UNIX System Administration Handbook - Evi Nemeth [137]
Note the last line of the excerpt, which complains of a message being repeated 100 times. To help keep the logs shorter, syslog generally attempts to coalesce duplicate messages and replace them with this type of summary. However, the machine from which this example was drawn accepts log entries from many other hosts, so this particular message is a bit misleading, It actually refers to the previous log entry from av18, not the entry immediately preceding it in the composite log.
It’s a good idea to peruse your log files regularly. Determine what is normal so that when an anomaly occurs, you can recognize it. Better yet, set up a log postprocessor such as swatch to trap these cases automatically; see Condensing log files to useful information on page 222.
Designing a logging scheme for your site
At a small site it is adequate to configure logging so that important system errors and warnings are kept in a file on each machine, much as was done before we had syslog. The syslog.conf file can be customized for each host.
On a large network, central logging is essential. It keeps the flood of information manageable and, with luck, makes auditing data unavailable to a person who violates the security of a machine on the network. Hackers often edit system logs to cover their tracks; if log information is whisked away as soon as it is generated, it is much harder to destroy. But be aware that anyone can call syslog and fake log entries from any daemon or utility. Syslog also uses the UDP protocol, which is not guaranteed to be reliable; messages can get lost. Your firewall should not allow external sites to submit messages to your syslogd.
Choose a stable machine as your logging server, preferably one that is well secured and does not have many logins. Other machines can use a generic configuration file that is maintained in a central place. Thus, only two versions of the syslog.conf file need be maintained.5
This approach allows logging to be complete but at the same time is not a nightmare to administer.
See Chapter 18 for more information about distributing files on a network.
Some very large sites may want to add more levels to the logging hierarchy. Unfortunately the current version of syslog retains the name of the originating host for only one hop. If host “client” sends some log entries to host “server,” which sends them on to host “master,” master will see the data as coming from server, not from client.
Software that uses syslog
Table 11.7 lists some of the programs that use syslog, the facilities and levels they log to, and a brief description of each program. Some rows have been shaded to improve readability.
Table 11.7 Software that uses syslog
With all this information, it should be perfectly clear which messages to keep and which to discard, right? Well, maybe not. In practice, you just have to learn what the useful logging levels are for your system. It’s best to start with an excessive amount of logging and gradually winnow out the cases that you don’t want. Stop winnowing when you feel comfortable with the average data rate.
Debugging syslog
The logger command is useful for submitting log entries from shell scripts. You can also use it to test changes in syslogd’s configuration file. For example, if you have just added the line
local5.warning /tmp/evi.log
and want to verify that it is working, run
% logger -p local5.warning "test message"
A line containing “test message” should be written to /tmp/evi.log. If this doesn’t happen, perhaps you forgot to create the evi.log file, to give the file appropriate permissions, or to send syslogd a hangup signal.
Early versions of syslogd have a fixed constant, NLOGS, that determines the total number of actions that can be specified in the configuration file. It is usually set to 20. If you exceed this number, syslogd ignores the extra actions and quietly throws