contact@linuxtpoint.com
Linuxtpoint
Candid photograph of a Linux server terminal with a soft olive-green glow against a dark slate background, conveying a calm technical atmosphere.

Step-by-step guides for system administrators — covering command-line basics, web server setup, and preparation material for technical interviews.

Browse Tutorials

Setting Up a Centralised rsyslog Server on CentOS

A centralised logging host collects messages from web servers, databases, firewalls, and applications in one searchable location. On CentOS, rsyslog is a practical choice because it is lightweight, widely documented, and integrates with systemd, SELinux, logrotate, and common monitoring tools.

This arrangement makes troubleshooting easier across hosts in Sydney, Melbourne, or a distributed Australian environment. Administrators can review authentication failures, service restarts, and kernel events without signing in to every machine. The Linux administration guides provide further command-line and server-maintenance material for building this foundation.

The examples below assume CentOS Stream 9, a server named loghost, and a private network such as 10.20.0.0/24. Use a static address or a reliable DHCP reservation, and synchronise time with chrony so events from different systems can be correlated accurately.

Prepare The CentOS Host

Install updates and rsyslog on the central server:

sudo dnf update -y
sudo dnf install -y rsyslog firewalld policycoreutils-python-utils
sudo systemctl enable --now rsyslog firewalld

Give the host a stable DNS record, such as loghost.example.internal. Confirm that the service is active and check its recent messages:

systemctl status rsyslog
journalctl -u rsyslog --no-pager -n 30

A logging host should have sufficient disk space and should not share its only storage volume with a busy database. In an Australian office connected through NBN, temporary connectivity interruptions can produce bursts of queued messages, so leave reasonable capacity for delayed delivery.

Enable Secure Remote Transport

Edit /etc/rsyslog.conf and add listeners for the protocols required by your environment. TCP is generally preferable because it confirms delivery at the transport layer:

module(load="imtcp")
input(type="imtcp" port="514")

module(load="imudp")
input(type="imudp" port="514")

Restart rsyslog, then permit only the source networks that need to send logs. Firewalld can allow TCP and UDP separately:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.20.0.0/24" port port="514" protocol="tcp" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.20.0.0/24" port port="514" protocol="udp" accept'
sudo firewall-cmd --reload

Plain rsyslog traffic is unencrypted. For messages crossing an untrusted network, use rsyslog TLS, a VPN, or a private management network. A staging system can also validate log forwarding behaviour with a web testing reference when application events must be checked alongside infrastructure records.

Store Messages By Host

Create a dedicated configuration file at /etc/rsyslog.d/10-central-storage.conf. The following template separates each sender and keeps messages grouped by year, month, and program:

$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& stop

Create the directory, check the syntax, and restart the daemon:

sudo mkdir -p /var/log/remote
sudo rsyslogd -N1
sudo systemctl restart rsyslog

The & stop rule prevents these messages from continuing through unrelated local rules. Hostnames supplied by clients should be consistent; otherwise, one machine may create multiple directories. For larger estates, use a naming convention based on inventory records and reserve a separate partition for /var/log/remote.

Configure CentOS Clients

On every client, create /etc/rsyslog.d/90-forwarding.conf:

*.* action(
  type="omfwd"
  target="loghost.example.internal"
  port="514"
  protocol="tcp"
  action.resumeRetryCount="-1"
  queue.type="linkedList"
  queue.filename="fwd_queue"
  queue.saveOnShutdown="on"
)

The disk-assisted queue helps retain messages during a short outage. Test the configuration before restarting:

sudo rsyslogd -N1
sudo systemctl restart rsyslog
logger -p local0.notice "central logging test from $(hostname)"

On the server, look for the generated file under /var/log/remote/. If no event appears, inspect DNS, firewalld, SELinux denials, and the client’s journalctl -u rsyslog output. The logger command is useful because it creates a controlled test without needing to stop a production service.

Protect And Rotate The Archive

Log files can contain usernames, IP addresses, request paths, and other personal information. Australian organisations handling personal information should consider the Privacy Act 1988, the Australian Privacy Principles, and the Notifiable Data Breaches scheme when choosing access controls, retention periods, and incident procedures. These considerations matter when logs are stored in a local data centre, an Australian cloud region, or a provider outside Australia.

Set ownership and permissions so ordinary users cannot browse central records:

sudo chown -R root:root /var/log/remote
sudo chmod 750 /var/log/remote
sudo semanage fcontext -a -t var_log_t "/var/log/remote(/.*)?"
sudo restorecon -Rv /var/log/remote

Logrotate should compress older files and remove them according to an approved retention policy. Before changing storage or retention, take a tested backup. The guide on LVM snapshots on CentOS explains a useful method for protecting filesystem changes, although snapshots should complement rather than replace independent backups.

Test Reliability And Capacity

A central logger is only useful when its data can be trusted. Check that timestamps use the correct timezone, commonly Australia/Sydney or Australia/Melbourne, and verify chrony on every host:

timedatectl
chronyc tracking

Use logger to test ordinary delivery, stop rsyslog briefly on the server to test client queuing, and then confirm that delayed messages arrive after recovery. Monitor disk utilisation with df -h /var/log and review service errors with journalctl.

Area Recommended setting Verification
Transport TCP 514 on a private network ss -ltnp | grep 514
Client queue Disk-assisted forwarding queue Inspect rsyslog service logs
Storage Per-host directories and a dedicated filesystem find /var/log/remote -type f
Access Root-controlled ownership and SELinux labels ls -Zd /var/log/remote
Retention Documented rotation and deletion policy Review /etc/logrotate.d/

Run a final controlled event from one client and confirm its hostname, timestamp, facility, and severity in the central file. The next concrete step is to execute logger -p authpriv.notice "rsyslog validation" on a client and verify the resulting record on loghost.