Set up a syslog server with rsyslog and logrotate

Central logging gives an Australian IT team a dependable view of what happened across firewalls, switches, servers and remote sites. An office may combine a Windows file server, a Linux appliance and a Fortinet gateway, while staff work from an NBN-connected home or a regional branch with less consistent broadband. A small VM in Sydney or Melbourne can collect those events without turning into a heavyweight security platform.

This guide establishes a practical baseline: receive messages over UDP or TCP, store them in a controlled directory, rotate them predictably, and test the path from sender to archive. It assumes a Debian or Ubuntu host, but the same design fits a RHEL-family server. Keep timestamps in UTC and convert them for display, especially when Sydney and Melbourne move to daylight saving time and Brisbane does not.

Choose the host and define the data boundary

Use a dedicated VM or appliance where possible, with a reserved internal address, a stable DNS name such as logs.example.com.au, and NTP or chrony synchronisation. Put it on a management segment rather than the same VLAN as guest Wi-Fi or public web traffic. Check free disk space, inodes and backup capacity before pointing devices at it; a log collector that fills its filesystem can become an outage of its own.

Decide which sources may send logs and how long the team needs them. Routers, NAS appliances, UPS units and application servers may support different transports, so accept TCP where possible and UDP for older appliances while restricting both to known source networks. A remote NBN site should use a site-to-site VPN or encrypted tunnel rather than opening port 514 to the internet. Logs can contain names, IP addresses and user identifiers. If the Privacy Act 1988 applies to the organisation, collection, access and retention should align with the Australian Privacy Principles; an eligible notifiable data breach must also be handled under the Notifiable Data Breaches scheme.

Install rsyslog and create a predictable layout

On Debian or Ubuntu, install the daemon and rotation utility, then enable the service:

sudo apt update
sudo apt install rsyslog logrotate
sudo systemctl enable --now rsyslog
sudo install -d -o syslog -g adm -m 0750 /var/log/rsyslog

Enable the packaged logrotate.timer where it is available, or leave rotation to the distribution’s daily cron job. The custom directory gives incoming messages a stable home and separates them from /var/log/syslog. Confirm the relevant accounts with getent passwd syslog and getent group adm, since RHEL-family systems may use different paths and SELinux policies. Many Australian small offices still rely on Windows endpoints, Linux services, NAS boxes and Fortinet or Cisco gateways. SMB research is a useful reference when checking the protocol behaviour and interoperability of those storage sources.

Configure collection and protect the listener

Merge the following into the existing /etc/rsyslog.conf rather than replacing the package rules. Retain the distribution’s local imuxsock configuration; the two remote inputs accept network traffic and write it to a separate file:

module(load="imudp")
module(load="imtcp")
module(load="omfile")

template(name="RemoteFormat" type="string"
    string="%TIMESTAMP:::date-utc-rfc3339% %fromhost% %syslogtag%%msg:::drop-last-lf%\n")

ruleset(name="remote") {
    action(type="omfile" file="/var/log/rsyslog/remote.log"
          template="RemoteFormat")
    stop
}

input(type="imudp" port="514" address="0.0.0.0" ruleset="remote")
input(type="imtcp" port="514" address="0.0.0.0" ruleset="remote")

Check the configuration with sudo rsyslogd -N1, restart the service, and use ss -lntup to confirm both sockets are listening. Then allow only the source subnet through the host firewall. For example, use ufw allow from 192.0.2.0/24 to any port 514 proto tcp and the matching UDP rule, replacing that documentation range with the real branch network. For important events, prefer TCP or use imtls with certificates on a dedicated encrypted port. Plain syslog on 514 provides neither confidentiality nor sender authentication. Once the pattern is stable, teams can use automating configuration tasks to explore F# for repeatable server and appliance changes instead of hand-editing every location.

Rotate files without breaking the trail

Add a dedicated file under /etc/logrotate.d/ for the custom directory, and avoid overlapping it with the distribution’s existing rsyslog rule:

/var/log/rsyslog/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog adm
    su syslog adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

The policy keeps 30 daily generations, compresses older files and avoids creating empty archives. create and su protect the files, while the post-rotation hook asks rsyslog to reopen its outputs. Verify that the helper script exists on your distribution or use sudo systemctl kill -s HUP rsyslog. A busy collector may need a maxsize rule or shorter retention period. Avoid copytruncate unless the application cannot reopen files, because it creates a small loss window. Monitor the directory and send encrypted copies to an Australian-hosted backup target, such as an AWS Sydney or Melbourne region or an Azure Australia East account, while checking the provider’s contractual data-residency terms.

Validate the service and run it as a team

Test locally, then from a representative client, and record the results in the runbook:

