[X-Unix] Using SYSLOG

[Kevin Stevens]

On Mon, 28 Jun 2004, AKappyCT wrote:

> Can anyone advise on configuring SYSLOG on a Panther box to receive
> such messages and designate a file to log them to?

Maybe!  I use my system in such a way.

> The switch config:
> > 3. Configure remote logging by using the following command:
> > config syslog {add} <ipaddress> <facility> {<priority>}
> >
> > where:
> >  ipaddress Specifies the IP address of the syslog host.
> >
> >  facility Specifies the syslog facility level for local use. Options
> > include local0 through local7.
> >
> >  priority Filters the log to display message with the selected
> > priority or higher (more critical). Priorities include (in order)
> > critical, emergency, alert, error, warning, notice, info, and debug.
> > If not specified, only critical priority messages are sent to the
> > syslog host.

1.  Configure your switch as above.  Those look like Cisco instructions,
you can Google to find more information if you need help with that part.

2.  Configure your Panther system to log external syslog messages.  Most
of these steps require root privileges to implement.

a.  Configure /etc/syslog.conf to accept the messages. Add an entry near
the bottom of the file that reflects facility.priority and destination
file name you want to log.  For example:
	local3.*                           /var/log/netscreen

I prefer to use the wildcard here to accept any messages to local3, and
adjust the level on the output device (the switch), but you can also
specify the priority here.

b.  Create the log file.  The file can be located anywhere, but /var/log
is standard.  As you can see I'm logging messages from my NetScreen
firewall.  The file needs to pre-exist; syslogd won't create it for you,
so "touch" it to create it and adjust rights per your needs.

c.  Change the /etc/rc startup script file to alter the syslogd launch
settings.  !WARNING! -- This file controls system startup.  You can screw
up your environment quite thoroughly by altering this file!  !WARNING!  I
wish that Apple provided the equivalent of FreeBSD's rc.conf file to make
these kind of changes, but they don't.  Use appropriate care and caution.

!NEXT WARNING!  The man page for syslogd is WRONG!  Don't reference it!
If you manually run /usr/sbin/syslogd, it will report its switch settings,
and you can see that they are different than those listed in the man page.
The man page at www.freebsd.org for syslogd seems to be more accurate, but
I don't fully trust it either, as I have no guarantee that it refers to
the same executable.

Locate the line in /etc/rc that reads: /usr/sbin/syslogd -s -m 0 The
needed change is to remove the -s setting to allow external host logging
via UDP.  The specific change that I made was to change that line to:
/usr/sbin/syslogd -vv -m 10.  This adds verbosity to the logging, removes
the -s setting, and sets the "mark" message interval to 10 minutes (the
default 0 setting disables mark messages).  Save and exit.

Note that this configuration opens your machine to potential DOS attacks
via UDP.  There are ways to restrict host access to syslogd, but they
require the correct @#$!#%$ documentation to implement.  This is fairly
safe in MY environment at the present time, you have to assess your own.

d.  Modify firewall settings as necessary to permit inbound syslog
traffic.  I don't run the Apple firewall on my syslog system, so can't
help with config details, but you need to permit in UDP on port 514 for
the sending host.

3.  Relaunch syslogd.  I prefer to reboot, since I want to verify that the
rc changes work correctly, but you can kill the current syslogd and
restart it with your new settings if you prefer.

4.  Verify that syslog messages are being sent, received, and logged.
Obviously if they are getting logged, the other steps work.  However,
depending on your sending device and the priority level you have set, you
may not see any messages.  Debugging steps I use include:

- using the logger utility to create local syslog messages and ensure they
get logged correctly.

- using tcpdump (tcpdump udp port 514) to verify that inbound messages are
being received.

- using debug syslog and/or temporarily changing the output priority level
on the switch to ensure it is kicking out messages.

5.  Note that after things are working, you may be getting duplicate
messages in your console.log or system.log, due to wildcard entries.  If
desired, you can use <facility>.none entries to block unwanted duplicates.

Hope this helps!

KeS