Okay, I found a way. It turns out the $ActionForwardDefaultTemplate by default is set to :
$ActionForwardDefaultTemplate RSYSLOG_ForwardFormat
Per this rsyslog documentation, the RSYSLOG_ForwardFormat
is specifically used to maintain interoperability between different syslogs. No shocker then that if you modify this Forward template as I described originally, some functionality for other syslogs break:
$template MyTemplate, "%timestamp% <FQDN> %syslogtag%%msg%"
$ActionForwardDefaultTemplate MyTemplate
The workaround I found was to dig up the back-end template that RSYSLOG_ForwardFormat
uses and mimic it. After digging through the source I eventually found that RSYSLOG_ForwardFormat
is actually this:
"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
So, if I create a custom template with almost the same content, but substitute my FQDN in place of the %HOSTNAME%
macro, syslog-ng facility separation works properly and the system logs with FQDN:
$template MyForwardTemplate, "<%PRI%>%TIMESTAMP% <fqdn> %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
$ActionForwardDefaultTemplate MyForwardTemplate
I solved it. It was a routing(!) error. Server could not reach the message originator, thus, the message was not processed from rsyslog... Go figure...
Best Answer
For outgoing connections the source interface is usually determined according to your routing tables. If you do
ip route show
you should get some output similar to this:In this snippet you see a list of destination networks on the left side, and after the
dev
keyword you see which outgoing interface is going to be used for outgoing packets to this destination.If you want to modify this behaviour you can change your routes by using the
ip
utility, for this you can checkman ip-route
. Another way which is more powerful but also more complicated would be to create specific routing rules, you can see more about that inman ip-rule
.