Solaris

Standard Solaris syslog system consists of the following components:

syslogd — the system daemon used to receive and route system log events from syslog() calls and logger commands
/etc/syslog.conf — the configuration file used to control the logging and routing of system log events
logger — a UNIX command used to add single-line entries to the system log

. See also ogger

syslog() — an application program interface (API) referenced by several standard system utilities and available to anyone writing software in the C programming language, C++, Java and many scripting languages (Perl is one example).
logadm -- System Log Rotation Utility (Solaris 9 and later)

The key file that is influencing syslog behavior is /etc/syslog.conf file. It contains two colums called the selection and action.

selector field: a semicolon-separated list of priority specifications in the following format: facility.level; facility.level.
action field: defines where to forward the message. This field can have one or several of the following entries four types of entries:

1. file Output sent to the file specified

2. @host The @ sign denotes that messages must be forwarded to a host The name should be defined in /etc/hosts and represent a remote logserver.

3. user[,user] The user(s) (can be comma delimitated list) receive messages if they are logged in.

4. * All logged in users will receive messages when they are logged in.

As typical for Sun the file has a dinosaur (pre-70th style) syntax, as it does not permit using spaces as a separator, tabs should be used as a separator between two columns of syslog.conf. Now let's discuss those two columns is some details:

The selector field is a semicolon-separated list of priority specifications in the following format: facility.level; facility.level.

The facility field can contain only 16 codes:

kern Messages generated by the kernel.
user Messages generated by user processes. This file does not list the default priority for messages from
programs or facilities.
mail The mail system.
daemon System daemons, such as the in.ftpd and the telnetd daemons.
auth The authorization system, including the login, su, and ttymon commands.
syslog Messages generated internally by the syslogd daemon.
lpr The line printer spooling system, such as the lpr and lpc commands.
news Files reserved for the USENET network news system.
uucp The UNIX-to-UNIX copy (UUCP) system does not use the syslog function.
cron The cron and at facilities, including crontab, at, and cron.
local0-7 Fields reserved for local use.

the level selector specifies the severity or importance of the message. Each level includes all the levels above (of a higher severity). To remember the sequence for the certification exam you can use an appropriately constructed phase like "Every alerted cardriver escapes warning notice"

emerg 0 Panic conditions that are normally broadcast to all users
alert 1 Conditions that should be corrected immediately, such as a corrupted system database. Only sysadmin of a particular server needs to be informed by mail or paged.
crit 2 Warnings about critical conditions, such as hard device errors.
err 3 Errors other than hard device errors
warning 4 Warning messages
notice 5 Non-error conditions that might require special handling
info 6 Purely informational messages (usually does not require any handling)
debug 7 Messages that are normally used only when debugging a program
none 8 Messages are not sent from the indicated facility to the selected file

