syslog Configuration

Making sure your system processes and critical applications log the events and states you're interested in with syslog.
Actions

In practice, most log messages are written to files. If you list the full path to a filename as a line's action in syslog.conf, messages that match that line will be appended to that file. (If the file doesn't exist, syslog will create it.) In the syslog.conf line above, we instructed syslog to send matched messages to the file /var/log/mail.

You can send messages other places too. An action can be a file, a named pipe, a device file, a remote host or a user's screen. Pipes usually are used for debugging. Device files people use tend to be TTYs, but some people also like to send security information to /dev/lp0, that is, to a local line printer. Logs that have been printed out can't be erased or altered by an intruder, and this is an excellent use for old dot-matrix printers.

Remote logging is one of the most useful features of syslog. If you specify a hostname or IP address preceded by an “@” sign as a line's action, messages that match that line will be sent to that remote host. For example, the line

*.emerg          @mothership.mydomain.org

will tell syslogd to send all messages with emerg priority to the host named mothership.mydomain.org. Note that the remote host's (in this example, mothership's) syslogd process will need to have been started with the -r flag in order for it to accept your log messages. By default, syslogd does not accept messages from remote systems.

If you run a central logserver, which I highly recommend, you'll want to consider having some sort of access controls on it for incoming messages. At the very least you should consider TCPwrappers' hosts-access (source-IP-based) controls or maybe even local firewall rules (ipchains or iptables).

Stealth Logservers

More Sophisticated Selectors

You can list multiple facilities separated by commas in a single syslog.conf selector. To extend our original syslog.conf line to include both mail and UUCP messages (still with priority notice or higher), you could use this line:

mail,uucp.notice     /var/log/mail

The same is not true of priorities. Remember that only one priority or priority wildcard may be specified in a single selector.

You may, however, specify multiple selectors separated by semicolons. When a line contains multiple selectors, they're evaluated from left to right; you should list general selectors first, followed by more specific selectors. Think of selectors as filters: as a message is passed through the line from left to right, it passes first through coarse filters and then through more granular ones.

Continuing our one-line example, suppose we still want important mail and UUCP messages to be logged to /var/log/mail, but we'd like to exclude UUCP messages with priority alert. Our line then looks like this:

mail,uucp.notice;uucp.!=alert     /var/log/mail

Actually, syslogd's behavior isn't as predictable as this may imply. Listing selectors that contradict each other or that go from specific to general, rather than the other way around, can yield unexpected results. Therefore, it's more accurate to say that for best results, list general selectors to the left and their exceptions (and/or more specific selectors) to the right.

Wherever possible, keep things simple. You can use the logger command to test your syslog.conf rules (see the “Testing System Logging with logger” section toward the end of this article).

Note that in the second selector (uucp.!=alert) we used the prefix “!=” before the priority to signify “not equal to”. If we wanted to exclude UUCP messages with priority alert and higher (i.e, alert and emerg), we could omit the “=”:

mail,uucp.notice;uucp.!alert      /var/log/mail

You might wonder what will happen to a UUCP message of priority info; this matches the second selector, so it should be logged to /var/log/mail, right? Based on the above examples, it won't. Since the line's first selector matches only mail and UUCP messages of priority notice and higher, such a message wouldn't be evaluated against the second selector.

There's nothing to stop you from having a different line for dealing with info-level UUCP messages, however. You even can have more than one line deal with these if you want. Unlike a firewall rule-base, each log message is tested against all lines in /etc/syslog.conf and acted on as many times as it matches.

Suppose we want emergency messages broadcast to all logged-in users as well as being written to their respective application logs. We could use something like the sample shown in Listing 1 to achieve this. Note the “-” sign in front of the write-to-file actions. This tells syslogd not to synchronize the specified log file after writing a message that matches that line.

Listing 1. A Sample syslog.conf File

Skipping synchronization increases the chances of introducing inconsistencies such as missing or incomplete log messages into those files, but it decreases disk utilization and thus improves performance. Use the minus sign, therefore, in lines that you expect to result in frequent file writes.

In Listing 1 we see some useful redundancy. Kernel warnings plus all messages of error-and-higher priority, except authpriv messages, are printed to the X-console window. All messages having priority of emergency and higher are printed there too and are also written to the screens of all logged-in users.

Furthermore, all mail messages and kernel messages are written to their respective log files. All messages of all priorities (except mail messages of any priority) are written to /var/log/messages.

The previous examples were adapted from the default syslog.conf that SuSE 7.1 put on one of my systems. But why isn't such a default syslog.conf file fine the way it is? Why change it at all?

Maybe you needn't, but probably you should. In most cases default syslog.conf files either assign to important messages at least one action that won't bring those messages to your attention effectively (e.g., by sending messages to a TTY console on a system you only access via SSH), or they handle at least one type of message with too much or too little redundancy to meet your needs.

Table 1 summarizes syslog.conf syntax, facility values, severity values and action types. Note that the three main columns of this table are independent; there's no correlation between facilities, severities and actions, i.e., a message may be sent to any facility with any severity and have any allowed action performed on it. Note also that the numeric facility and severity codes are provided strictly for reference; you should not use these in syslog.conf, but you may come across them in source code or in a packet-dump of network traffic.

Table 1. Summary of syslog.conf Usage and Values

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Magneto-Optical

alsafi's picture

the drive MO i cant go it .but when i write the comand below
# ls -l
hda
.
.
.
hdc *MO
#mkdir /test
#mount /hdc/test
#cd /test
Mes. error (file system does not found)
pls can u told me what i do? very important

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState