The system logger (rsyslog) includes general system logging facilities in one complete package. Generally, two kinds of logging are provided

• system logging which provides user-level system logging, used by external processes such as crond, and PAM
  
• kernel logging, which logs kernel messages
  

Previous versions, named syslog, divided these capabilities into two daemons, syslogd and klogd, where klogd was simply responsible for translating kernel messages into syslog format and syslogd did the actual logging. The newer package rsyslogd includes kernel log translation as a loadable module. rsyslogd also has advanced features to provide three types of remote logging: the traditional UDP transport, TCP, which is more robust and less lossy, and the new loss-less format RELP that uses message queuing. Most of the configuration file syntax of rsyslogd, which indicates how to log the various kinds of messages, is very similar to the old syslogd package. You can tell you are running the new package by the presence of the r prefix on the logging daemon (rsyslogd) and on its configuration file, rsyslog.conf.

Justification for rsyslog

Many system processes need to output status and informative messages periodically due to system events. Examples of these might be 

• a subsystem is started 
• a user logs on or off, attempts to log on unsuccessfully, or changes user id using su
• a user executes a command using sudo either successfully or unsuccessfully

The rsyslog subsystem provides a simple common interface for logging system events such as these, providing configurable redirection and/or duplication of these various types of messages in different files and/or to other systems. It also provides a consistent format for the messages.

Suppose an unsuccessful attempt is made to log in at the GUI console as alex. Rather than having to decide what to do with this information, whatever program is handling the login (sshd, login, or, in this case, gdm) simply assembles a message specifying

• the type of message (called the facility). Here the facility would be authpriv, which indicates a secure authentication message
• the importance of the message (called the priority). In this case the priority is probably info or notice.
• the message itself. This contains a tag (usually the originator), and the message data. In this case, the tag would indicate the low-level authentication package that attempted the login (pam_unix) prehaps as well as the user program that initiated it (gdm - the gnome display manager)

Then the syslog function in the C library (syslog(3)) is invoked. This writes to the Unix domain socket (usually /dev/log), which rsyslogd listens to. When rsyslogd reads the information from the socket, it logs it in the log file specified by /etc/rsyslog.conf, which determines where messages are logged based on their priority and facility, adding the date and the hostname.

In the example of an unsuccessful attempt to login at the GUI conosole as the existing user gboyd, my current system is configured to place the following message in /var/log/secure:

May  4 15:12:30 localhost pam: gdm-password[19885]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=:1 ruser= rhost=  user=gboyd

In this message you can see several parts: the timestamp, the host, the service (pam) and the module (pam_unix) and the message.

rsyslogd's configuration file /etc/rsyslog.conf details how rsyslogd is configured and where messages are logged. We will discuss that next. In previous versions, a syslogd file in /etc/sysconfig detailed daemon configuration options, but this functionality has been merged into rsyslog.conf

Note: The rsyslog package, including rsyslogd(8) is referred to as rsyslogd, or rsyslog Its configuration file is rsyslog.conf and the subsystem is rsyslog. The traditional syslog package is referred to variously as syslog, syslogd, or sysklogd. The configuration file and subsystem are named syslog.conf and syslog, respectively.

Next we will discuss rsyslog's configuration file. But since we will be working on multiple VMs during this section, we should take a sidestep and learn how to control them remotely.