How To Set Up A Debian Linux Syslog Server
The material on this page was prepared using Sarge or Etch
configured using our Installation and Packages pages.
If you did not use our pages to set up your system, what you
encounter on your system may be different than what is given here.
When network devices run into problems they generate error messages. In a lot of cases, where those error messages go is up to you. Devices like servers (including Windows servers with the utility mentioned below), routers, switches, and even some HP JetDirect print server cards support the use of a "syslog" server. A syslog server is kind of a central repository for log messages as a way for you to centralize your monitoring of network systems and devices. It's a client/server type of setup where the devices are the "clients".
When set up to use a syslog server, devices will send their log messages over the network wire to the syslog server rather than recording them in a local file or displaying them. By default Cisco routers and switches will typically write them to the console screen provided 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 where these messages are sent.
Not only is it up to you to decide where the messages are sent, but you can also decide which messages the client devices send based on the level of severity. These severity levels are standardized and identified by a number and/or a standard abbreviation (shown in parentheses) as so:
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 to send every peep to the syslog server. It's good to use when you want to test your syslog server to make sure it's working.
There are also things called "facilities" which loosely relate to system processes, a way of categorizing messages. When a remote device sends a message to a syslog server it includes one of the standard facility values (along with a severity level). Some of the common facilities are:
auth - authentication (login) messages
cron - messages from the memory-resident scheduler
daemon - messages from resident daemons
kern - kernel messages
lpr - printer messages (used by JetDirect cards)
mail - messages from Sendmail
user - messages from user-initiated processes/apps
local0-local7 - user-defined (see below)
syslog - messages from the syslog process itself
local7 is used by Cisco equipment and Windows servers. You can specify different severity levels for different facilities so you can, for example, log all kernel messages but only emergency messages from printers. This is done in the /etc/syslog.conf file using the following format:
Using the example we gave above for kernel and printer messages the /etc/syslog.conf file entries would look like this:
Note that the file uses the standard abbreviations for the severity level and not the number. Note also that you can specify any path and file name for the target log file. You can even specify different log files for different severities or facilities or any combination thereof.
kern.* /var/log/example.log lpr.emerg /var/log/example.log
I usually set up a large partition with the mount-point name of "logs" just for syslog files. The above /etc/syslog.conf file entries would then look something like this:
If you wanted every message from every device to get logged (for testing purposes for example) you'd only need one entry:
kern.* /logs/enterprise.log lpr.emerg /logs/enterprise.log
The Syslog Server
There's two things you have to do to set up your Debian system as a log host. Luckily they're simple edits to a couple text files. They are:
- Tell the syslog daemon to listen for messages from remote devices
- Tell the syslog daemon what to do with those messages
The syslog daemon is run at system startup by default because it also handles all the local log files, and there are a bunch of them. If you list the files in the /var/log directory you'll see what I'm talking about.
To take care of the first item above we have to edit the startup script that runs the syslogd daemon when the system boots. Open the script using the command:
and look for this line near the top:
and change it to:
(That's a zero after the 'm'.) Then exit the editor saving the file. The -r tells syslogd to listen for remote messages. The -m0 stops syslogd from putting a bunch of annoying -- MARK -- entries in your log files.
To take care of the second item, open the follwing file:
and add the following lines to it near the top:
Here we are just telling the syslogd daemon to write the messages to the enterprise.log file. If you want to monitor Windows servers and Cisco devices add this line also:
We're using the 'debug' level here just for testing to make sure our server is receiving and logging messages. It can tightened up later. Now restart the syslogd daemon with the command:
Congratulations, you've got yourself a syslog server! You can check it out by listing the files in the /var/log directory again. You should see the enterprise.log file there now.
Now you have to go around to your devices and tell them to use it, and what level of messages to send to it.
For Cisco switches running the CatOS you can console or telnet into the switch and enter the following commands to accomplish that:
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 where you set the level of severity. For Cisco routers and switches running IOS the commands are:
logging <ip address of your Debian system>
logging trap errors
service timestamps log datetime
Note that errors is where you set the level of severity.
If you want to set up other Linux servers (or even desktops) to be clients (i.e. to send their messages to this Debian log server) you'd add the following line to their /etc/syslog.conf files:
replacing 'debianbox' with whatever the hostname of your Debian system is. The '*.*' specifies that all log messages be sent to the log server. Some devices, like JetDirect cards will not allow you to specify a severity level which is why you want to restrict what's actually logged by the settings you enter in the /etc/syslog.conf file on the syslog server.
Naturally Microsoft doesn't want to support a long-held standard like syslog so we have to jump through some hoops to monitor Windows servers. A company in Sweden called Datagram has a great free utility called SyslogAgent that runs as a service on Windows servers. It converts the messages in all of the Event Viewer logs (System, Applications, Security, etc.) to a syslog format and sends them to a syslog server. You can even specify a different severity level for each log. And even better, installing it doesn't require a reboot. Go to their download page at:
and download just the SyslogAgent file, not the whole suite. It runs on NT, 2000, and 2003.
Rotating Log Files
Syslog is a daemon that runs on every Linux/UNIX system to keep local logs. The -r parameter (listen for remote systems) is what turns a system into a syslog server. There's one other daemon that works with syslog to maintain the files called logrotated. "Rotating" a log file means renaming the current file to append a .0 or .1 etc. to a log file and starting a new one (or optionally just keep appending to what's there - kind of a snapshot in time thing). The keeping (renaming) of the old log file and how many to keep are settable options and the frequency of the rotation is customizable by editing the /etc/logrotate.conf file. If you're only logging critical and above errors from remote devices you may want to only rotate them monthly. Weekly is the default. You can also set how many of the old log files to keep.
The key settings in the /etc/logrotate.conf file are:You can even set up sections so that different log files have different settings. See the man page for logrotate for details.# rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # uncomment this if you want your log files compressed #compress
Viewing The Log Files
If you set your /etc/syslog.conf file to have everything written to the same file, once you get all the client devices set up you'll only have one log file to check for all the devices on your network.
Rather than having to go to the Debian system itself to look at the central log fle, you can make it accessible from anywhere on your network via a browser provided you have Apache installed on your syslog server. In addition to installing Apache you'd have to configure it to process SSI (Server-Side Includes). We show you how to do both on the Internet Servers page.
Once you've got Apache set up we need to create a Web page that will display the log. Start out by renaming the supplied home page (because it has some useful Apache path information) using the following command:
mv /var/www/index.html /var/www/index.org
Then use the nano editor to create a new home page with the command:
(note that the s in the file extension is required for SSI) and enter the following into it:
<html> <head> <title>Enterprise Syslog Log File</title> </head> <body> <center> <h2> MyCorp Enterprise Syslog Log </h2> </center> <!--#include file="enterprise.log" --> <br> </body> </html>
Exit the editor saving the file.
The file reference in the SSI include directive is relative to the "Document Root" of the Apache Web server. In other words, the enterprise.log file has to reside in the /var/www directory with the index.shtml file that contains the directive.
Creating an enterprise log file in the Document Root of your Web server probably isn't the best idea. As mentioned above, if you're going to set up a serious log server you'll probably want to create a separate large partition with the mount point of /logs to store the log files. Perhaps the easiest way to handle accessing the enterprise log file from the Web page is to change your Apache Document Root setting to point to the same /logs mount point.
We covered changing the Apache configuration back on the Internet Servers page. Changing the Document Root setting is simply a matter of opening the Apache configuration file in a text editor with the command:
and changing the line (in Section 2):
and exit the editor saving the file. Be sure to move your index.shtml to the /logs partition and to change you /etc/syslog.conf file so that the enterprise log file is also saved to the /logs partition. For testing purposes make it:
After you've got all the changes made you'll have to restart the syslog and Apache services or just reboot the system.
Now go to another system on the network, fire up a Web browser, and point it to the IP address of your syslog server like so:
A Web page containing the contents of the 'enterprise.log' file should appear (provided it has something in it at this point). If it doesn't, click on "View" on your browser menu and select "Source" and see if the SSI directive line is listed with the HTML code. It shouldn't. If it does it means that Apache is not properly configured to process SSI directives (or you didn't use the s in the extension of the page file name). The /var/log/apache.log and /var/log/apache.err files 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 failures which could indicate a hacking attempt. With lower severity it can log all authentication attempts so you can archive who logged in when.
Syslog can also be the source of security concerns because it doesn't care who sends it messages. This may not be a huge issue on an internal LAN, but it isn't an appropriate service to run on Internet-connected systems.
Do NOT plan to use the system you will create using these guide pages as a "production" (real) server. It will NOT be secure!
There are many steps involved in creating a secure Internet or LAN server. While we do refer to some things you can do to make your system more secure, there are many other measures related to system security that also need to be taken into consideration and they are not covered on these pages.
These guide pages are meant as a learning tool only. The knowledge gained on these pages will help you understand the material covered in security-related publications when you are ready to consider setting up a production server.
Did you find this page helpful ?
If so, please help keep this site operating
by using our DVD or book pages.
Site, content, documents, original images Copyright © 2003-2013 Keith Parkansky All rights reserved
Duplication of any portion of this site or the material contained herein without
the express written consent of Keith Parkansky, USA is strictly prohibited.
This site is in no way affiliated with the Debian Project, the debian.org Web site, or
Software In The Public Interest, Inc. No endorsement of this site by the Debian Project
or Software In the Public Interest is expressed or implied. Debian and the Debian logo
are registered trademarks of Software In The Public Interest, Inc. Linux is a registered
trademark of Linus Torvalds. The Tux penguin graphic is the creation of Larry Ewing.
IN NO EVENT WILL KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. ALL INFORMATION, METHODS, HTML OR COMPUTER CODE IS PROVIDED STRICTLY "AS IS" WITH NO GUARANTY OF ACCURACY AND/OR COMPLETENESS. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.