How to Forward /var/log/yum.log to Remote Logging Server using rsyslog.conf?

To forward /var/log/yum.log to a remote server, you must configure rsyslog to read the file and send its contents via TCP or UDP. This involves creating a dedicated input module in /etc/rsyslog.conf to tail the log file and defining an output action with your remote host details. This setup ensures that package installation events are centrally aggregated for auditing without modifying the local logging behavior.

Understanding the Log Source

The file /var/log/yum.log is generated by the Yellowdog Updater, Modified (YUM) or DNF package managers. It records transactions such as package installations, updates, and removals. By default, this information stays on the local machine. To send it remotely, we treat yum.log not as a standard syslog stream, but as a flat file that rsyslog needs to monitor continuously. This approach differs from forwarding standard system logs like /var/log/messages. Standard logs are already structured in syslog format. In contrast, yum.log is a plain text file. Therefore, we cannot simply use a facility selector like local0.* to catch it. We must explicitly tell rsyslog to open this specific path and parse each line as it is written. For more context on managing log files based on application sources, see our guide on Log file name based on application with syslog-ng. While that article covers syslog-ng, the conceptual separation of application-specific logs remains relevant when designing centralized logging architectures.

Configuring the Input Module

Modern versions of rsyslog (v8+) use dynamic modules for file input. You need to load the imfile module, which allows rsyslog to act as a log watcher for arbitrary files. Open your configuration file, typically located at /etc/rsyslog.conf, or create a new file in the /etc/rsyslog.d/ directory, such as /etc/rsyslog.d/99-yum-forward.conf. Using a separate file keeps your main configuration clean and makes upgrades easier. Add the following lines to load the module:

module(load="imfile")

Next, define the input source. The input directive requires several parameters to function correctly. You must specify the tag, which identifies the log entries in the remote system. A common convention is to prefix tags with the hostname or service name to avoid collisions. For example, using [yum] as the tag helps distinguish these messages from other system events. You also need to set the filename to /var/log/yum.log. The severity and facility determine how the remote server categorizes the message. Typically, info severity and local7 facility are appropriate for administrative audit logs. Finally, StateFile is critical. Rsyslog uses state files to remember where it left off reading. If you do not provide a unique state file name, rsyslog may fail to track multiple inputs or restart incorrectly. Here is the complete input configuration block:

input(type="imfile"
      File="/var/log/yum.log"
      Tag="yum-log:"
      Severity="info"
      Facility="local7"
      StateFile="/var/lib/rsyslog/imfile-yum.state"
      RestartOnTimeout="on"
      PollingInterval="10")

The PollingInterval defines how often rsyslog checks for new data. Ten seconds is usually sufficient for yum logs, which are written infrequently compared to web server access logs. The RestartOnTimeout option ensures that if rsyslog crashes, it resumes reading from the last known position rather than skipping data or duplicating it.

Defining the Remote Output Action

Once rsyslog reads the file and assigns it a tag and facility, you must direct those messages to your remote logging server. This is done using the action syntax. You have two primary transport options: TCP and UDP. TCP is recommended for reliability. It guarantees that no log entries are lost during transmission, provided the connection is stable. UDP is faster but offers no delivery guarantees; packets may be dropped under high load. For audit logs like yum transactions, reliability is paramount. To send to a remote server over TCP, add the following line to your configuration:

if $syslogtag contains 'yum-log:' then {
    action(type="omfwd"
           target="YOUR_REMOTE_IP"
           port="514"
           protocol="tcp"
           queue.type="LinkedList"
           queue.filename="yum_fwd"
           queue.maxdiskspace="1g"
           queue.saveonshutdown="on")
    stop
}

Replace YOUR_REMOTE_IP with the IP address or hostname of your central logging server (e.g., ELK Stack, Splunk, or another rsyslog instance). The queue parameters are vital for preventing data loss. If the network is slow or the remote server is down, rsyslog buffers the messages in memory and on disk. Setting queue.maxdiskspace prevents rsyslog from consuming all available disk space. queue.saveonshutdown="on" ensures that buffered logs are saved before rsyslog stops, allowing them to be sent upon restart. The stop directive at the end of the block prevents the local rsyslog from processing these messages further through the default ruleset. Since we only want to forward them, stopping here avoids duplicate writes to local logs if you have generic catch-all rules below.

Applying and Verifying Changes

After saving your configuration, validate the syntax before restarting the service. Run the following command to check for errors:

rsyslogd -N1

If the output indicates success, restart the rsyslog daemon to apply the changes:

systemctl restart rsyslog

To verify that the forwarding is working, perform a test package installation on the local machine:

yum install vim-enhanced

Wait a few moments, then check the remote logging server. You should see entries tagged with yum-log: containing the transaction details. On the local machine, you can also check the rsyslog status to ensure the input module is active:

journalctl -u rsyslog -n 20 --no-pager

Look for messages indicating that the imfile module has started reading /var/log/yum.log. If you encounter issues, ensure that firewall rules allow traffic on port 514 (or your chosen port) between the source and destination servers. Also, verify that the user running rsyslog (usually root or syslog) has read permissions for /var/log/yum.log.

Frequently Asked Questions

What happens if the remote server is unreachable?

Rsyslog will buffer the messages locally using the queue settings defined in the action. As long as you have configured queue.maxdiskspace and queue.saveonshutdown, your logs will not be lost. Once the connection is restored, rsyslog will automatically flush the queue and send the pending messages.

Can I use UDP instead of TCP for better performance?

Yes, you can change protocol="tcp" to protocol="udp" in the action block. However, UDP does not guarantee delivery. If the network experiences packet loss, yum log entries might be dropped. For critical audit trails, TCP is strongly preferred despite the slight overhead.

Why is my state file growing indefinitely?

The state file tracks the byte offset of the last read line. It should grow only when new logs are written. If it grows excessively without log activity, check for permission issues or if rsyslog is crashing repeatedly. Ensure the StateFile path is writable by the rsyslog process.

How do I prevent duplicate logs on the remote server?

Ensure that the remote server is not also receiving logs from other sources that include yum data. Use unique tags like yum-log: and filter strictly on that tag in the remote configuration. Additionally, verify that the local rsyslog is not forwarding the same data via multiple actions.

Does this method work for DNF on newer distributions?

Yes. DNF also writes to /var/log/yum.log by default on many distributions, or you can configure DNF to use the same log path. The rsyslog configuration remains identical because it monitors the file path, not the writing application.