1 - You send syslog messages to a remote host by specifying that host in the
action field in the following form:
auth.notice @loghost
or
auth.notice @moog
The term loghost is just an alias which is used by convention.By default,your
local machine is the loghost.
Make sure loghost is defined correctly for your name service.
Verify with ping -s loghost.
Or specify the desired hostname in place of loghost.
Again, verify with ping -s - if a fully-qualified domain name is returned,
specify this.
2 - Make the modifications necessary to the syslog.conf file on the system you
want to log.
See syslog.conf(4) and syslog(3) for explanation of the facilities
and levels.
No modifications need to be made to syslog.conf on the loghost,
unless you are redefining the targets for specific facilities.
In other words, the facility you log to the remote host will be logged according
to how the action field is set up on that system. You must restart syslogd for
changes to take effect.
3 - Make sure the action field is set correctly for the facility you want to
log, and that you are selecting the right level.
For example, if you are logging auth.notice and your entry is this:
auth.notice /var/log/authlog
Don't expect it to show up in /var/adm/messages.
Note: an example of the "notice" level of the auth facility is a successful su
to root. A failed su to root is considered to be at the "emergency" level, so
that WILL be logged to /var/adm/messages if you have the following line:
*.emerg;user.none *
In short, any facility will be logged at the level selected and all higher
levels, but never lower levels.
4 - Syslog does NOT send mail to users; rather it attempts to write to the pty
of specified users that are logged in (similar to wall).
If you wish to mail users you will need to create a pipe and have that do the
message handling, or create a script run at regular intervals to monitor one of
the log files and send out messages accordingly.
5 - don't create multiple targets on one line. create a new line for each.
For example -this doesn't work:
auth.notice /var/log/authlog,@loghost
But this does:
auth.notice /var/log/authlog
auth.notice @loghost
you can combine facilities on one line, they should be delimited with
semicolons.
6 - If you don't wish to use the default ifdef lines, create your own for
selected facilities.
You can replace this:
auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost)
with this:
auth.notice /var/log/authlog
auth.notice @loghost
Troubleshooting:
1 - run syslogd in debug mode (note: this must run in the foreground). examine
the output, particularly at the beginning. The following is healthy output:
(root):(/):/usr/sbin/syslogd -d
getnets() found 1 addresses, they are: 0.0.0.0.2.2
off & running....
init
amiloghost() testing 129.151.30.223.2.2
cfline(.err;kern.notice;auth.notice;user.none /dev/console)
cfline(.err;kern.debug;daemon.notice;mail.crit;user.none /var/adm/messages)
cfline(.alert;kern.err;daemon.err;user.none operator)
cfline(.alert;user.none root)
cfline(*.emerg;user.none *)
cfline(auth.notice @loghost)
cfline(mail.debug @loghost)
cfline(user.err /dev/console)
cfline(user.err /var/adm/messages)
cfline(user.alert root, operator)
cfline(user.emerg *)
cfline(daemon.notice /dev/console)
cfline(daemon.notice sean)
cfline(daemon.notice @moog)
cfline(daemon.notice /nsr/logs/messages)
cfline(daemon.notice operator)
cfline(local0.notice /nsr/logs/summary)
cfline(local0.alert root, operator)
If the target is not valid, you will generally see error messages here.
Here is an example:
(root):(/):/usr/sbin/syslogd -d
getnets() found 1 addresses, they are: 0.0.0.0.2.2
off & running....
init
amiloghost() testing 129.151.30.223.2.2
cfline(.err;kern.notice;auth.notice;user.none /dev/console)
cfline(.err;kern.debug;daemon.notice;mail.crit;user.none /var/adm/messages)
cfline(.alert;kern.err;daemon.err;user.none operator)
cfline(.alert;user.none root)
cfline(*.emerg;user.none *)
cfline(auth.notice /var/log/authlog )
syslogd: /var/log/authlog : No such file or directory
logmsg: pri 53, flags 8, from superfreak, msg syslogd: /var/log/authlog : No
such file or directory
2 - while in debug mode, use logger to test the facility in question.
To test auth.notice, type logger -p auth.notice "testing auth.notice".
monitor the output:
logmsg: pri 45, flags 2, from superfreak, msg May 1 10:39:31 sdillman: testing
auth.notice
Logging to CONSOLE /dev/console
Logging to UNUSED
^^^^^^^^^^^^^^^^^^
Here you know you have a problem. Go back to syslog.conf.
3 - If you're still not logging on the loghost, use snoop to debug further.
First try between the system you are logging and the loghost. Syslog uses
the udp protocol:
(root):(/):snoop udp between superfreak moog
Using device /dev/hme (promiscuous mode)
superfreak -> moog SYSLOG C port=35725 <37>May 1 10:42:33
superfreak -> moog SYSLOG C port=35725 <34>May 1 10:45:12
Here, the absence of syslog messages indicates a problem. If you're not seeing
anything here, simplify it by just running snoop udp (hostname) to see if
packets are being sent out at all. If this is still not working, and you've
verified logging is working on they system being logged, test the same facility
on the loghost and make sure it's working there. For SunOS, use etherfind in
place of snoop.
Keep in mind that the udp protocol works on a "best-effort" basis and if you
regularly experience network problems which affect other upd services (NFS v.2,
DNS, etc) you you can expect similar problems here.
Note: Since data can be lost in this scenario, it is recommended that you log
both to the localhost and the loghost if you must have this data. Alternatively
you could use other means to distribute the log data to the loghost via TCP,
such as using NFS v.3 or rdist (each of which has security implications of it's
own).
4 - if problems persist, suspect syslog.conf file itself. There should be
nothing but tabs between the facility/level field and the action field, and
a misplaced space or carriage return can cause different sorts of failures.
In the following example, logging is working both on the "local" system and
the loghost, yet messages are not getting logged to the loghost.
Looking at the debug output, we see the following:
(root):(/):/usr/sbin/syslogd -d
getnets() found 1 addresses, they are: 0.0.0.0.2.2
off & running....
init
amiloghost() testing 129.151.30.220.2.2
I am loghost
cfline(.err;kern.notice;auth.notice;user.none /dev/console)
cfline(.err;kern.debug;daemon.notice;mail.crit;user.none /var/adm/messages)
cfline(.alert;kern.err;daemon.err;user.none operator)
cfline(.alert;user.none root)
cfline(*.emerg;user.none *)
cfline(auth.notice @moog )
syslogd: line 29: unknown host moog
logmsg: pri 53, flags 8, from superfreak, msg syslogd: line 29: unknown host
moog
^^^^^^^^^^^^^^^^^
What's going on here?
A problem with the name resolution?
Here we try adding the host/ip address alias to /etc/hosts, but still get the
same problem.
What to do?
GO BACK TO SYSLOG.CONF.
Invoking :set list in vi, we notice the following:
# if a non-loghost machine chooses to have authentication messages$
# sent to the loghost machine, un-comment out the following line:$
#auth.notice^I^I^Iifdef(`LOGHOST', /var/log/authlog, @moog)$
auth.notice^I^I^I@moog^I$
^^^^
$
There is an extra tab after the hostname of the loghost.
Remove this, and we get healthy startup messages:
(root):(/):/usr/sbin/syslogd -d
getnets() found 1 addresses, they are: 0.0.0.0.2.2
off & running....
init
amiloghost() testing 129.151.30.223.2.2
cfline(.err;kern.notice;auth.notice;user.none /dev/console)
cfline(.err;kern.debug;daemon.notice;mail.crit;user.none /var/adm/messages)
cfline(.alert;kern.err;daemon.err;user.none operator)
cfline(.alert;user.none root)
cfline(*.emerg;user.none *)
cfline(auth.notice /var/log/authlog)
cfline(auth.notice @moog)
cfline(mail.debug @loghost)
cfline(user.err /dev/console)
cfline(user.err /var/adm/messages)
cfline(user.alert root, operator)
cfline(user.emerg *)
cfline(daemon.notice /dev/console)
cfline(daemon.notice sean)
cfline(daemon.notice @moog)
cfline(daemon.notice /nsr/logs/messages)
cfline(daemon.notice operator)
cfline(local0.notice /nsr/logs/summary)
cfline(local0.alert root, operator)
A test now logs correctly to the remote loghost.
5 - If you still have problems and the debugging output does not make the
cause clear, you can run a truss on the syslog daemon (syslogd). Here it is
most likely that there is a problem elsewhere with the system and the truss
helpS identify this.
