CATEGORII DOCUMENTE |
DOCUMENTE SIMILARE |
|||||||
|
|||||||
Troubleshooting Linux with syslog
Introduction
There are hundreds of Linux applications on the market, each with their own configuration files and help pages. This variety makes Linux vibrant, but it also makes Linux system administration daunting. Fortunately, in most cases, Linux applications use the syslog utility to export all their errors and status messages to files located in the /var/log directory.
This can be invaluable in correlating the timing and causes of related events on your system. It is also important to know that applications frequently don't display errors on the screen, but will usually log them somewhere. Knowing the precise message that accompanies an error can be vital in researching malfunctions in product manuals, online documentation, and Web searches.
syslog, and the logrotate utility that cleans up log files, are both relatively easy to configure but they frequently don't get their fair share of coverage in most texts. I've included syslog here as a dedicated chapter to both emphasize its importance to your Linux knowledge and prepare you with a valuable skill that will help you troubleshoot all the Linux various applications that will be presented throughout the book
syslog
syslog is a utility for tracking and logging all manner of system messages from the merely informational to the extremely critical. Each system message sent to the syslog server has two descriptive labels associated with it that makes the message easier to handle.
The first describes the function (facility) of the application that generated it. For example, applications such as mail and cron generate messages with easily identifiable facilities named mail and cron.
The second describes the degree of severity of the message. There are eight in all and they are listed in Table 5-1:
You can configure syslog's /etc/syslog.conf configuration file to place messages of differing severities and facilities in different files. This procedure will be covered next.
Table 5-1 Syslog Facilities
Severity Level |
Keyword |
Description |
emergencies |
System unusable |
|
alerts |
Immediate action required |
|
critical |
Critical condition |
|
errors |
Error conditions |
|
warnings |
Warning conditions |
|
notifications |
Normal but significant conditions |
|
informational |
Informational messages |
|
debugging |
Debugging messages |
The /etc/syslog.conf File
The files to
which syslog writes each type of message received is set in the /etc/syslog.conf
configuration file. This file consists of two columns. The first lists the
facilities and severities of messages to expect and the second lists the files
to which they should be logged. By default, RedHat/Fedora's /etc/syslog.conf
file is configured to put most of the messages in the file /var/log/messages
.
Here is a sample:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
In this
case, all messages of severity 'info' and above are logged, but none
from the mail, cron or authentication facilities/subsystems. You can make this
logging even more sensitive by replacing the line above with one that captures
all messages from debug severity and above in the /var/log/messages
file. This example may be more suitable for troubleshooting.
*.debug /var/log/messages
In this
example, all debug severity messages; except auth, authpriv, news and mail; are
logged to the /var/log/debug
file in caching mode.
Notice how you can spread the configuration syntax across several lines using
the slash () symbol at the end of each line.
*.=debug;
auth,authpriv.none;
news.none;mail.none -/var/log/debug
Here we see
the /var/log/messages
file configured in caching
mode to receive only info, notice and warning messages except for the auth,
authpriv, news and mail facilities.
*.=info;*.=notice;*.=warn;
auth,authpriv.none;
cron,daemon.none;
mail,news.none -/var/log/messages
You can even have certain types of messages sent to the screen of all logged in users. In this example messages of severity emergency and above triggers this type of notification. The file definition is simply replaced by an asterisk to make this occur.
*.emerg *
Certain
applications will additionally log to their own application specific log files
and directories independent of the syslog.conf
file.
Here are some common examples:
Files:
/var/log/maillog : Mail
/var/log/httpd/access_log : Apache web server page access logs
Directories:
/var/log
/var/log/samba : Samba messages
/var/log/mrtg : MRTG messages
/var/log/httpd : Apache webserver messages
Note: In some older versions of Linux the
/etc/syslog.conf file was very sensitive to spaces and would recognize only
tabs. The use of spaces in the file would cause unpredictable results. Check
the formatting of your /etc/syslog.conf
file to be safe.
Activating Changes to the syslog Configuration File
Changes to /etc/syslog.conf will not take effect until you restart syslog. Issue this command to do so:
[root@bigboy tmp]# service syslog restart
In Ubuntu / Debian systems the command would be:
root@u-bigboy:~# /etc/init.d/sysklogd restart
How to View New Log Entries as They Happen
If you want to get new log entries to scroll on the screen as they occur, then you can use this command:
[root@bigboy tmp]# tail -f /var/log/messages
Similar commands can be applied to all log files. This is probably one of the best troubleshooting tools available in Linux. Another good command to use apart from tail is grep. grep will help you search for all occurrences of a string in a log file; you can pipe it through the more command so that you only get one screen at a time. Here is an example:
[root@bigboy tmp]# grep string /var/log/messages | more
You can also just use the plain old more command to see one screen at a time of the entire log file without filtering with grep. Here is an example:
[root@bigboy tmp]# more /var/log/messages
Logging syslog Messages to a Remote Linux Server
Logging your system messages to a remote server is a good security practice. With all servers logging to a central syslog server, it becomes easier to correlate events across your company. It also makes covering up mistakes or malicious activities harder because the purposeful deletion of log files on a server cannot simultaneously occur on your logging server, especially if you restrict the user access to the logging server.
Configuring the Linux Syslog Server
By default syslog doesn't expect to receive messages from remote clients. Here's how to configure your Linux server to start listening for these messages.
As we saw previously, syslog checks its /etc/syslog.conf file to determine the expected names and locations of the log files it should create. It also checks the file /etc/sysconfig/syslog to determine the various modes in which it should operate. Syslog will not listen for remote messages unless the SYSLOGD_OPTIONS variable in this file has a -r included in it as shown below.
# Options to syslogd
# -m 0 disables 'MARK' messages.
# -r enables logging from remote machines
# -x disables DNS lookups on messages received with -r
# See syslogd(8) for more details
SYSLOGD_OPTIONS='-m 0 -r'
# Options to klogd
# -2 prints all kernel oops messages twice; once for klogd to decode, and
once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS='-2'
Note: In Debian / Ubuntu systems you have
to edit the syslog
startup script
/etc/init.d/sysklogd directly and make the SYSLOGD
variable definition become '-r
'.
# Options for start/restart the daemons
For remote UDP logging use SYSLOGD='-r'
#SYSLOGD='-u syslog'
SYSLOGD='-r'
You will have to restart syslog on the server for the changes to take effect. The server will now start to listen on UDP port 514, which you can verify using either one of the following netstat command variations.
[root@bigboy tmp]# netstat -a | grep syslog
udp 0 0 *:syslog *:*
[root@bigboy tmp]# netstat -an | grep 514
udp 0 0 0.0.0.0:514 0.0.0.0:*
[root@bigboy tmp]#
Configuring the Linux Client
The syslog server is now expecting to receive syslog messages. You have to configure your remote Linux client to send messages to it. This is done by editing the /etc/hosts file on the Linux client named smallfry. Here are the steps:
1) Determine the IP address and fully qualified hostname of your remote logging host.
2) Add an entry in the /etc/hosts file in the format:
IP-address fully-qualified-domain-name hostname 'loghost'
Example:
192.168.1.100 bigboy.my-site.com bigboy loghost
Now your /etc/hosts file has a nickname of 'loghost' for server bigboy.
3) The next thing you need to do is edit your /etc/syslog.conf file to make the syslog messages get sent to your new loghost nickname.
*.debug @loghost
*.debug /var/log/messages
You have now configured all debug messages and higher to be logged to both server bigboy ('loghost') and the local file /var/log/messages. Remember to restart syslog to get the remote logging started.
You can now test to make sure that the syslog server is receiving the messages with a simple test such as restarting the lpd printer daemon and making sure the remote server sees the messages.
Linux Client
[root@smallfry tmp]# service lpd restart
Stopping lpd: [ OK ]
Starting lpd: [ OK ]
[root@smallfry tmp]#
Linux Server
[root@bigboy tmp]# tail /var/log/messages
Apr 11
Apr 11
[root@bigboy tmp]#
Syslog Configuration and Cisco Network Devices
syslog reserves facilities 'local0' through 'local7' for log messages received from remote servers and network devices. Routers, switches, firewalls and load balancers each logging with a different facility can each have their own log files for easy troubleshooting. Appendix 4 has examples of how to configure syslog to do this with Cisco devices using separate log files for the routers, switches, PIX firewalls, CSS load balancers and LocalDirectors.
Logrotate
The Linux utility logrotate renames and reuses system error log files on a periodic basis so that they don't occupy excessive disk space.
The /etc/logrotate.conf File
This is logrotate's general configuration file in which you can specify the frequency with which the files are reused.
You can specify either a weekly or daily rotation parameter. In the case below the weekly option is commented out with a #, allowing for daily updates.
The rotate parameter specifies the number of copies of log files logrotate will maintain. In the case below the 4 copy option is commented out with a #, while allowing 7 copies.
The create parameter creates a new log file after each rotation
Therefore, our sample configuration file will create daily archives of all the logfiles and store them for seven days. The files will have the following names with, logfile being current active version:
logfile
logfile.0
logfile.1
logfile.2
logfile.3
logfile.4
logfile.5
logfile.6
Sample Contents of /etc/logrotate.conf
# rotate log files weekly
#weekly
# rotate log files daily
daily
# keep 4 weeks worth of backlogs
#rotate 4
# keep 7 days worth of backlogs
rotate 7
# create new (empty) log files after rotating old ones
create
The /etc/logrotate.d Directory
Most Linux applications that use syslog will put an additional configuration file in this directory to specify the names of the log files to be rotated. It is a good practice to verify that all new applications that you want to use the syslog log have configuration files in this directory. Here are some sample files that define the specific files to be rotated for each application.
Here is an
example of a custom file located in this directory that rotates files with the .tgz
extension which are located in the /data/backups
directory. The parameters in this file will override the global defaults in the
/etc/logrotate.conf
file. In this case, the
rotated files won't be compressed, they'll be held for 30 days only if they are
not empty, and they will be given file permissions of 600 for user root
.
/data/backups/*.tgz
Note: In Debian / Ubuntu systems the /etc/cron.daily/sysklogd
script reads the /etc/syslog.conf
file and rotates any
log files it finds configured there. This eliminates the need to create log
rotation configuration files for the common system log files in the /etc/logrotate.d
directory. As the script resides in the /etc/cron.daily
directory it automatically runs every 24 hours. In Fedora / Redhat systems this
script is replaced by the /etc/cron.daily/logrotate
daily script which does not use the contents of the syslog configuration file,
relying mostly on the contents of the /etc/logrotate.d
directory.
Activating logrotate
The above logrotate settings in the previous section will not take effect until you issue the following command:
[root@bigboy tmp]# logrotate -f
If you want logrotate to reload only a specific configuration file, and not all of them, then issue the logrotate command with just that filename as the argument like this:
[root@bigboy tmp]# logrotate -f /etc/logrotate.d/syslog
Compressing Your Log Files
On busy Web sites the size of your log files can become quite large. Compression can be activated by editing the logrotate.conf file and adding the compress option.
# File: /etc/logrotate.conf
# Activate log compression
compress
The log files will then start to become archived with the gzip utility, each file having a .gz extension.
[root@bigboy tmp]# ls /var/log/messages*
/var/log/messages /var/log/messages.1.gz /var/log/messages.2.gz
/var/log/messages.3.gz /var/log/messages.4.gz /var/log/messages.5.gz
/var/log/messages.6.gz /var/log/messages.7.gz
[root@bigboy tmp]#
Viewing the contents of the files still remains easy because the zcat command can quickly output their contents to the screen. Use the command with the compressed file's name as the argument as seen below.
[root@bigboy tmp]# zcat /var/log/messages.1.gz
Nov 15
Nov 15
Nov 15
[root@bigboy tmp]#
syslog-ng
The more recent syslog-ng application combines the features of logrotate and syslog to create a much more customizable and feature rich product. This can be easily seen in the discussion of its configuration file that follows.
The /etc/syslog-ng/syslog-ng.conf file
The main configuration file for syslog-ng is the /etc/syslog-ng/sylog-ng.conf file but only rudimentary help on its keywords can be found using the Linux man pages.
[root@zippy tmp]# man syslog-ng.conf
Figure 5-1 has a sample syslog-ng.conf file and outlines some key features. The options section that covers global characteristics is fully commented, but it is the source, destination and log sections that define the true strength of the customizability of syslog-ng.
Figure 5-1 A Sample syslog-ng.conf File
options ;
# Define all the sources of localhost generated syslog
# messages and label it 'd_localhost'
source s_localhost ;
# Define all the sources of network generated syslog
# messages and label it 'd_network'
source s_network ;
# Define the destination 'd_localhost' log directory
destination d_localhost ;
# Define the destination 'd_network' log directory
destination d_network ;
# Any logs that match the 's_localhost' source should be logged
# in the 'd_localhost' directory
log ;
# Any logs that match the 's_network' source should be logged
# in the 'd_network' directory
log ;
In our example, the first set of sources is labeled s_localhost. It includes
all system messages sent to the Linux /dev/log device, which is one of syslog's
data sources, all messages that syslog-ng views as being of an internal nature
and additionally inserts the prefix 'kernel' to all messages it
intercepts on their way to the /proc/kmsg kernel message file.
Unlike a regular syslog server which listens for client messages on UDP port 514, syslog-ng also listens on TCP port 514. The second set of sources is labeled s_network and includes all syslog messages obtained from UDP sources and limits TCP syslog connections to 5000. Limiting the number of connections to help regulate system load is a good practice in the event that some syslog client begins to inundate your server with messages.
Our example also has two destinations for syslog messages, one named d_localhost, the other, d_network. These examples show the flexibility of syslog-ng in using variables. The $YEAR, $MONTH and $DAY variables map to the current year, month and day in YYYY, MM and DD format respectively. Therefore the example:
/var/log/syslog-ng/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log
refers to a
directory called /var/log/syslog-ng/2005.07.09 when messages arrive on
Installing syslog-ng
The most recent syslog-ng and its companion eventlog tar files can be downloaded from the www.balabit.com website. The installation procedure is straightforward, but you will need to have the Linux gcc C programming language compiler preinstalled to be successful. Here are the steps.
1. Download the tar files from the BalaBit website. In this case we have browsed the website beforehand and know the exact URLs to use with the wget command.
[root@zippy tmp]# wget wget https://www.balabit.com/downloads/syslog-ng/2.0/src/eventlog-0.2.5.tar.gz
--12:34:17-- wget https://www.balabit.com/downloads/syslog-ng/2.0/src/eventlog-0.2.5.tar.gz
=> `eventlog-0.2.5.tar.gz'
[root@zippy tmp]# wget https://www.balabit.com/downloads/syslog-ng/2.0/src/syslog-ng-2.0.0.tar.gz
--12:24:21-- wget https://www.balabit.com/downloads/syslog-ng/2.0/src/syslog-ng-2.0.0.tar.gz
=> ` syslog-ng-2.0.0.tar.gz'
[root@zippy tmp]#
2. Install the prerequisite glib libraries.
[root@zippy tmp]# yum -y install glib
3. Using the tar command we extract the files in the pre-requisite eventlog archive and then use the configure; make and make install commands to install them correctly. Pay special attention to the output of the configure command to make sure that all the pre-installation tests are passed. If not, install the packages the error messages request and then start again.
[root@zippy tmp]# tar -xzf eventlog-0.2.5.tar.gz
[root@zippy tmp]# cd eventlog-0.2.5
[root@zippy eventlog-0.2.5]# ./configure
checking for a BSD-compatible install /usr/bin/install -c
checking whether build environment is sane yes
[root@zippy eventlog-0.2.5]# make
Making all in utils
make[1]: Entering directory `/tmp/eventlog-0.2.5/utils'
sed -e 's,_SCSH_,/usr/bin/scsh,' make_class.in >make_class
[root@zippy eventlog-0.2.5]# make install
Making install in utils
make[1]: Entering directory `/tmp/eventlog-0.2.5/utils'
make[2]: Entering directory `/tmp/eventlog-0.2.5/utils'
make[2]: Leaving directory `/tmp/eventlog-0.2.5'
make[1]: Leaving directory `/tmp/eventlog-0.2.5'
[root@zippy eventlog-0.2.5]#
4. The next step is to install the prerequisite glib package on your system.
[root@zippy eventlog-0.2.5]# yum -y install glib
5. Some environmental variables also need to be set prior to the installation of the syslog-ng files.
[root@zippy eventlog-0.2.5]# PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
[root@zippy eventlog-0.2.5]# export PKG_CONFIG_PATH
6. Using the tar command we extract the files in the pre-requisite syslog-ng archive and then use the configure, make clean, make and make install commands to install them correctly. In this case we the --sysconfdir directive with the configure command to make sure syslog-ng searches for its configuration file in the /etc directory. Once again, pay close attention to the pre-installation tests that the configure command executes.
[root@zippy eventlog-0.2.5]# cd /tmp
[root@zippy tmp]# tar -xzf syslog-ng-2.0.0.tar.gz
[root@zippy tmp]# cd syslog-ng-2.0.0
[root@zippy syslog-ng-2.0.0]# make clean
[root@zippy syslog-ng-2.0.0]# ./configure --sysconfdir=/etc
checking for a BSD-compatible install /usr/bin/install -c
checking whether build environment is sane yes
[root@zippy syslog-ng-2.0.0]# make; make install
Making all in src
make[1]: Entering directory `/tmp/ syslog-ng-2.0.0/src'
[root@zippy syslog-ng-2.0.0]#
7. The installation has template init.d/syslog-ng scripts and syslog-ng.conf files in the contribs/ directory.
[root@zippy syslog-ng-2.0.0]# ls contrib/
fedora-packaging init.d.RedHat-7.3 init.d.SuSE
Makefile.in rhel-packaging syslog-ng.conf.HP-UX
syslog-ng.vim init.d.HP-UX init.d.solaris
Makefile README syslog2ng
init.d.RedHat syslog-ng.conf.RedHat init.d.SunOS
Makefile.am relogger.pl syslog-ng.conf.doc
syslog-ng.conf.SunOS
[root@zippy syslog-ng-2.0.0]#
8. Copy the versions for your operating system to the /etc/init.d and /etc , /etc/logrotate.d , /etc/sysconfig directories. The /etc/syslog-ng/ directory needs to be created beforehand. Redhat and Fedora installations have their own subdirectories contrib/.
[root@zippy syslog-ng-2.0.0]# mkdir /etc/syslog-ng/
[root@zippy syslog-ng-2.0.0]# cp contrib/fedora-packaging/syslog-ng.init
/etc/init.d/syslog-ng
[root@zippy syslog-ng-2.0.0]# cp contrib/fedora-packaging/syslog-ng.conf
/etc
[root@zippy syslog-ng-2.0.0]# cp contrib/fedora-packaging/syslog-ng.sysconfig
/etc/sysconfig/syslog-ng
[root@zippy syslog-ng-2.0.0]# cp contrib/fedora-packaging/syslog-ng.logrotate
/etc/logrotate.d/syslog-ng
Remember that you may want to customize your syslog-ng.conf file.
9. Change the permissions on your new /etc/inid.d/syslog-ng file.
[root@zippy syslog-ng-2.0.0]# chmod 755 /etc/init.d/syslog-ng
10. You need to be careful. The init.d script may refer to a syslog-ng binary
file that's in an incorrect location. Find its true location and edit the
script.
[root@zippy syslog-ng-2.0.0]# updatedb
[root@zippy syslog-ng-2.0.0]# locate syslog-ng | grep bin
/usr/local/sbin/syslog-ng
[root@zippy syslog-ng-2.0.0]# vi /etc/init.d/syslog-ng
#exec='/sbin/syslog-ng'
exec='/usr/local/sbin/syslog-ng'
:wq
[root@zippy syslog-ng-2.0.0]#
11. Next create the /etc/syslog-ng directory for the configuration files and the /var/log/syslog-ng directory for the log files.
[root@zippy syslog-ng-2.0.0]# chkconfig syslog off
[root@zippy syslog-ng-2.0.0]# chkconfig syslog-ng on
[root@zippy syslog-ng-2.0.0]# service syslog stop
Shutting down kernel logger: [ OK ]
Shutting down system logger: [ OK ]
[root@zippy syslog-ng-2.0.0]# service syslog-ng start
syslog-ng: unrecognized service
[root@zippy syslog-ng-2.0.0]#
12. The sample syslog-ng.conf file in Figure 5-1 was configured to have all directories owned by the group logs. This user group needs to be created and any users that need access to the directories need to added to this group using the usermod command. In this case the user peter is added to the group and the groups command is used to verify success.
[root@zippy tmp]# groupadd logs
[root@zippy tmp]# usermod -G logs peter
[root@zippy tmp]# groups peter
peter: users logs
[root@zippy tmp]# usermod -G logs peter
13. You can now configure syslog-ng to start on the next reboot with the chkconfig command and then use the service command to start it immediately. Remember to stop the old syslog process beforehand.
[root@zippy tmp]# service syslog stop
Shutting down kernel logger: [ OK ]
Shutting down system logger: [ OK ]
[root@zippy tmp]# chkconfig syslog off
[root@zippy tmp]# chkconfig syslog-ng on
[root@zippy tmp]# service syslog-ng start
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
[root@zippy tmp]#
14. Now, your remote hosts should log begin logging to the /var/log/syslog-ng directory. According to our preliminary configuration file, there should be sub-directories categorized by date inside it. Each of these sub-directories in turn will have directories beneath them named after the IP address and/or hostname of the various remote syslog clients and will contain files categorized by syslog facility. In this example we see that the 2005.07.09 directory as received messages from three hosts, 192.168.1.1, 192.168.1.100 and localhost.
[root@zippy tmp]# ls /var/log/syslog-ng/
[root@zippy tmp]# ll /var/log/syslog-ng/2005.07.09/
drwxr-x--- 2 root logs 4096 Jul 9
drwxr-x--- 2 root logs 4096 Jul 9
drwxr-x--- 2 root logs 4096 Jul 9
[root@zippy tmp]# ls /var/log/syslog-ng/2005.07.09/localhost/
cron.log kern.log local7.log syslog.log
[root@zippy tmp]#
Using syslog-ng your system can now be used as a much more customizable tool to help troubleshoot devices attached to your network. Each day syslog-ng will automatically create new sub-directories to match the current date and at the end of each calendar quarter the files will be moved to a special archive directory containing all the data for the previous three months. This archived data can then be periodically deleted as needed. For very large deployments, or for better searching and correlation capabilities, it is possible to send the output of syslog-ng to a SQL type database. This is beyond the scope of this book, but it is a worthwhile feature to keep in mind.
Configuring syslog-ng Clients
Clients logging to the syslog-ng server don't need to have syslog-ng installed on them, a regular syslog client configuration will suffice.
Simple syslog Security
One of the shortcomings of a syslog server is that it doesn't filter out messages from undesirable sources. It is therefore wise to implement the use of TCP wrappers or a firewall to limit the acceptable sources of messages when your server isn't located on a secure network. This will help to limit the effectiveness of syslog based denial of service attacks aimed at filling up your server's hard disk or taxing other system resources that could eventually cause the server to crash.
Remember that regular syslog servers listen on UDP port 514 and syslog-ng servers rely on port 514 for both UDP and TCP. Please refer to Chapter 14, 'Linux Firewalls Using iptables', on Linux firewalls for details on how to configure the Linux iptables firewall application and Appendix I, 'Miscellaneous Linux Topics', for further information on configuring TCP wrappers.
Conclusion
In the next chapter we cover the installation of Linux applications, and the use of syslog will become increasingly important especially in the troubleshooting of Linux-based firewalls which can be configured to ignore and then log all undesirable packets; the Apache Web server which logs all application programming errors generated by some of the popular scripting languages such as PERL and PHP; and finally, Linux mail whose configuration files are probably the most frequently edited system documents of all and which correspondingly suffer from the most mistakes.
This syslog chapter should make you more confident to learn more about these applications via experimentation because you'll at least know where to look at the first sign of trouble.
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1438
Importanta:
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved