/etc/rsyslog.conf to define logging rules, creating custom log files with proper permissions, and setting up logrotate to manage disk space. This ensures system logs are captured, rotated, and retained according to compliance standards required for certification.
Core Configuration File Structure
The primary configuration file for RSyslog is located at /etc/rsyslog.conf. Understanding its structure is essential for passing the RHCSA exam. The file is divided into several sections: global directives, modules, properties, and rules. Global directives control the behavior of the daemon itself, while rules determine where specific types of messages are sent.
For the exam, you must be comfortable modifying this file directly. While some distributions may use additional configuration files in /etc/rsyslog.d/, the core logic resides in the main configuration file. You should verify that the service is enabled and running using standard systemd commands like systemctl status rsyslog.
It is important to note that changes to /etc/rsyslog.conf require a restart of the service to take effect. Always check the syntax before restarting to avoid breaking the logging subsystem. A common practice is to backup the original file before making significant changes.
Defining Logging Rules
Logging rules follow the format facility.priority action. Facilities represent the source of the message (e.g., kern for kernel, authpriv for authentication), and priorities indicate the severity level (e.g., info, warn, err). Actions specify where the message should go, such as a file path or a remote server.
By default, most facilities are logged to /var/log/messages with an info priority. However, you can create custom rules to capture specific events. For example, to log all authentication errors to a dedicated file, you would add a rule like:
authpriv.* /var/log/auth_errors.logThis rule captures all priorities (*) from the authpriv facility and writes them to /var/log/auth_errors.log. Ensure the file exists and has appropriate permissions so the rsyslog user can write to it. If the file does not exist, RSyslog will typically create it, but setting permissions manually is safer for security audits.
Remember that rules are processed in order. If a message matches a rule and stops processing, it will not appear in subsequent rules unless specified otherwise. Use the ~ symbol to stop processing for a specific message.
Custom Log Files and Permissions
When creating custom log files, ensure they have the correct ownership and permissions. The rsyslog daemon usually runs as the root user or a dedicated user depending on the distribution. However, best practices suggest restricting access to sensitive logs like authentication records.
Use chmod 600 for sensitive logs and chmod 644 for general logs. This prevents unauthorized users from reading critical security information. Additionally, consider using chown root:root to ensure only root can modify the log file content, preventing tampering.
Log Rotation with Logrotate
RSyslog handles writing logs, but it does not rotate them. You must configure logrotate to manage old log files and prevent disk space exhaustion. The configuration for RSyslog-specific rotation is often found in /etc/logrotate.d/rsyslog.
A typical rotation configuration might look like this:
/var/log/messages /var/log/secure {
weekly
rotate 5
compress
delaycompress
missingok
notifempty
create 0644 root root
}This configuration rotates logs weekly, keeps five copies, compresses older logs, and creates new log files with specific permissions. The missingok directive prevents errors if the log file is missing, which can happen during testing or misconfiguration.
For the RHCSA exam, you may need to create custom logrotate configurations for your custom RSyslog files. Place these configurations in /etc/logrotate.d/ with a descriptive name. Ensure the paths match those defined in your RSyslog rules.
Testing Logrotate Configurations
Before deploying logrotate configurations, test them using the logrotate -d command. This dry-run mode displays what actions would be taken without actually performing them. It helps identify syntax errors or permission issues.
If you encounter issues with log rotation, check the /var/lib/logrotate/status file to see when each log was last rotated. This can help diagnose why logs are not being rotated as expected. Also, verify that the postrotate script, if used, correctly signals RSyslog to reopen log files.
Relating to Other System Services
While RSyslog handles local logging, other services like OpenSSH also generate logs that interact with the system. For instance, SSH authentication attempts are logged via the authpriv facility, which RSyslog captures. Understanding how these services integrate is crucial for comprehensive system administration.
For more details on configuring SSH securely, refer to our guide on Persistently configure the OpenSSH daemon on Linux. This complements your understanding of how authentication logs are generated and managed.
Similarly, firewall logs generated by iptables or firewalld are also captured by RSyslog. Knowing how to filter and direct these logs can help in troubleshooting network issues. For insights into firewall configuration, see Iptables Command: A Guide to Firewall Configuration on Ubuntu Router.
Common Pitfalls and Troubleshooting
One common mistake is forgetting to restart the RSyslog service after making changes. Always run systemctl restart rsyslog to apply new rules. Another issue is incorrect file permissions, which can prevent RSyslog from writing to custom log files. Check the journal logs using journalctl -u rsyslog for error messages.
If logs are not appearing in the expected location, verify the facility and priority in your rules. Ensure that the log file path is absolute and that the directory exists. Also, check SELinux contexts if applicable, as strict policies can block RSyslog from writing to non-standard locations.
Frequently Asked Questions
How do I check if RSyslog is running?
Use the command systemctl status rsyslog to view the current state of the service. If it is inactive, start it with systemctl start rsyslog and enable it to start on boot with systemctl enable rsyslog.
What happens if I don't configure logrotate?
Without logrotate, log files will grow indefinitely until they consume all available disk space. This can lead to system instability or failure. Always pair RSyslog configurations with appropriate logrotate settings.
Can I send logs to a remote server?
Yes, you can configure RSyslog to send logs to a remote syslog server by specifying a UDP or TCP destination in the action part of the rule, such as @remote-server-ip for UDP or @@remote-server-ip for TCP.
How do I debug RSyslog configuration errors?
Run rsyslogd -N1 to validate the configuration syntax without starting the daemon. Check /var/log/messages or journalctl -u rsyslog for runtime errors after attempting to restart the service.
Why are my custom logs not being created?
Ensure that the parent directory exists and has write permissions for the RSyslog user. Also, verify that the rule syntax is correct and that the service has been restarted after adding the rule.