When network devices have problems, they generate error messages. In many cases, these error messages go to you. Devices such as servers (including Windows servers using the utilities mentioned below), routers, switches support the use of the server “syslog”. The syslog server is a kind of central repository for the message log, as a way for you to centralize the monitoring of network systems and devices. This is a type of client / server installation where devices are “clients”.
When you set up and use the syslog server, devices will send their log messages over the network wire to the syslog server rather than writing them to a local file or displaying them. By default, Cisco routers and switches usually write them to the console screen if you have a console session open. But since you don’t have a console session open most of the time, it’s a good idea to change the messages you send.
Not only can you decide when messages are sent, but you can also decide which messages the client device is sending based on the severity. These severity levels are standardized and are identified by a number and / or standard abbreviation (shown in parentheses) as listed below:
0 – Emergency (emerg) 1 – Alerts (alert) 2 – Critical (crit) 3 – Errors (err) 4 – Warnings (warn) 5 – Notification (notice) 6 – Information (info) 7 – Debug (debug) Level 7 basically says send every signal to a syslog server. This is good to use when you want to check your syslog server to make sure it is working.
There are also things called “facilities” that are loosely related to system processes, a way of categorizing messages. When a remote device sends a message to the syslog server, it includes one of the default values for the object (along with the severity). Some of the common remedies are:
- auth – authentication messages (login)
- cron – messages from memory resident scheduler
- daemon – messages from daemon residents
- kern – kernel messages
- lpr – printer messages (using JetDirect card)
- mail – messages from Sendmail
- user – messages from the user who initiated processes / applications
- local0 – local7 – user-defined (see below)
- syslog – messages from the syslog process itself
facility.severity log-file-namelocal7 is used in Cisco hardware and Windows servers. You can set different severity levels for different objects, so that you can, for example, log all kernel messages, but only alarms from printers. This is done in the /etc/syslog.conf file using the following format:
Using the example above for kernel and printer, the messages will be written to the /etc/syslog.conf file and will look like this:
kern.* /var/log/example.log lpr.emerg /var/log/example.log
Note that the file uses standard abbreviations for severity, not quantity. Note also that you can specify any path and filename for the target log file. You can even specify different log files with different severity or services, or any combination of these.
We usually create a large partition named “logs” mount point just for the syslog files. The above entries in the /etc/syslog.conf file will look something like this:
kern.* /logs/andreyex.log lpr.emerg /logs/andreyex.log
If you want to receive every message from every device, after login (for testing purposes, for example) you only need one entry:
*. * /logs/andreyex.log
There are two things you must do to set up your Debian system as a host log. Fortunately, these are simple changes to a couple of text files. this is:
- Tell the syslog daemon to listen for messages from remote devices
- Tell the syslog daemon what to do with these messages
The Syslog daemon is started by default when the operating system starts up, since it also processes all local log files. If you scroll through the files in the / var / log directory you will see what we are talking about.
In order to accomplish the first step above, we need to modify the startup script that starts the SyslogD daemon at system boot. Open the script with the command:
and find the line at the top:
and change it to:
(This is the zero after the “m”). Then exit the editor and save the file. -r tells SyslogD to listen for remote messages. -m0 stops SyslogD from putting an annoying entry – tag – in the log file on the heap.
To take care of the second point, open the following file:
and add the following lines at the top:
*.emerg /var/log/andreyex.log *.alert /var/log/andreyex.log *.crit /var/log/andreyex.log
Here we just tell the SyslogD daemon to write messages to the grayex.log file. If you want to control Windows servers and Cisco device, add this line as well:
We use the “debug” level here for testing purposes only, to make sure our server receives and logs messages. It can be compressed later. Now restart the SyslogD daemon using the command:
Congratulations, you’ve got yourself a syslog server! You can check this by listing the files in the / var / log directory. You should see the grayex.log file there by now.
Now you have devices and you can tell them how to use and what level of messages to send.
For Cisco switches running CatOS, you can use the console or telnet on the switch and enter the following commands to accomplish this:
set logging server <ip address of your Debian system> set logging server severity 3 set logging timestamp enable set logging server enable
Note that 3 is the severity level you set. For Cisco routers and switches running IOS, the commands are:
config term logging <ip address of your Debian system> logging trap errors service timestamps log datetime logging on
Note where errors are, you set the severity level.
If you want to configure other Linux servers (or even desktops) to be clients (i.e. send your messages to this Debian server log), add the following line to your /etc/syslog.conf file:
replacing “debianbox” with the hostname of your Debian system. “*. * ”Indicates that all log messages will be sent to the log server.
Rotating log files
Syslog is a daemon that runs on any Linux / UNIX system for local logs. The -r (listen to remote systems) option is what turns the system into a syslog server. There is one daemon that works with Syslog to save files called logrotated. Log file “Rotating” means renaming the current file with the addition of 0.0 or 0.1, and so on. to a log file and create a new one (or perhaps just save the addition to it, a snapshot in time). Keeping (renaming) the old log file and rotation rates are set in the parameters, and the rotation rate is adjusted by editing the /etc/logrotate.conf file. If you only log all important errors from remote devices, then you can rotate them monthly. Weekly by default. You can also set which of the old log files to keep.
The main parameters in the /etc/logrotate.conf file are:
# Ротация файлов журнала еженедельно weekly # Делать ротация на период последних 4 недель rotate 4 # Создать новый (пустой) файл журнала после ротации старых create # Раскомментируйте, если вы хотите, чтобы ваши файлы журналов сжимались #compress
You can even customize partitions so that different log files have different settings. See the LogRotate page for details.
Viewing log files
If you specify in the /etc/syslog.conf file to write everything to a file, you will get records of all client devices, and you will have only one log file to check all devices on the network.
Instead of going to the Debian system itself to look at the central FLE log, you can make it accessible from anywhere on the network through a browser if you have Apache installed on the syslog server. In addition to installing Apache, you must configure it to handle SSI (Server-Side Includes).
Once you’ve got Apache configured, we need to create a web page to display in the log. Start by renaming the attached home page (because it has some useful Apache path information) with the following command:
mv /var/www/index.html /var/www/index.org
Then, using the nano editor, create a new home page using the command:
(note that the s in the file extension is required for SSI) and enter the following into it:
<html> <head> <title>Файл журнала Syslog</title> </head> <body> <center> <h2> Мой журнал Syslog </h2> </center> <!--#include file="andreyex.log" --> <br> </body> </html>
Close the editor and save the file. The SSI file reference includes directives regarding the “Document Root” in the Apache Web server. In other words, the file andreyex.log should be located in the / var / www directory with the index.shtml file that contains the directive. Creating a log file in the Document Root of your web server is probably not a good idea. As mentioned above, if you are going to create a serious log server you probably want to create a separate large partition with a / logs mount point to store the log files. Perhaps the easiest way to deal with accessing the log file from a web page is to change the Document Root settings in Apache to point to the same / logs mount point. To change the Document Root setting, simply open the Apache configuration file in a text editor using the command:
and changing the line (in section 2):
and exit the editor and save the file. Be sure to move index.shtml to the / logs section and modify the /etc/syslog.conf file so that the grayex log file is also saving the kcz to the / logs section. For testing purposes, do cktle.ott:
Now go to another system on the network, launch a web browser, and point it to the IP address of your syslog server: After you have made the changes, you will have to restart the syslog and Apache service or simply reboot the system.
http://192.168.0.70 A web page that includes content in the “andreyex.log” file should appear (assuming there is something in it at the moment). If this does not happen, click on the “View” button in the browser menu and select “Source” and see if there is an SSI directive specified with the HTML code. It doesn’t have to be. If it does, it means that Apache is not properly configured to handle the SSI directive (or you didn’t use S in the page filename extension). the files /var/log/apache.log and /var/log/apache.err are also helpful in troubleshooting SSI problems.
Syslog is a very powerful tool. It has many options, such as sending messages to devices rather than files that you should investigate. It can also be used to log authentication errors that could indicate a hack attempt. With a lower severity, it can log all authentication attempts so that you can archive when logged in.
Syslog can also be a source of security problems because it doesn’t care who sends it a message. This may not be a big problem on an internal LAN, but it is not a reliable service to run on an Internet-connected system.