syslogd is the Linux system logging utility that take care of filling up your files in /var/log when it is asked to.
On a standard system, logging is only done on the local drive. But syslog can be configured to receive logging from a remote client, or to send logging to a remote syslog server.
Some of the use cases could be:
- A machine which filesystem goes read-only
- Log replication
this tutorial will explain how to set up both the server, to receive message from a remote client, and the client to emit messages to a syslogd server.
In this tutorial I will consider that you do not have any firewalls interfering with the traffic.
The syslogd server will be called etch32 and has IP 192.168.2.1.
The client is called hardy32-1. Its IP do not matter.
syslogd is using UDP on port 514
1. Setting up the syslogd server
The distribution used for the server is, as its hostname says, a Debian Etch. But, unless you are not using a debian based distro, the changes will be the same.
changes for syslogd are pretty minor. We basically simply have to tell syslogd to listen for remote messages.
It is either opened or closed, there is no filtering, so if you need to only accept a subset of machines, IPtables will be your friend.
To enable remote logging, go and edit /etc/default/syslogd and make sure SYSLOGD is set to:
then, restart syslogd:
# /etc/init.d/syslogd restart
Now, let set a client to send messages to our remote syslogd server.
2. syslogd clients
The action is in /etc/syslog.conf. In this example, I am going to send to both the remote syslogd server and to the filesystem the messages written to /var/log/messages.
In Ubuntu, this is the bit of conf that handle that:
*.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages
The default is to send the messages to /var/log/messages without “synching” after each log messages (“-“ in front of the file name.).
to specify a remote host, the name or the ip of the remote host as to be given instead of a file, and, prepended with an “@”. So, to send the messages writtent to /var/log/messages, our syslog.conf file will look like:
*.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none @etch32
to have etch32 receiving messages from hardy32-1.
now, we need to make syslog aware of the chances:
$ sudo /etc/init.d/sysklogd restart
3. What happens then
Well, lets take a look at each /var/log/messages after I restarted syslogd on hardy32-1 and I started tcpdump on eth0:
Jun 30 23:01:59 etch32 dhcpd: added reverse map from 220.127.116.11.in-addr.arpa. to hardy32-1.lan.debuntu.local Jun 30 23:01:59 etch32 dhcpd: DHCPREQUEST for 192.168.2.198 (192.168.2.1) from 00:0c:29:d4:01:57 (hardy32-1) via eth1 Jun 30 23:01:59 etch32 dhcpd: DHCPACK on 192.168.2.198 to 00:0c:29:d4:01:57 (hardy32-1) via eth1 Jun 30 23:04:15 hardy32-1.lan.debuntu.local syslogd 1.5.0#1ubuntu1: restart. Jun 30 23:05:01 hardy32-1.lan.debuntu.local kernel: [ 6268.923820] device eth0 entered promiscuous mode Jun 30 23:05:01 hardy32-1.lan.debuntu.local kernel: [ 6268.923847] audit(1214863498.177:3): dev=eth0 prom=256 old_prom=0 auid=4294967295 Jun 30 23:05:11 hardy32-1.lan.debuntu.local kernel: [ 6278.677844] device eth0 left promiscuous mode Jun 30 23:05:11 hardy32-1.lan.debuntu.local kernel: [ 6278.677869] audit(1214863510.404:4): dev=eth0 prom=0 old_prom=256 auid=4294967295
As you can see, messages from hardy32-1 contains the box FQDN: hardy32-1.lan.debuntu.local and we see that eth0 went temporarily in promiscuous mode.