Chris Tyler - Fedora Linux

Jun 1 02:52:33 darkday named[13255]: zone localdomain/IN: loaded serial 42

Jun 1 02:52:33 darkday named[13255]: zone localhost/IN: loaded serial 42

Jun 1 02:52:33 darkday named[13255]: running

Jun 1 02:57:22 bluesky chris: VNC service configured, restarting xinetd

Jun 1 02:57:29 bluesky xinetd[15394]: Exiting...

Jun 1 02:57:29 bluesky xinetd[15452]: xinetd Version 2.3.13 started with libwrap loadavg options compiled in.

Jun 1 02:57:29 bluesky xinetd[15452]: Started working: 1 available service

Notice that this log contains entries from darkday (the syslog server) as well as from bluesky (which is forwarding log messages to darkday ). Notice also the system administrator's note on bluesky , stating the reason that xinetd was being restarted.

There's not much point in collecting all this information if the logs are never read, but reading logfiles is boring, tedious work. Fortunately, the logwatch package automates this process, sending a daily summary email to alert you to important log entries.

The daily summary is emailed to root on the local machine. Email to the root user should be redirected to a specific user or users by the /etc/aliases file. Edit this file and uncomment the entry for root found at the the end, inserting the name of a user who is responsible for administering the system (or a list of people separated by commas). In this example, all mail for root is redirected to chris@fedorabook.com :

# Person who should get root's mail

root: chris@fedorabook.com

Here is a typical daily logwatch summary:

From: root

To: root@bluesky.fedorabook.com

Subject: LogWatch for bluesky.fedorabook.com

Date: Wed, 31 May 2006 04:02:17 -0400

################### LogWatch 7.1 (11/12/05) ####################

Processing Initiated: Thu Jun 1 02:52:14 2006

Date Range Processed: yesterday ( 2006-May-31 )

Period is day.

Detail Level of Output: 10

Type of Output: unformatted

Logfiles for Host: bluesky.fedorabook.com

##################################################################

--------------------- httpd Begin ------------------------

A total of 3 unidentified 'other' records logged

GET /level/16/exec/-///pwd HTTP/1.0 with response code(s)

2 404 responses

POST /garethjones/photos/--WEBBOT-SELF-- HTTP/1.0 with response code(s)

1 404 responses

GET http://bluesky.fedorabook.com/foo HTTP/1.1 with response code(s)

1 404 responses

---------------------- httpd End -------------------------

--------------------- SSHD Begin ------------------------

Users logging in through sshd:

chris:

172.16.97.2: 3 times

--------------------- SSHD End -------------------------

--------------------- Disk Space Begin ------------------------

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/main-root 9.5G 2.9G 6.1G 33% /

/dev/hda1 99M 9.7M 84M 11% /boot

/dev/mapper/main-home 4.9G 24M 4.7G 1% /home

---------------------- Disk Space End -------------------------

###################### LogWatch End #########################

This report will vary according to the services you have installed, but it provides a simple, easy-to-scan summary of log entries that may warrant attention. It also provides a summary of free disk space; if you methodically review these email messages, you won't be caught unaware when your storage needs start to inch upward.

Logfiles can grow to be massive. The Fedora logrotate package automatically moves historical log data into history files and keeps a limited number of history files on hand.

logrotate is configured through the master configuration file /etc/logrotate.conf :

# see "man logrotate" for details

# rotate log files weekly

weekly

# keep 4 weeks worth of backlogs

rotate 4

# create new (empty) logfiles after rotating old ones

create

# uncomment this if you want your logfiles compressed

#compress

# RPM packages drop log rotation information into this directory

include /etc/logrotate.d

# no packages own wtmp -- we'll rotate them here

/var/log/wtmp {

monthly

create 0664 root utmp

rotate 1

}

# system-specific logs may be also be configured here.

The most frequently altered lines are highlighted in bold: logrotate is initially configured to rotate logs every week and to save the last four historical logfiles in addition to the current log. If you have a lot of storage and wish to keep more history, edit the rotate line to increase the number of history files maintained, or change the weekly line to monthly to reduce the frequency of history snapshots (which can make it easier to analyze patterns over a longer period of time without merging data from several files).

The default configuration results in five separate message files being present on the system:

$ ls -l /var/log/messages*

-rw------- 1 root root 86592 Jun 1 02:49 /var/log/messages

-rw------- 1 root root 85053 May 30 02:03 /var/log/messages.1

-rw------- 1 root root 105491 May 26 23:51 /var/log/messages.2

-rw------- 1 root root 74062 May 7 04:12 /var/log/messages.3

-rw------- 1 root root 286194 May 2 13:00 /var/log/messages.4

logrotate also uses per-logfile configuration files in /etc/logrotate.d . These files are installed by various RPM packages that generate logfiles.

The main system logging utility is named syslog . It is network-based and uses a server daemon, syslogd , which receives messages from all sorts of system programs through the Unix domain socket /var/log . These messages are matched against the lines in /etc/syslog.conf and written to the selected destinations.

Kernel messages are stored in a buffer that is read by a helper daemon named klogd , either by reading the file /proc/kmesg or by using a kernel system call. klogd then forwards these messages to syslogd for inclusion in the system logs.

A syslog network server listens to UDP port 514 and processes any messages received there through the normal routing decisions.

One significant problem with the syslog implementation is that there is absolutely no authentication performed. Any application can log any message with any facility and priority. Therefore it is relatively easy to spoof log messages or to create a denial-of-service attack by sending huge numbers of logfile entries, eventually filling all available disk space and making it impossible to log further events. (For this reason, it is a good idea to use a separate filesystem for /var/log ).