Lemur zaprasza
Linux: A Network Solution for Your Office ContentsIndex Chapter 16: Logs: The System Log Previous ChapterNext Chapter Sections in this Chapter: The System Log Log Maintenance Boot Notification Summary Reading the Log Files Manual Pages Other Log Files Previous SectionNext Section Chapter 16 Logs Whether you're trying to diagnose a problem, catch an attacker trying to gain access to your system, or just monitor your system's health, the primary tools you'll use are the various system logs. Their importance cannot be overstated. In order to manage a Linux server effectively and with confidence, it's important that you become thoroughly familiar with the logs generated on your system and are able to read them so as to locate messages of importance with ease. The System Log Log Messages Configuring syslogd Running syslogd Kernel Logging Logging over the Network Most UNIX systems provide a general-purpose log facility that can be used by the operating system itself as well as by any application programs. This facility is called the system log . In Linux, the system log is under the control of a special-purpose server program--the syslog daemon, syslogd. Log Messages By convention, most log messages are placed in the file /var/log/messages. This file contains lines similar to these: Apr 12 22:25:03 host syslogd 1.3-3: restart. Apr 12 22:25:05 host kernel: klogd 1.3-3, log source = /proc/kmsg started. Apr 12 22:25:06 host xntpd[347]: xntpd 3-5.91 Wed Aug 19 06:20:55 MST 1998 Apr 12 22:25:06 host cron[353]: (CRON) STARTUP (fork ok) As you can see, every line in the log file begins with a date and time stamp. The next field is the name of the computer where the log message originated. Most of the time, this will simply be the name of your Linux system; however, if you permit logging over the network, other computer names may show up here as well. The computer name is followed by the name of the application that generated the log message. The application's numeric process identifier is also shown in square brackets. Finally, the actual message is printed. Running syslogd The Linux system log server program is called syslogd, and it's usually started along with other system daemons at boot time. The function of syslogd is simple: It listens for incoming messages and places these messages in the appropriate file. If your system doesn't have a running copy of syslogd, you can start it by typing syslogd as the root user. (Since syslogd might not be on your default path, it might be necessary to precede it with a full path name, for instance /usr/sbin/syslogd.) This command can be added to your system initialization files in /etc/rc.d to ensure that syslogd is started when the system boots. Logging over the Network In addition to logging local events, the system log facility can also log events from across the network. Because this capability clearly provides a means to abuse your system (if a malicious hacker or malfunctioning computer begins sending massive amounts of syslog messages to your system, you have a problem), it's turned off by default. You can turn it on by changing the way syslogd starts; simply add the -r command-line switch to the syslogd startup command. This command-line switch instructs syslog to not only listen to local messages, but also to messages that come in across the network through UDP port 514. (See Chapter 5, "Internet Concepts," for more information about TCP and UDP ports.) Warning - Before using the -r switch with the syslogd command, you must understand that there's no way to make syslogd selectively listen only to messages coming in from certain computers. Any computer on the network can send log messages to a server that runs the syslog utility with this switch. Therefore, if your system is connected to the Internet (especially if it's permanently connected), you should filter any incoming data that's coming from an outside source and is directed at UDP port 514. For more information about packet filtering, see Chapter 11, "Firewalls." Configuring syslogd The fact that syslogd listens for incoming log messages is obviously only one part of the equation. Where do the received messages go? The answer is simple: The behavior of syslogd is controlled by the contents of the file /etc/syslog.conf. This configuration determines how incoming messages are processed and into which log files they'll be deposited. Log messages can be selectively processed because, in addition to what you see in the log file, each log message has two additional attributes: a facility identifier (see Table 16.1) and a priority level (Table 16.2). TABLE 16.1 Syslog Facility Identifiers Facility Description auth Security/authorization messages authpriv Security/authorization messages (private) cron Clock daemon daemon System daemons kern Kernel messages lpr Line printer subsystem Mail system mark Reserved for internal use news Network news subsystem syslog Messages generated internally by syslogd user Random user-level messages uucp UUCP subsystem local0 through local7 Locally defined use Table 16.2 Syslog Priority Identifiers Priority Description debug Debug-level messages. info Informational. notice Normal but significant conditions. warning Warning conditions. err Error conditions. crit Critical conditions. alert Action must be taken immediately. emerg System is unusable. These identifiers in the two tables are used in /etc/syslog.conf to specify how specific message types are to be processed. Each line in /etc/syslog.conf looks like this: facility.priority action The facility and priority fields contain keywords from Tables 16.1 and 16.2, respectively. The action field determines how messages of the selected type will be processed. It's possible to specify multiple facilities, separated by commas, or to use a single asterisk to mean all facilities . In the priority field, a single keyword means all messages of the specified priority and above . However, you can precede priority keywords with an equal sign (meaning only the specified priority). The priority (with or without the equal sign) can also be preceded by an exclamation mark, which negates its meaning. For instance, !warning means only priorities lower than warning, and !=emerg means all priorities except emerg. The action field can contain any one of the following: A full pathname, in which case messages of the specified type are written to the file specified by this path An "at" sign ( @) followed by the network address of a machine that's configured to receive syslog messages A user or list of users (separated by commas) or all currently logged on users ( *) The name of a device such as a console or a named pipe Warning - The action field must be separated from the facility.priority part using tab characters (space characters will not work on most systems)! Note - In order to guarantee the integrity of log files in case of a system crash, syslogd always flushes the contents of a log file to disk every time the file is written to. This ensures that no data remains cached in memory in case of a crash; however, this behavior incurs a performance penalty. To prevent syslogd from flushing a particular log file, precede the file's name with a minus sign in /etc/syslog.conf. Caldera OpenLinux, as installed on my test system, comes with a preconfigured syslog.conf file that contains the following configuration lines: *.info;news,mail,authpriv,auth.none -/var/log/messages authpriv.*;auth.* /var/log/secure mail.* /var/log/mail news.* /var/log/news.all uucp,news.err /var/log/spooler *.emerg * This configuration is fine; it works well for most purposes. However, I decided to add one line to ensure that error messages are logged to another host on my network as well: *.err @192.168.1.2 Needless to say, the host specified here is also equipped with a running copy of syslogd--one that has been configured to accept log messages over a network connection. Kernel Logging A special category of log messages is reserved for those generated by the Linux kernel. By default, these messages are printed on the console, which can be quite disturbing when they pop up while you're editing a critical file, for instance. There isn't a need to see most kernel messages immediately; quite a few of them are just informational messages, such as those telling you that the CD in your CD-ROM drive has been changed. Kernel log messages can be redirected to the system log using the kernel log daemon, klogd. This daemon is usually started along with syslogd at system boot time. When this daemon is running, all kernel messages except "panics" (messages indicating a catastrophic system failure) will be redirected to the system log instead of being displayed on the console. The most recent kernel messages can also be viewed at any time using the dmesg command. The kernel keeps a fixed-size internal buffer in which it stores the messages it generates; when the buffer becomes full, it's reused from the beginning in a circular fashion (which is why it's called a ring buffer ). The dmesg command simply lists the contents of this buffer. Optionally, it can also be used to clear the contents of the buffer. (Note that it will not remove any messages that have been sent to the system log.) Linux: A Network Solution for Your Office ContentsIndex Chapter 16: Logs: The System Log Previous ChapterNext Chapter Sections in this Chapter: The System Log Log Maintenance Boot Notification Summary Reading the Log Files Manual Pages Other Log Files Previous SectionNext Section © Copyright Macmillan USA. All rights reserved. |