syslog-ng exercise

Installing syslog-ng

syslog-ng is not included in Fedora Core 4. Use yum/yumex to install it.

Getting syslog out of the way

We don't want a conflict:

service syslog stop
service syslog-ng start

Emulating syslog's network logging

Traditional syslog (as opposed to syslog-ng) has a message disposition option for shipping the message via UDP to port 514 on a network host where, if that syslog is listening on 514, it will absorb and log your message for you. Syslog-ng can do that if so configured. Here's how.

On the client, add the following to the bottom of /etc/syslog-ng/syslog-ng.conf:

destination loghost {udp("<server's IP>"port(514));};
log {source(s_sys); destination(loghost);};

The first line makes syslog-ng cognizant that the name "loghost" stands for an outlet whose mechanism is to call upon the network software to construct UDP packets (from whatever is sent to the outlet), address them as specified, and send them. It's passive. If you never actually send anything to that outlet (with the log directive) nothing will ever happen. The second line takes advantage of the newly established outlet by sending something to it. What does it send? Any message material that enters the syslog-ng system from the sources defined (elsewhere) by the name "s_sys".

On the server, uncomment the line that includes incoming udp from the sources of log messages so it ends up like:

source s_sys {
file ("/proc/kmsg" log_prefix("kernel: "));
unix-stream ("/dev/log");
internal();
udp(ip(0.0.0.0) port(514));
};

This widens the circle of what's included by the server under the "s_sys" reference, to encompass any UDP packets that show up at port 514. This directive alone causes nothing to happen to such data, but a disposition is presumably defined elsewhere by a "log" directive that references s_sys among the sources it processes.

Restart syslog-ng on both boxes to effect those changes:

service syslog-ng restart

On the client, generate a message:

logger "apple pie"

Look for "apple pie" logged in /var/log/messages on the server. ("tail -f /var/log/messages" is your friend.)

Now repeat the above, changing "udp" to "tcp" in both files. The apparent result should be the same (client's message in server's logfile) but if you care to run tcpdump or ethereal while conducting the 2 types of tranmittal you'll see the TCP signature connection handshake sequence in the second case but not in the first. Same end, different means. This is a distinction between syslog-ng and syslog. The latter is limited to UDP only.

Sending the message stream over stunnel

Now on the client change the network address (host and port) of the "loghost" destination by changing

destination loghost {tcp("192.168.3.12"port(514));};

to

destination loghost {tcp("127.0.0.1"port(2000));};

Restart syslog-ng on the client:

service syslog-ng restart

Run stunnel on both machines, as client on your syslog-ng client machine and as server on your syslog-ng server machine. Your configuration should be as below. It might already be that way from your earlier activity.

Everything's in place. Generate a log message on the client:

logger "tunnel vision"

look for "tunnel vision" in the server's /var/log/messages logfile. It traveled encrypted between machines thanks to stunnel.