sudo rsyslogd -N1
sudo systemctl restart rsyslog
logger -p local0.info "local rsyslog test"
logger --server 192.0.2.10 --port 514 --tcp "remote TCP test"
logger --server 192.0.2.10 --port 514 --udp "remote UDP test"

The local message should appear in the distribution’s normal syslog file, while the remote messages should appear in /var/log/rsyslog/remote.log. Replace the example server address with the actual collector.

Checks before the first client

  • Confirm the hostname, source address, facility, severity and timestamp appear correctly.
  • Restrict TCP and UDP access to the approved office and VPN ranges.
  • Set file ownership, retention and backup ownership before enabling a production source.
  • Record a rollback command and the person responsible for the listener.

Once live, schedule a daily review of the collector’s health. Alert on a stopped service, disk pressure, a sudden drop in events or a failed client connection. The Australian market includes both locally managed appliances and cloud platforms, so the runbook should identify whether each change is local, hosted in an Australian region or managed externally.

Checks during each rotation

  • Run logrotate -d first and inspect the planned rename and compression actions.
  • Verify that rsyslog reopens the active file and that new messages still arrive.
  • Watch free space, inode use, delivery failures and the oldest retained archive.
  • Rehearse restoration of a compressed file from the off-site backup.

Keep the device inventory beside the runbook. Each source should record its site, transport, source subnet, owner and last test date, so a replacement firewall or a new office can be added without guesswork. An off-site archive and a documented restoration test provide useful continuity if a summer storm, heat event or bushfire smoke disrupts a site.

Start with one representative office or a lab VM: install the packages, send a local event and a TCP event from a client, and force one controlled rotation. Once the path is repeatable, add sites one at a time, review the resulting alerts, and keep every retention decision tied to a named owner. That sequence creates a dependable syslog service without turning the host into a dumping ground.

Experience

Information Technology Consulting

Independent Practice

Provides IT consulting services focused on infrastructure planning, cloud migration strategy, and systems architecture. Engagements draw on years of hands-on sysadmin and development experience across Linux, Windows, and hybrid environments.

K9 Search & Rescue Volunteer

Ongoing

Active participant in K9 Search & Rescue operations, combining technical logistics skills with field support for canine search teams.

Karl Katzke's Blog

October 2006 – May 2014

Published a long-running personal technology blog covering cloud vs. in-house infrastructure, F# and Mono on OSX, hardware vendor critiques, RAID card performance analysis, and sysadmin storytelling. Notable posts include "When Sysadmins Ruled the Earth" (May 15, 2014) and "Getting Started with F# and Mono on OSX" (December 22, 2012).

Credentials

A small badge icon with a shield shape in muted blue tones on a light background

Systems Administration

Deep experience with Linux (RHEL, SLES, CentOS), high-availability clusters, and STONITH configurations.

A small badge icon with a gear shape in muted blue tones on a light background

Cloud Infrastructure

Practical knowledge of AWS EC2, reserved instances, and cost analysis for cloud vs. on-premises deployments.

A small badge icon with a code symbol in muted blue tones on a light background

Development

Proficient in F#, PHP (Symfony), and cross-platform tooling including Mono and MonoDevelop on OSX.

Studies

F# & Functional Programming

Self-directed, 2012

Explored strongly typed functional programming with F# on OSX using the Mono runtime. Published a detailed getting-started guide covering toolchain setup and cross-platform game development research.

High-Availability & Cluster Management

Professional Development, 2009

Configured and documented crm_mon email alerting for STONITH events on SLES11-HAE clusters, integrating with Nagios monitoring for production environments.

Hardware & Storage Performance

Ongoing

Conducted hands-on benchmarking of SATA/SAS RAID controllers including HighPoint RocketRaid 2740 and LSI/SuperMicro AOC-USASLP2-H8iR, comparing against software RAID configurations.

Skills

A small icon representing a server with clean geometric lines in slate blue

Linux Administration

RHEL, SLES, CentOS — package management, kernel tuning, HA clustering, and monitoring integration.

A small icon representing a cloud shape with clean geometric lines in slate blue

Cloud Architecture

AWS EC2, reserved-instance planning, cost modeling, and hybrid infrastructure strategy.

A small icon representing code brackets with clean geometric lines in slate blue

F# & .NET/Mono

Functional programming on OSX, MonoDevelop toolchain, and cross-platform game-dev exploration.

A small icon representing a database cylinder with clean geometric lines in slate blue

PHP & Symfony

Web application development with the Symfony framework and the broader PHP ecosystem.

A small icon representing a storage drive with clean geometric lines in slate blue

Storage & RAID

SATA/SAS controller evaluation, md RAID configuration, and performance benchmarking.

A small icon representing a shield with clean geometric lines in slate blue

High Availability

Pacemaker, STONITH, crm_mon alerting, and Nagios integration for production cluster monitoring.