INFODOC ID: 17097

SYNOPSIS: Setting up and debugging syslog for logging to remote hosts
DETAIL DESCRIPTION:

Setting up and debugging logging to remote hosts:

General considerations:

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.  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 affect.

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 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.
e.g. this doesn't work:

auth.notice			/var/logs/authlog,@loghost

this does:

auth.notice			/var/logs/authlog
auth.notice			@loghost

you can combine facilities on one line, they should be delimited with
semicolons.


6 - don't use the default ifdef lines - create your own for selected
facilities.
These never seem to work reliably.  Better to 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.  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
help identify this.  

PRODUCT AREA: Security
PRODUCT: Syslog
SUNOS RELEASE: Solaris 2.x, Solaris 1.x
HARDWARE: any

Questions or comments regarding this service? webmaster
Copyright 1994-1998 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.
All rights reserved.