Syslog

This module presents the syslog facility, which allows the administrator to dispose of messages generated by the kernel, daemons and various utilities to log files of the superuser's choice, to the console, to specified users, or to syslog on another system. Syslog can also serve a security function.  It can keep track of where users may be logging in from.

 

Logging messages:

Syslog:

The process called syslog sends messages from system processes to the syslogd daemon.  The urgency level of these messages is predetermined by the process.

/etc/syslog.conf determines where these  messages go.

/var/adm/messages is where most of these messages go by default.

 

The files:

/etc/syslog.conf     format: 2 fields separated by a tab.

facility.severity_level           action

the facility is whatever sent the message...the cron daemon , the kernel...

the severity_level is more or less correlated with how important the message is.  It can be anything from none to emerg.

action is how you want to dispose of the message.  An entry of "console" means that messages from the indicated facility, at the indicated severity level and above will be sent to the console.  An entry of "@host" will send the message to the syslog facility at the host indicated. An entry of one or more users will send the message to the screen of those users, while * will send the message to all users logged in. An  entry of the form "/filename" will send the message to that file. The file /dev/sysmsg will send a message to the console.

 

Variations:

 

1) multiple entries in the facility.severity_level, separated by semi-colons.

2) * may replace facility, and indicates any facility.

3) none, used as the severity level of a facility listed after * , means make an exception for that facility.

 

 

 

Examples:

mail.crit       /var/adm/messages           

sends all messages from mail at level crit (or above) to /var/adm/messages

*.emerg        root             

sends all messages of level emerg to root.

 

*.emerg;mail.crit              /var/logfile             

sends all messages of level emerg AND all messages from mail of level crit (or above) to a file called /var/logfile.

 

*.crit;mail.none      @masterserver        sends all messages of level crit except those generated by mail to the syslogd daemon on the system "masterserver."

 

/etc/syslog.conf is read by syslogd when it starts, so if you alter it, you must start and restop the syslogd daemon, either by rebooting or with

 

svcadm refresh system/system-log    

 

m4

The file /etc/syslog.conf is read by a macro processor called m4, which is called by the daemon syslogd. At startup, syslogd tries to contact the system in /etc/hosts which has the alias loghost using the syslog port; if it finds it is talking to itself, that is, if the system "loghost" is the local machine,  it runs the m4 processor using m4  -DLOGHOST=1, so that the variable LOGHOST is defined (=1). If it finds it is talking to another host, LOGHOST is undefined (=0) and syslog runs the m4 processor without the option. Loghost is usually undefined when the system is a NIS client. If loghost is not resolvable at all to an IP address, syslogd issues
a warning and ignores any .conf lines pointing at @loghost

 

As long as a line does not contain the word ifdef, the m4 processor passes it verbatim to syslogd. Thus the contents of the first part of the file /etc/syslog.conf goes directly to syslogd. 

 

The default syslog.conf contains two m4-parsed statements.

 

The first is :

 

mail.debug                      ifdef(`LOGHOST', /var/log/syslog, @loghost)

 

The m4 ifdef( , , ) is a simple conditional test and replacement.  The first element is a definition which is tested for existence. If the definition exists, the whole construct is replaced by the string following the first comma. If the definition does not exist, the whole construct is replaced by the string following the second comma.

 

Thus for the above example,

 

If there are one or more "loghost" entries in /etc/hosts and the first occurs adjacent either to the entry, "localhost" or the system's hostname, syslogd will set the "LOGHOST" variable for m4 to 1 (i.e. LOGHOST will be defined), syslog gets the configuration line:

 

mail.debug     /var/log/syslog

 

and if loghost is a remote host (i.e. LOGHOST is not defined), syslog gets the configuration line:

 

mail.debug     @loghost

 

The second entry in syslog.conf which is parsed by the m4 processor is :

 

ifdef(`LOGHOST', ,

user.err                                        /dev/sysmsg

user.err                                        /var/adm/messages

user.alert                                      `root, operator' (operator is a special account from

mainframe days, not used any more)

user.emerg                                      *

)

 

In this definition, if loghost is the local host, syslogd gets nothing.

 

If loghost is a remote host, syslogd gets the following four lines

 

user.err       /dev/sysmsg

user.err       /var/adm/messages

user.alert     root, operator         

user.emerg     *

 

inetd

 

inetd is the daemon that manages ftp and telnet connections among others. By default it does not send messages about logins to syslogd for disposal.  Such messages can easily be set up, in which case messages of facility daemon at level notice (daemon.notice) are sent to the indicated location every time someone tries to make an ftp or telnet connection to your machine.  These notices include the IP address and process used, and allow you to maintain a list of where remote connections are coming from.

 

Practice

1.There are two parts to logging messages from inetd:

A. Have inetd begin sending messages.  This is done by changing the properties of inetd in the SMF. Show properties with

 

inetadm -p

 

tcp tracing is set to FALSE.  This can be modified with

 

inetadm -M tcp_trace=TRUE

 

to set tracing for all services, which is probably more than you want. To set tracing for just one service:

 

inetadm -m telnet tcp_trace=TRUE

 

Check this setting with

 

inetadm -l telnet | grep tcp

 

B. Create the logging file /var/telnets ( or any other name you want to use)

touch /var/telnets

C. Add a line to the top part of /etc/syslog.conf to send the messages wherever you want them to go (if a file, it must exist), and restart syslogd.

vi /etc/syslog.conf

add line:

daemon.notice                  /var/telnets

 

svcadm refresh system/system-log

 

2. Test logging.

A. Spy on /var/telnets

tail -f /var/telnets

B. Telnet to your own system

telnet localhost

C. look in /var/adm/messages. What is in there and why?

tail  /var/adm/messages

 

3. You can write to your syslogd log files with the utility logger.  Logger sends messages by default at the priority level user.notice. You can also give it a specific priority using logger -p facility.severity_level . Logger is most commonly used in shell scripts.

 

A. Try this, while spying on /var/telnets:

logger -p daemon.notice tangerine

 

B. Logger can also place a tag on the line which replaces the user name:

logger -p daemon.notice -t tuesday pear

 

C.  By default logger writes to the location where messages of level user.notice are sent.

vi /etc/syslog.conf

add a line

user.notice   /var/telnets

 

svcadm refresh system/system-log

 

tail -f /var/telnets

logger -t friday stuff4

 

Logging su

 

auth is the utility that controls su.  When a user su's to another user, a message is sent to the console.  A second line may be sent if the line CONSOLE=/dev/console is uncommented in /etc/default/su.

 

A. Check that the message works:

Make sure ONE console window is open:

su user1 (create user1 if it does not already exist)

su root

exit

 

You will get a message after the first su to root. After that, you will get no more messages sent via syslog until you have su'ed to root 3 more times.

At that point a message is sent saying that the previous message has been repeated 3 times.

 

B. Edit /etc/syslog.conf and add the following line:

auth.notice             /var/adm/messages

 

Also: remove auth.notice from the list of messages sent to /dev/console

C. Stop and restart syslogd

 

svcadm refresh system/system-log

 

D. Test with su again:

su user1

su root

E. Check /var/adm/messages for notices about su (try a few times if it doesn't work immediately).

 

Added notes:

 

An ongoing problem with syslog is getting unwanted remote messages from other hosts.  You can certainly turn off remote logging for syslog altogether, by starting syslogd with the –t option.  However, this disables ALL remote logging.  There is no built in way to selectively disable remote logging for certain hosts, however, it may be possible to reduce the problem by changing the port to which syslogd listens. By default (see /etc/services) this port is 514/udp. 

 

Hosted by www.Geocities.ws

1