19.19. Building a Syslog Server

Problem

You want to have a central network logging server, but the mossy old Linux syslog isn't really up to the job. It's OK for host logging, but it's not as flexible as it could be, and its remote logging capability is not built-in—it's a bit of a hack job, really. You want a modern log server that is designed for network logging, has encryption, and that lets you fine-tune your settings.

You have your SSL certificates and stunnel all configured and ready to go, so now you want to set up Syslog-ng itself.

Solution

Install Syslog-ng on Debian with this command:

	# aptitude install syslog-ng

And on Fedora with this command:

	# yum install syslog-ng

These will automatically remove the old syslog and set up a default configuration that mimics a standard syslog installation.

You must install Syslog-ng, OpenSSL, and stunnel on all client hosts as well, so if you haven't done this yet, see the previous three recipes.

We don't want to make a lot of changes to the existing /etc/syslog-ng/syslog-ng.conf file, so let's start with the options section on the Syslog-ng server:

	options {
	     sync (0);
	     log_fifo_size (2048);
	     time_reopen(10);
	     time_reap(360);
	     create_dirs (yes);
	     perm (0640);
	     dir_perm (0750);
	     chain_hostnames(0);
	     use_dns(no);
	     use_fqdn(no);
	     };

Add these lines to the source section to tell Syslog-ng to listen for messages via stunnel, and to give each remote host its own file in /var/log/hosts/:

	source stunnel {tcp(ip("127.0.0.1")port(514) max-connections(1));};
	destination d_clients {file("/var/log/hosts/$HOST/$DATE_$FACILITY"); };
	log {source(stunnel); destination(d_clients);};

Now, add the following to the syslog-ng.conf file on each client:

	options
	      {long_hostnames(off);
	      sync(0);};

	source s_local {unix-stream("/dev/log"); pipe("/proc/kmsg"); internal();};
	destination stunnel {tcp("127.0.0.1" port(514));};
	log { source(s_local); destination(stunnel); };

And now, the moment of truth—we start up stunnel and Syslog-ng:

	# stunnel
	# /etc/init.d/syslog-ng

Give it a test drive with the logger command on both the server and the client:

	$ logger "this is a test!"

Look in /var/log/messages to see a successful test:

	Jul 14 21:46:32 xena logger: this is a test

Then, /var/log/hosts/ should have a new file created for the client, Uberpc, and Uberpc should have also logged the test message in its own /var/log/messages file.

Discussion

That is a good setup that should suit most situtations because it nearly replicates the standard logging setup on the server. One difference is the client files are named with the hostname, date, and logging facility, so it's easy to find the file you want.

syslog-ng.conf has five sections:

options{}

Global options. These can be overridden in any of the next four sections.

source{}

Message sources, such as files, local sockets, or remote hosts.

destination{}

Message destinations, such as files, local sockets, or remote hosts.

filter{}

Filters are powerful and flexible; you can filter on any aspect of a log message, such as standard syslogd facility names (man 5 syslog.conf), log level, hostname, and arbitrary contents like words or number strings.

log{}

Log statements connect the source, destination, and filter statements, and tell Syslog-ng what to do with them.

As you saw from our examples, you don't have to organize everything in this manner. I like to group the statements by task rather than the type of statement.

Source, destination, and filter statements have arbitrary names. For example, source s_local could be source local, or source fred, or anything. There is a convention of using s_ to indicate source statements and d_ for destination statements, but it's not required.

Debian comes with a startup file for stunnel; Fedora doesn't. So, Fedora users can create one using /etc/skel as a model, or just drop it into /etc/rc.d/rc.local.

What if things don't work? Well, this is a chapter on troubleshooting, so you might read backwards!

First, make sure that Syslog-ng is operating correctly locally, which you can check with the logger command.

stunnel's maximum logging level is debug=7 (in stunnel.conf),and stunnel messages go into /var/log/daemon.log. You might also try directing the log messages to the screen by starting it from the command line with these options:

	# stunnel -f -D7

That keeps it in the foreground, so you'll see everything in real time.

Using a packet sniffer will show you the communications between the various players, so set tcpdump to watching your Syslog-ng ports to see what they're telling each other:

	# tcpdump -pi eth0 -s0 port 514 or port 5140

See Also