remote syslog

Posted by: Brad Waite

syslog is the standard system logging tool on most flavors of unix.  It stores records of system events in a number of user-defined files.  On FreeBSD, these files live by default in /var/log.  syslog has a configuration file, /etc/syslog.conf, that determines which file to log system events.

What a lot of people don't know is that syslog can send events to a remote syslog server.  This means you can have all of your logs from multiple machines stored on a single host automatically.  Both the client and the server need properly configured config files.

Here's a quick primer on syslog.conf:

The file is broken into sections separated by program and/or hostname definition lines.  Program definitions are in the form of "!program" (ex: !httpd), while hostname definitions take the form "+hostname" (ex: +  "-" (minus) can be used to exclude a program or hostname, so "!-httpd" would log every program except httpd.  Multiple definitions can be separated by commas (ex: !httpd, qmail).  Program and hostname definitions can be reset by using "*" (!* or +*).

Each section contains rules that are valid for only the most recent program and hostname definitions.  Rules are made up of two fields, the selector and the action, separated by tabs or spaces.  Selectors define what types of messages and priorities and the action defines what to do with those messages.

Selectors look like this: facility.level, where facility is the part of the system that generated the message and can be one of the following keywords:

auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, mark, news, ntp, security, syslog, user, uucp and local0 through local7.

Multiple selectors can be separated by a ';'.

Level defines the severity of the message and can be one of the following keywords:

emerg, alert, err, warning,  notice, info and debug.

You can also use the comparison flags !, <, > and = after the "." to specify a range of severity levels.  For example, "mail.<=notice" would log all notice, info and debug messages for the mail facility.  The default flag is >=, so "mail.alert" would log alert and emerg messages for mail.

The action field can take one of five forms:

  • the full path of a file to which the message is appended (/var/log/mail.log)
  • a hostname on which a syslog server is listening (@hostname)
  • a comma-separated list of users who will see messages on their terminal if logged in (root, ecarter)
  • a *, which writes the message to all logged-in users
  • a | followed by a command (| mail admin)

So how do you combine these configuration parameters to set up remote syslog?  Let's look at a simple example with a server named "logmaster" and a client named "mailhost".

Server Config

# Log all messages coming from mailhost
*.* /var/log/mailhost/mail.log

Client Config

# local logging
*.notice;kern.debug; /var/log/messages

# send all mail messages to logmaster
mail.* @logmaster

This is a basic remote syslog configuration that simply sends all messages on mailhost with a "mail" facility to logmaster, where they are appended to a file.  This isn't necessarily idea since all the mail messages, regardless of their originating program, are globbed into a single file.

By using the program definition after the host definition in the syslog.conf on the server, we can separate log messages based on which program they came from.

Server Config

# Log all messages coming from mailhost

# log qmail messages of all facilities and severities
*.* /var/log/mailhost/qmail.log

# log messages from imapd of all facilities and severities
*.* /var/log/mailhost/imapd.log

# log messages from POP daemon of all facilities and only err+ severity
*.err /var/log/mailhost/pop3d.log

In this config, we're taking all the mail syslog messages from mailhost and saving ones from qmail, imapd and pop3d to their respective files.

You can probably see how using different combinations of the program and hostname definitions and syslog facilities can match any message and direct it where you wish.

That's remote syslog logging in a nutshell.


Comments (0)Add Comment

Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.