![[Home]](gif/home6.gif)
One of the first places to look for warning or error messages is in the
UNIX syslog file (/usr/adm/syslog). How do the messages
get there? and How is it possible to customise it?
The flexible and often-overlooked syslog facility provides system administrators with fine-grained control over error messages. When used to its fullest, syslog can make the administrator's job much easier by organising log information. A well-designed, centralised logging facility also can augment security by providing a virtually incorruptible logging facility.
On Windows NT, the syslog service is emulated using the Event Log.
Unix utilities and your own applications (including scripts) can use the syslogd daemon to send messages. Each message sent to syslog has a facility and a priority associated with it. The facility indicates which sub-system the message originated from, and the priority relates to how important the message is.
Note: The information is this guide relates specifically to SCO
Unix 3.2v5.0.x, however, syslogd is available on most Unix
platforms so the principles here will apply.
Facilities recognised by /etc/syslogd are defined in the
array facilitynames and priority levels in the array
prioritynames both contained in /usr/include/sys/syslog.h
| Facility | Numeric (<<3) | Messages from |
|---|---|---|
| kern | 0 | the kernel. |
| user | 1 | user processes. (This is the default facility if none is
specified in /etc/syslog.conf)
|
| 2 | the mail system. | |
| daemon | 3 | system daemons. |
| auth | 4 | programs that authenticate users' primary and secondary authorisations. |
| syslog | 5 | generated internally by syslogd. |
| lpr | 6 | the line printer spooling system. |
| news | 7 | the network news system. |
| uucp | 8 | programs that deal with UUCP. |
| cron | 9 | cron. |
| authpriv | 10 | programs that authenticate users' system privileges. |
| local0 -- local7 | 16 - 23 | reserved for local use through |
| mark | Timemarks generated internally by syslogd every 20 minutes (The interval may be changed using the -m option. ) |
| Priority levels | Numeric | Relates to |
|---|---|---|
| emerg | 0 | Highest priority: a panic condition indicating that the system is unusable. This is normally broadcast to all users. |
| alert | 1 | A condition that should be corrected immediately, such as a corrupted system database. |
| crit | 2 | Critical conditions, for example, hard device errors. |
| err | 3 | Error conditions. |
| warning | 4 | Warning conditions. |
| notice | 5 | Conditions that are not error conditions, but may require special handling. |
| info | 6 | Information only. |
| debug | 7 | Lowest priority: information normally of use only when debugging a program. |
| none | Disable messages from the associated facilities. |
The way in which the syslog daemon (/etc/syslogd) handles
messages is defined in the configuration file /etc/syslog.conf
(can be changed with the -f option). The syntax is simple.:
The first part is a list of facility and priority pairs (the selectors)
separated by semicolons, for example *.notice;mail.info.
You can specify multiple facilities if they are separated via commas
e.g. kern,mark.debug which is the same as
kern.debug;mark.debug.
The second part is an action. The action field describes where the message is to be logged if the line is selected, action can take one of the following forms:
| Action | What |
|---|---|
| pathname | Open the specified file or device file in append mode;
The file must already exist the file must be specified by an absolute pathname beginning with a leading slash (/). |
| @hostname | Forward selected messages to syslogd on the host named by hostname. |
| user[,user]... | Write selected messages to the comma-separated list of users if they are logged in. |
| * | Write selected messages to all logged-in users. |
To be logged, the incoming message must have come from the named facility and must have a priority equal to or higher than the one listed in syslog.conf. For example, the pair mail.warning will match any syslog message from the mail (facility) sub-system with priority warning or higher (e.g. err, crit, alert and emerg).
The asterisk can be used to indicate all facilities, so *.info specifies all logged messages at priority level info and higher for all facilities.
The level none can be used to deselect a facility, so
*.info;mail.none specifies all messages at or
above info except for mail facility messages.
Each action line will be processed in turn and if the selectors match the action will be taken. This can lead to duplication, take the following two lines:
mail.info /usr/adm/maillog
*.debug /usr/adm/syslog
Any event from the mail facility will be logged in syslog (as
per *.debug) AND mail with a priority of info and higher (as
per mail.info) will be logged in maillog. To avoid this you should
specify mail.none on the *.debug line e.g. *.debug;mail.none
.
Some examples from the man page:
*.debug;mail.none /usr/adm/syslog
kern,mark.debug /dev/console
*.notice;mail.info /usr/adm/syslog
*.crit /usr/adm/critical
local0.* @xanth
*.emerg *
*.alert tom, katem
*.alert;auth.warning maf
There may be times when the documentation does not indicate what an event is logged as. To find this out you should switch on debugging for /etc/syslogd as follows:
/etc/syslogd -d 2>&1 >/tmp/syslog.debug &
This will log details to the file /tmp/syslog.debug as per:
logmsg: pri 56, flags 4, from xanth, msg syslogd: restart logmsg: pri 26, flags 0, from xanth, msg May 14 18:05:00 rshd[29567]: connect from xanth logmsg: pri 5, flags 4, from xanth, msg %Stp-0 - - - Vendor=HP Product=C1533A logmsg: pri 26, flags 0, from xanth, msg May 14 20:28:12 telnetd[1689]: connect from portable logmsg: pri 64, flags 0, from hplaser, msg printer: toner/ink low logmsg: pri 63, flags 0, from hplaser, msg printer: paper out logmsg: pri 26, flags 0, from xanth, msg May 15 13:27:30 popper[10233]: connect from kate logmsg: pri 25, flags 0, from xanth, msg May 15 13:27:30 popper[10233]: (v2.1.4-R3) Servicing request from "kate" at 192.168.10.88
The important piece of information is the pri xxx
Taking
logmsg: pri 25, flags 0, from xanth, msg May 15 13:27:30 popper[10233]: (v2.1.4-R3) Servicing request from "kate" at 192.168.10.88
as an example, this entry came from the popper program and was logged at level 25. The level is in octal.
You should be aware, that when running with the -d option not all events will be logged. Some events (timemarks) are generated by alarm calls to syslogd and these are disabled in this mode. Take care when looking at the log file as all (normal) events are reported as being received even if they are later discarded and it is easy to think a change to syslog.conf has not worked.
Using this information you can configure your system so that the correct events are logged in the correct files e.g.
# TCP Wrappers - Normally logged under mail - change in tcpd Makefile local0.* /usr/adm/tcpdlog # Make sure the popper messages go else where mail.info /usr/adm/maillog # Keep an eye on local scripts by sending to testbox local7.* @testbox # Everything except mail and tcpd messages to syslog *.debug;mail,local0.none /usr/adm/syslog
An administrator in charge of a network of UNIX machines needs to centralise the logs. It is much easier to check for abnormalities on one machine than on 30. Allocate one of the server's to be the central 'loghost' and configure syslog on that host to suit your needs. Then change all other hosts to redirect logging information to loghost.
This can be done with a single line in syslog.conf:
*.debug @loghost
If you feel some messages need to be logged on the local machine or to the console, put in configuration lines for those.
Note: Some versions of syslogd may need an additional flag to indicate that they should listen for remote requests (usually on port 514) - refer to the man page for details.
In addition to having Unix utilities log information you can, by using the logger (C) (and syslogd(SLIB)) include commands in your own programs and shell scripts routines to add syslog entries.
Examples
Log messages as priority level info in the local3 facility:
logger -p local3.info "Database Validation Carried Out"
While the man page indicates you can use either the 'numeric option (
<number>)' or 'Symbolic (<facility.priority>)' in message
text e.g. logger "<local0.debug> foobar failed" -
you can't. All messages sent to syslog via logger will be at
user.info unless the -p option is used. Any text passed to
logger will be included in syslog unchanged.
If you must use the <number> option then you can write directly to
the device /dev/logfifo e.g.
Numeric priorities are generated by :
facility * 8 + priority
e.g. mail.info = 2 * 8 + 6 = 22
The string ``%m'' within a message is replaced by the current error message (corresponding the global error number, errno): e.g.
logger -p local0.debug "foobar failed with reason: %m"
If a message is not specified, the contents of the file specified using the -f option are logged; otherwise, the standard input is logged until EOF is encountered. The other useful option is -t for tag. e.g. The tag will appear before the message, if the -t option is not used then it will default to your user id. For example:
logger -p local0.notice -t OPER -f /tmp/msg
If changes have been made to /etc/syslogd.conf then you need
to "refresh" the syslog daemon so it notices them.
This is done by sending a "hangup" (HUP) signal to the syslog daemon. The easy way to do this is to do a "kill -1" with the syslog daemon's process ID (PID) number. e.g.
# ps -ef | grep syslog
root 16091 1 0 May-15 ? 00:00:00 /etc/syslogd
root 17200 17199 3 13:45:52 ttyp3 00:00:00 grep syslog
# kill -1 16091
At that point you should have your first message(s) logged. It will say something to the effect that the "syslog has restarted".
For instance, on SCO OpenServer Release 5:
May 17 13:45:59 testbox syslogd: re-initialise
May 17 13:45:59 testbox syslogd: restart
If you see something like this in your syslog file, then you know that
logging is working.
Syslog is underutilised at many installations. Its ability to log events to different files and forward to remote systems can vastly improve pro-active management of a network. Used in conjunction with programs such as TCP Wrappers you can have centralised security logging that is difficult to foil.