System Logs

System Logs provides a method for controlling the syslogd daemon used on most UNIX system to provide standard logging functions. The module opens with a list of all currently existing logs. By clicking the Log destination of a log file, you can edit the logging properties, as shown in Figure 5-11. On the editing page there is also a View log button that allows you to view a configurable number of lines from the end of the log file. It also allows a constantly refreshing log view if selected.

Figure 5-11: System Logs

This module edits the /etc/syslog.conf file and provides a pretty easy way to check up on your logs remotely. And even though the module is designed primarily for syslogd logs only, it is flexible enough to allow you to view other types of logs as well. For example, the web-caching proxy Squid doesn’t use standard syslog facilities, so doesn’t fall under the control of syslogd. Nonetheless, I like to be able to check up on a running Squid, so I add an entry on all of the boxes I administer to allow me to watch those logs in Webmin. To create a new syslog entry, click the Add a new system log link.

Adding a System Log

The Add System Log page is divided into sections labeled Log Destination and Message types to log.

Log Destination

The log destination options below specify where log entries will be written, and whether a particular log is active.

Log to

This option configures the destination of the log file. Syslog can log to a file, a named pipe, a remote syslog server, or the console of some or all local users.

File

The log entries will be appended to the file name specified. A complete path should be given. Historically, system logs are stored in /var/log. The Sync after each message? option will cause the syslog daemon to flush to disk after every entry, therefore overriding the disk I/O buffering provided by the operating system. This can be detrimental to performance in circumstances in which logging occurs at a very rapid rate, such as the mail log on a very busy mail server. In most circumstances, the integrity of the log is far more important than avoiding the small amount of disk activity system logs generate.

Named pipe

The concept of pipes is fundamental to the UNIX Way, or the philosophy of combining small tools to perform large jobs efficiently and flexibly. Most UNIX users are familiar with the standard command-line pipe, which allows the output of one command to be the input of another command. A named pipe expands upon that and allows output to be sent to a pipe that is located within the normal filesystem under a normal file name. Or, to put it another way, the output of syslog will go to whatever program is accepting input from the named pipe. While named pipes and their usage is beyond the scope of this book, I will point out a few resources to get you started on the subject. Many modern UNIX systems, including Linux systems, include a command called mkfifo, which creates the FIFO special file connected to a named pipe. Reading the man page, as well as reading about named pipes in your favorite general UNIX reference should give you a good overview of the topic.

Syslog server on

The syslogd daemon can log to local files, pipes, and users, as well as direct its output to a remote server running syslogd. However, the remote server must be configured to permit remote logging from your server. When using remote logging, the address of the server is entered here.

Local users, All logged-in users

When one or more users, or all users, are specified here, the log entries that match the description will be written to all open consoles of the users specified. For example, on most systems, all messages of priority .emerg, or emergency, are sent to all user consoles. Most systems are configured to send shutdown and reboot messages at this priority.

Logging active?

This is a simple yes or no question, with obvious meaning. However, what may not be obvious is that a disabled log is simply commented out in the /etc/ syslog.conf file with a hash mark, and so the configuration details remain in the file even though it is no longer an active logging entry.

Message Types to Log

Here the types of messages to log to the configured log destination can be specified. Any given log entry has two identifiers: its facility and its priority. The facility specifies the type of program generating the log, such as mail, daemon, cron, or locally definable facilities, named local0 through local7 on many Linux systems and similarly defined on other UNIX variants. The priority is the level of message on a scale of debug to emergency. The priority level used by any given program for any given message is somewhat arbitrary, as it is chosen by the author(s) of the program. However, it is safe to say that debug level messages will be incredibly verbose and unnecessary in all but the most complicated troubleshooting situation, while emergency is reserved for messages of the utmost importance. Generally, you’ll want to configure the priority of logs somewhere in the middle of this, somewhere around warning or err.