After making any changes to syslog.conf file, you need to ask the daemon to reread the configuration file with kill -HUP command, for example pkill -HUP syslogd. This is an operation that is often forgotten. It might make sense to implement "system configuration" attribute that can automatically send executes a command after closing of the file with such attribute if it was opened for writing (Unix has "command execution string" for scripts forever, for example #!/usr/bin/perl, so it can be used for configuration files). In the absence of such facility that would be a real paradise for absent minded people like me you probably will be better off creating a special script, like visyslog that contains just two command: vi and pkill to ensure that you do not forget this operation; I often do and then face consequences)

The default Solaris syslog configuration (/etc/syslog.conf) is far from being optimal (any selector in /etc/syslog.conf means "this level and higher", for example mail.crit includes mail.emerg):

*.err;kern.notice;auth.notice                 /dev/sysmsg
*.err;kern.debug;daemon.notice;mail.crit      /var/adm/messages

*.alert;kern.err;daemon.err                   operator
*.alert                                       root
*.emerg                                       *

# if a non-loghost machine chooses to have authentication messages
# sent to the loghost machine, un-comment out the following line:
#auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost)

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

#
# non-loghost machines will use the following lines to cause "user"
# log messages to be logged locally.
#

ifdef(`LOGHOST', ,
user.err                                     /dev/sysmsg
user.err                                     /var/adm/messages
user.alert                                   root, operator
user.emerg                                     *
)

For one thing, AUTH messages don’t get logged to any logfiles. This is important if you want to know when people are trying to break into your system so such messages should be emailed at least to operator (may be operator and root) and written to /var/adm/authlog

*.emerg *

*.kernel.notice;*.alert root,operator

*.err;kern.notice;auth.notice    /dev/sysmsg

*.notice    /var/adm/messages

auth.notice    /var/adm/authlog, /var/log/messages

Each line of the file contains two parts:

A selector that specifies which kinds of messages to log (e.g., all error messages or all debugging messages from the kernel).
An action field that says what should be done with the message (e.g., put it in a file or send the message to a user's terminal).
You must use the tab character between the selector and the action field. If you use a space, it will look the same, but syslog will not work.

Message selectors have two parts: a facility and a priority. kern.debug, for example, selects all debug messages (the priority) generated by the kernel (the facility). It also selects all priorities that are greater than debug. An asterisk in place of either the facility or the priority indicates "all." (That is, *.debug means all debug messages, while kern.* means all messages generated by the kernel.) You can also use commas to specify multiple facilities. Two or more selectors can be grouped together by using a semicolon. (See the earlier examples.)

The action field specifies one of five actions (some versions of syslog support additional actions, such as logging to a proprietary error management system):

1. Log to a file or a device
In this case, the action field consists of a filename (or device name), which must start with a forward slash (e.g., /var/adm/lpd-errs or /dev/console). Beware: logging to /dev/console creates the possibility of a denial of service attack. If you are logging to the console, an attacker can flood your console with log messages, rendering it unusable. If your system supports virtual consoles, as with Linux, you can usually safely log to one of the virtual consoles, and leave the others uncluttered.

2. Send a message to a user. In this case, the action field consists of a username (e.g., root). You can specify multiple usernames by separating them with commas (e.g., root,nosmis). The message is written to each terminal where these users are shown to be logged in, according to the utmp file.

3. Send a message to all users. In this case, the action field consists of an asterisk (*).

4. Pipe the message to a program . In this case, the program is specified after the Unix pipe symbol (|). Note that the current Solaris version syslog does not support logging to programs. You need to use syslog-ng to achieve that.

5. Send the message to the syslog on another host. In this case, the action field consists of a hostname preceded by an at sign (e.g., @prep.ai.mit.edu).

With the following explanation, understanding the typical syslog.conf configuration file shown earlier becomes easy:

*.err;kern.debug;auth.notice /dev/console

This line causes all error messages, all kernel debug messages, and all notice messages generated by the authorization system to be printed on the system console. If your system console is a printing terminal, this process will generate a permanent hardcopy that you can file and use for later reference. (Note that kern.debug means all messages of priority debug and above.)

daemon,auth.notice /var/log/messages

This line causes all notice messages from either the system daemons or the authorization system to be appended to the file /var/log/messages. Note that this is the second line that mentions auth.noticemessages. As a result, auth.notice messages will be sent to both the console and the messages file.

lpr.* /var/log/lpd-errs

This line causes all messages from the line printer system to be appended to the /var/log/lpd-errs file.

auth.* root,nosmis

This line causes all messages from the authorization system to be sent to the users root and nosmis. Note, however, that if the users are not logged in, the messages will be lost.

auth.* @prep.ai.mit.edu

This line causes all authorization messages to be sent to the syslog daemon on the computer prep.ai.mit.edu. If you have a cluster of many different machines, you may wish to have them all perform their loggings on a central (and presumably secure) computer.

*.emerg *

This line causes all emergency messages to be displayed on every user's terminal.

*.alert |dectalker

This line causes all alert messages to be sent to a program called dectalker, which might broadcast the message over a public address system.

mark.* /dev/console

This line causes the time to be printed on the system console every 20 minutes. This is useful if you have other information being printed on the console, and you want a running clock on the printout.

Solaris

Pages

Search This Blog

Tuesday, May 11, 2010

Snoop on Solais10

Syslog Configuration...

Monday, April 12, 2010

Solaris 10 Installation

About Me

Blog Archive