How to configure the syslog.conf file?
Note: Still needs edition for mediawiki. Coming soon.
One of the most neglected area of Unix is handling system events. Daily checks for system messages is crucial for the security and health conditions of a computer system.
System logs contain much "noise" - messages which have no importance - and on the contrary important events, which should not be lost in the load of messages. With current tools it's difficult to select which messages we are interested in.
A message is sent to different destinations based on the assigned facility/priority pair. There are 12+8 (12 real and 8 local) predefined facilities (mail, news, auth etc.), and 8 different priorities (ranging from alert to debug).
BSD syslog protocol is defined in RFC 3164 (rfc3164) - The BSD Syslog Protocol A good summary of RFC can be found in Introduction to Syslog Protocol - MonitorWare
Syslog uses target UDP port 514. RFC recommends that source port also be set to 514.
syslog uses the user datagram protocol (UDP) [1] as its underlying transport layer mechanism. The UDP port that has been assigned to syslog is 514.
It is RECOMMENDED that the source port also be 514 to indicate that the message is from the syslog process of the sender, but there have been cases seen where valid syslog messages have come from a sender with a source port other than 514. If the sender uses a source port other than 514 then it is RECOMMENDED and has been considered to be good form that subsequent messages are from a single consistent port.
It its pure form it is an outdated, insecure (if used with central logging host, as it actually should be used in any modern enterprise environment) and rather primitive logging mechanism that lucks the flexibility of dynamically extending message classification scheme. A better scheme was proposed in 2004 syslog-1 but tremendous amount of inercia prevent any changes.
The fixed classification scheme with just a dozen of entries is a major problem with the protocol. Messages severity classification also can be improved/simplified (IBM has a better classification on mainframes) but even in present form it is an OK solution.
There are two slightly better, more modern implementation of traditional syslog daemon called syslog-ng and kiwi syslog. Syslog-ng is a better implementation if you wish to integrate Tivoli log preprocessing. It is also portable between different platforms. I do not know why Sun did not replaced the traditional syslog with syslog-ng in Solaris 10 (after all they discarded pretty usable own firewall in favor of IP Filter). It probably should consider this move.
Standard Solaris syslog system consists of the following components:
syslogd — the system daemon used to receive and route system log events from syslog() calls and logger commands
/etc/syslog.conf — the configuration file used to control the logging and routing of system log events
logger — a UNIX command used to add single-line entries to the system log. See also ogger
syslog() — an application program interface (API) referenced by several standard system utilities and available to anyone writing software in the C programming language, C++, Java and many scripting languages (Perl is one example).
logadm -- System Log Rotation Utility (Solaris 9 and later)
The key file that is influencing syslog behavior is /etc/syslog.conf file. It contains two colums called the selection and action.
selector field: a semicolon-separated list of priority specifications in the following format: facility.level; facility.level. action field: defines where to forward the message. This field can have one or several of the following entries four types of entries: file Output sent to the file specified @host The @ sign denotes that messages must be forwarded to a host The name should be defined in /etc/hosts and represent a remote logserver. user[,user] The user(s) (can be comma delimitated list) receive messages if they are logged in.
- All logged in users will receive messages when they are logged in.
As typical for Sun the file has a dinosaur (pre-70th style) syntax, as it does not permit using spaces as a separator, tabs should be used as a separator between two columns of syslog.conf. Now let's discuss those two columns is some details:
The selector field is a semicolon-separated list of priority specifications in the following format: facility.level; facility.level.
The facility field can contain only 16 codes:
kern Messages generated by the kernel. user Messages generated by user processes. This file does not list the default priority for messages from programs or facilities. mail The mail system. daemon System daemons, such as the in.ftpd and the telnetd daemons. auth The authorization system, including the login, su, and ttymon commands. syslog Messages generated internally by the syslogd daemon. lpr The line printer spooling system, such as the lpr and lpc commands. news Files reserved for the USENET network news system. uucp The UNIX-to-UNIX copy (UUCP) system does not use the syslog function. cron The cron and at facilities, including crontab, at, and cron. local0-7 Fields reserved for local use. the level selector specifies the severity or importance of the message. Each level includes all the levels above (of a higher severity). To remember the sequence for the certification exam you can use an appropriately constructed phase like "Every alerted cardriver escapes warning notice" emerg 0 Panic conditions that are normally broadcast to all users alert 1 Conditions that should be corrected immediately, such as a corrupted system database. Only sysadmin of a particular server needs to be informed by mail or paged. crit 2 Warnings about critical conditions, such as hard device errors. err 3 Errors other than hard device errors warning 4 Warning messages notice 5 Non-error conditions that might require special handling info 6 Purely informational messages (usually does not require any handling) debug 7 Messages that are normally used only when debugging a program none 8 Messages are not sent from the indicated facility to the selected file After making any changes to syslog.conf file, you need to ask the daemon to reread the configuration file with kill -HUP command, for example pkill -HUP syslogd. This is an operation that is often forgotten. It might make sense to implement "system configuration" attribute that can automatically send executes a command after closing of the file with such attribute if it was opened for writing (Unix has "command execution string" for scripts forever, for example #!/usr/bin/perl, so it can be used for configuration files). In the absence of such facility that would be a real paradise for absent minded people like me you probably will be better off creating a special script, like visyslog that contains just two command: vi and pkill to ensure that you do not forget this operation; I often do and then face consequences)
The default Solaris syslog configuration (/etc/syslog.conf) is far from being optimal (any selector in /etc/syslog.conf means "this level and higher", for example mail.crit includes mail.emerg):
- .err;kern.notice;auth.notice /dev/sysmsg
- .err;kern.debug;daemon.notice;mail.crit /var/adm/messages
- .alert;kern.err;daemon.err operator
- .alert root
- .emerg *
- if a non-loghost machine chooses to have authentication messages
- sent to the loghost machine, un-comment out the following line:
- auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost)
mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost)
- non-loghost machines will use the following lines to cause "user"
- log messages to be logged locally.
ifdef(`LOGHOST', , user.err /dev/sysmsg user.err /var/adm/messages user.alert root, operator user.emerg * )
For one thing, AUTH messages don’t get logged to any logfiles. This is important if you want to know when people are trying to break into your system so such messages should be emailed at least to operator (may be operator and root) and written to /var/adm/authlog
- .emerg *
- .kernel.notice;*.alert root,operator
- .err;kern.notice;auth.notice /dev/sysmsg
- .notice /var/adm/messages
auth.notice /var/adm/authlog, /var/log/messages
Each line of the file contains two parts:
A selector that specifies which kinds of messages to log (e.g., all error messages or all debugging messages from the kernel).
An action field that says what should be done with the message (e.g., put it in a file or send the message to a user's terminal).
!
You must use the tab character between the selector and the action field. If you use a space, it will look the same, but syslog will not work.
Message selectors have two parts: a facility and a priority. kern.debug, for example, selects all debug messages (the priority) generated by the kernel (the facility). It also selects all priorities that are greater than debug. An asterisk in place of either the facility or the priority indicates "all." (That is, *.debug means all debug messages, while kern.* means all messages generated by the kernel.) You can also use commas to specify multiple facilities. Two or more selectors can be grouped together by using a semicolon. (See the earlier examples.)
The action field specifies one of five actions (some versions of syslog support additional actions, such as logging to a proprietary error management system):
Log to a file or a device In this case, the action field consists of a filename (or device name), which must start with a forward slash (e.g., /var/adm/lpd-errs or /dev/console). Beware: logging to /dev/console creates the possibility of a denial of service attack. If you are logging to the console, an attacker can flood your console with log messages, rendering it unusable. If your system supports virtual consoles, as with Linux, you can usually safely log to one of the virtual consoles, and leave the others uncluttered.
Send a message to a user. In this case, the action field consists of a username (e.g., root). You can specify multiple usernames by separating them with commas (e.g., root,nosmis). The message is written to each terminal where these users are shown to be logged in, according to the utmp file.
Send a message to all users. In this case, the action field consists of an asterisk (*).
Pipe the message to a program . In this case, the program is specified after the Unix pipe symbol (|). Note that the current Solaris version syslog does not support logging to programs. You need to use syslog-ng to achieve that.
Send the message to the syslog on another host. In this case, the action field consists of a hostname preceded by an at sign (e.g., @prep.ai.mit.edu). With the following explanation, understanding the typical syslog.conf configuration file shown earlier becomes easy:
- .err;kern.debug;auth.notice /dev/console
This line causes all error messages, all kernel debug messages, and all notice messages generated by the authorization system to be printed on the system console. If your system console is a printing terminal, this process will generate a permanent hardcopy that you can file and use for later reference. (Note that kern.debug means all messages of priority debug and above.)
daemon,auth.notice /var/log/messages This line causes all notice messages from either the system daemons or the authorization system to be appended to the file /var/log/messages. Note that this is the second line that mentions auth.notice messages. As a result, auth.notice messages will be sent to both the console and the messages file.
lpr.* /var/log/lpd-errs This line causes all messages from the line printer system to be appended to the /var/log/lpd-errs file.
auth.* root,nosmis This line causes all messages from the authorization system to be sent to the users root and nosmis. Note, however, that if the users are not logged in, the messages will be lost.
auth.* @prep.ai.mit.edu This line causes all authorization messages to be sent to the syslog daemon on the computer prep.ai.mit.edu. If you have a cluster of many different machines, you may wish to have them all perform their loggings on a central (and presumably secure) computer.
- .emerg *
This line causes all emergency messages to be displayed on every user's terminal.
- .alert |dectalker
This line causes all alert messages to be sent to a program called dectalker, which might broadcast the message over a public address system.
mark.* /dev/console This line causes the time to be printed on the system console every 20 minutes. This is useful if you have other information being printed on the console, and you want a running clock on the printout.
