Rsyslog Template is not working in Rocky Linux 8

Rocky Linux General
1

Hi,
We are currently using centralized log server configured on Centos 7 , Now we are planning to building new server using Rocky Linux 8 and decommission old server.

Weird thing is that rsyslog Template is not working in version 8. Below is the complete rsyslog configuration

image
image711×308 11.1 KB

As per this configuration rsyslog should create directory with client hostname inside /data and should put log inside.

On Centos 7 its working fine, we tested by creating new rsylog tetst server also.

Traffic is reaching on both test rsyslog server. ( Rocky 8 and Centos 7 ) . We can see from tcpdump.

image
image1655×144 7.63 KB

Centos 7 creating the client directly ( /data/php-apps-03) whereas Rocky 8 is not.

image
image1370×88 3.01 KB

We even tried to use /etc/rsyslogd.conf file of Centos 7 on Rocky 8. still client directories not creating.

2

After two day struggling :grimacing: we are able to resolve the issue. Actually issue was not with rsyslog. Culprit was firewalld on Rocky 8.

disabling the firewalld put every thing back on track.

systemctl stop firewalld.service

3

Which is obviously not the optimal solution. Do remember that firewalld does more than just filter. For example, the NAT. (Although, your server probably does not use NAT?)

The more appropriate approach is to configure the firewall to allow the rsyslog-traffic.
The firewalld has predefined service ‘syslog’:

# firewall-cmd --info-service=syslog
syslog
  ports: 514/udp
  protocols: 
  source-ports: 
  modules: 
  destination: 
  includes: 
  helpers:

Is that what the rsyslog listens?

FirewallD is zone-based. You have at least two zones:

  • Machines that send rsyslog-data
  • Everyone else

Both zones should allow the usual stuff, but the first zone must allow syslog too.

If you don’t like FirewallD, then you can write your whole ruleset for nftables.service

4

Dear Jlehtone,
Couple of years before we have migrated all Dev/Prod workload to AWS. Before migration we were using firewalld/iptables. In AWS all host base firewall functionality is achieved through EC2 Security Groups (without any performance impacts). So in general keeping firewalld etc in disable state.

5

In that case disabling the firewall inside OS is indeed the right thing to do.