The candidate should be able to configure the logging daemon to act as a central network log server. This objective also includes configuring the logging daemon to send log output to a central log server, logging remote connections and using grep and other text utilities to automate log analysis.
Key files, terms and utilities include:
syslog.conf |
sysklogd |
syslog-ng |
/etc/hosts |
Resources: the man pages of syslogd(1), klogd(1) and syslog.conf(5). The syslog-ng 2.0 reference manual.
The acronym ng in syslog-ng stands for `Next Generation' and is a replacement for sys(k)logd. Syslog-ng adds the posibility to filter (regular expressions) messages based on the content of the messages in addition to the priority/facility pair. The use of a long hostname format that appends the next loghost hostname to the hostname which in the end contains a chain of hostnames. Provide a clean and powerful configuration format and offers support for messages originating from different timezones.
Note: The klogd daemon processes kernel messages and can be used to forward messages to the syslog-ng daemon. Though this is not recommended because syslog-ng can use the proc filesystem to process kernel messages. There is no need to run klogd and syslog-ng at the same time.
Sysklogd is an enhanced version of the standard Berkeley utility program which is used on Linux systems. It is responsible for logging messages received from programs and facilities on the local host, as well as from remote hosts.
Sysklogd includes two system utilities syslogd and klogd, which support system logging and kernel message trapping. Support of both internet and unix domain sockets enables this utility package to support both local and remote logging.
syslogd provides the kind of logging that
is used by many modern programs. Every logged message
contains at least a time, a hostname and, usually, a program
name field. (See the
syslog(3) manual page for
information on generating messages)
Rules in /etc/syslog.conf specify where
messages should go. An example syslog.conf entry is shown
below:
# Sample syslog.conf daemon.warning /var/log/daemon.log
In this example messages of priority
warning and higher, from processes that use the facility
daemon, will be sent to the file
/var/log/daemon.log.
The new scheme adds four new specifiers. The asterisk (*) wildcard, the equation sign (=), the exclamation mark (!), and the minus sign (-).
The * specifies that all messages for the specified facility are to be directed to the destination. Note that this behaviour is degenerate with specifying a priority level of debug. Users have indicated that the asterisk notation is more intuitive.
The = wildcard is used to restrict logging to the specified priority class. This allows, for example, routing only debug messages to a particular logging source. For example the following line in syslog.conf would direct debug messages from all sources to the /usr/adm/debug file.
# Sample syslog.conf
*.=debug /usr/adm/debug
The ! is used to exclude logging of the specified priorities. This affects all (!) possibilities of specifying priorities. For example the following lines would log all messages of the facility mail except those with the priority info to the /usr/adm/mail file. And all messages from news.info (including) to news.crit (excluding) would be logged to the /usr/adm/news file.
# Sample syslog.conf
mail.*;mail.!=info /usr/adm/mail
news.info;news.!crit /usr/adm/news
You may use it intuitively as an exception specifier. The above mentioned interpretation is simply inverted. Doing that you may use:
mail.none
or
mail.!*
or
mail.!debug
to skip every message that comes with a mail facility.
The - may only be used to prefix a filename if you want to omit sync'ing the file after every write to it. This may take some acclimatization for those individuals used to the pure BSD behaviour but testers have indicated that this syntax is somewhat more flexible than the BSD behaviour. Note that these changes should not affect standard syslog.conf(5) files. You must specifically modify the configuration files to obtain the enhanced behaviour.
The facility specifies the subsystem that produces the message. The following list contains all possible syslog facilities.
The priority is one of the following keywords, in ascending
order: debug,
info, notice,
warning, err,
crit, alert,
emerg. The priority defines the
severity of the message. The standard behaviour is that all
messages of the specified priority and higher are logged to
the given action.
The second field is the “logfile”, but it need not be a regular file. The syslogd provides the following actions:
Typically messages are logged to real files. The file has to be specified with the full pathname, beginning with a slash ('/').
You may prefix an entry with the minus ('-') sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right after a write attempt. Nevertheless, this might give you back some performance, especially if you run programs that use logging in a very verbose manner.
If the file you specified is a tty, special
tty-handling is done, same as with
/dev/console.
syslogd provides full remote logging, that is, it is able to send messages to a remote host running syslogd and to receive messages from remote hosts. The remote host won't forward the message again, it will just log them locally. To forward messages to another host, prepend the hostname with the at sign ('@'):
# Send all logging to a remote machine *.* @remote
Using this feature, you're able to control all syslog messages on one host, assuming all other machines log remotely to that host. This makes administration easier.
If the remote hostname cannot be resolved at startup
because the name-server is inaccessible (perhaps it
is started after
syslogd), no need to worry:
syslogd will retry ten times
before complaining. One way to avoid this is to
place the hostname in
/etc/hosts.
Note that you have to start the central logging
server with the -r option to enable
this. By default, syslogd doesn't
listen to the network. Also note that
syslogd has no facility to split
log messages from different hosts to different
files.
Usually, critical messages are also directed to “root” on the host machine. You can specify a list of users who get the message by simply writing their login names. You may specify more than one user by separating them with commas (',').
# Messages of the priority alert will be directed to root and joey *.alert root,joey
If they're logged in, they get the message. An e-mail will not be sent, because, by the time it arrives, it might be too late.
Emergency messages often should go to all users currently online to notify them that something strange is happening with the system. To specify this wall-feature, use an asterisk ('*').
klogd is a system daemon which intercepts and logs linux kernel messages.
The kernel log information is gathered from either the
/proc filesystem or from the syscall
interface.
Although klogd has the option of sending
the log messages directly to a file, the default behaviour is
to send the messages to syslogd using the
kern facility.
Syslog-ng consist of a daemon binary and the configuration
file syslog-ng.conf. Normally syslog-ng
is run as root. It is possible to run syslog-ng with a
non-root user if the log files and directories are writeable
and the daemon doesn't use a privileged port.
The configuration for logging messages is made up of three parts. The source, destination and filter rules. The source can be configured to use the following drivers.
The destination can be configured to use the following drivers.
Filters can be made up of facility, level, regular expressions, another filter and subnet checking. The regular expressions can be used on the name of the host, program, message, filter and netmask checking.