Certification Objective 14.03Managing System Messaging

Certification Objective 14.03—Managing System Messaging

Exam Objective 4.3: Explain syslog function fundamentals, and configure and manage the /etc/syslog.conf file and syslog messaging.

Applications (and processes) running on an operating system do malfunction from time to time, and generate errors. An application error may cause an operating system error, or the system may produce its own errors due to its own problems. The capability of capturing error-generating events and storing them (a process called logging) so that a system administrator can view and analyze them to take corrective action is an important requirement of any operating system.

Solaris uses the UNIX-native logging facility called syslog to handle system messaging. The system messaging function is run by the error-logging daemon, syslogd, which receives a message from a source (e.g., an application), adds some information to it such as a time stamp, and saves it in an appropriate message file. By default, the daemon displays these messages on the system console and stores them in the /var/adm/messages. * files. Of course, you can make changes to the default behavior by customizing the system message logging.

Fundamentals of System Message Logging

The syslogd daemon receives a message from the source and forwards it to a target such as the message log file. A system message consists of a single line of text, which in most cases includes the following information:

    [ID <msgid> <facility>.<priority>] 

For example:

    [ID 746763 kern.notice] 

This is the message that was originated in the kernel, and the kernel module name is displayed. The daemon may add a time stamp to the message. So the full displayed message may look like the following:

 Sep 29 21:41:18 agore ufs: [ID 746763 kern.notice] alloc /: file system full 

The two most important points about how system message logging works are:

• The syslogd daemon receives messages from the applications (processes) and sends them to the specified target: the system console or a file.

• The syslog allows you to capture messages by their source (e.g., type of process) and the level of priority (severity). Priorities are defined in the /sys/syslog.h file.

How are these two features implemented? In other words, how does the daemon know where to send the message, and how can you capture the messages based on source and priority level? This is accomplished through the configuration file:

    /etc/syslog.conf 

The /etc/syslog.conf file has two columns, which are described here:

• <facility>.<level>. The <facility> specifies the source of message (or error condition); it may be a list of comma-delimited names of sources. The <level> specifies the severity (or priority) of the condition being logged.

• <action>. This column specifies the comma-delimited list of targets (destinations) of the messages—that is, where the messages are being sent (e.g., the name of a file).

Examples of entries from the default /etc/syslog.conf file are shown here:

    user.err /dev/sysmsg    user.err /var/adm/messages    user.alert 'root, operator'    user.emerg * 

In all these entries, the facility source is the user that refers to the user processes. The first entry means that the message from the user processes with priority level should automatically be printed to the system console, while second entry means that these messages should also be logged to the /var/adm/messages file. The third entry means that the user messages with the alert priority level should be sent to the root and the operator, while the fourth entry means that the user messages with the emerg level (emergency messages) should be sent to the individual users.

The commonly used facility sources and priority levels are described in Tables 14-6 and 14-7, respectively.

Table 14-6: The most common error condition sources, called source facilities

Source Facility	Description
auth	Message comes from somewhere in the authorization system such as login and su.
daemon	Message source is a daemon such as httpd.
kern	Message generated by the OS Kernel.
lp	Message comes from the line printing spooling system.
mail	Message generated by the mail system.
user	Message generated by a user process.

Table 14-7: The most common priority levels for syslog messages

Priority Level	Description
emerg	System emergency. A panic condition.
alert	An error requiring immediate action to correct the situation.
crit	Critical error.
debug	The output used for debugging.
err	Other errors.
warning	Warning messages.
info	An informational message.
notice	Conditions that are not errors but may require special handling.
none	Specifies the do not log message for this system.

On the Job 

You can activate a source facility in the /etc/syslog.conf file. There is no limit on how many facilities you can activate.

Now that you know how syslog works, you need to know how to manage it.

Managing Syslog

To manage syslog, you need to know how to handle the syslog.conf file and the syslog daemon. We have already covered the syslog.conf file in the previous sections. The syslog daemon, syslogd, is started during bootup, and the command has the following syntax:

 /usr/sbin/syslogd [-d] [-f <configFile>] [-m <markInterval>] [-p <path>] [-t -T] 

Exam Watch

Make sure you recognize the facility (source), the priority level, and the message target (where the message will go) in an entry of the syslog.conf file. You should be able to interpret the entries in this file.

The options are described here:

• -d. Turn on debugging.

• -f <configFile>. Specify a configuration file. The default is /etc/syslog.conf.

• -m <markInterval>. Specify an interval in minutes between mark messages—that is, messages with a system time stamp. The default value is 20.

• -P <path>. Specify a log device name. The default is /dev/log.

• -T. Turn on logging of remote messages by enabling the UDP port of syslogd. This is the default behavior.

• -t. Turn off logging of remote messages by disabling the UDP port of syslogd.

The default settings reside in the /etc/default/syslogd file.

On the Job 

The -d option for the syslogd daemon to turn on debugging should only be used interactively in a root shell once the system is in multiuser mode. You should not use it in the system start-up scripts, because this will cause the system to hang when syslogd is started.

Note that the syslogd service is managed by the Service Management Facility (SMF) under the service identifier:

    svc:/system/system-log:default 

That means you can perform administrative actions on this service, such as enabling, disabling, or restarting by issuing the following svcadm commands:

    svcadm enable svc:/system/system-log:default    svcadm disable svc:/system/system-log:default    svcadm restart svc:/system/system-log:default 

You can query the status of the service by issuing the svcs command:

    svcs -1 svc:/system/system-log:default 

Now that you know how syslog works, here are some practical scenarios and their solutions.

SCENARIO & SOLUTION
What command would you issue to generate messages recently generated by a reboot or a system crash?	dmesg | more or more /var/adm/messages
Consider the following line in the syslog.conf file: *.alert root What does it say about who will get the system alert messages?	The superuser (root) will get all the system alert messages.
You want all the user emergency messages and user alert messages to be sent to individual users as well as the root. What entry in the syslog.conf file will ensure that?	user.emerg, user.alert 'root, *'

The three most important takeaways from this chapter are the following:

• The role-based access control (RBAC) security model offers a more secure arid flexible security system by allowing the superuser to create multiple administrators with different administrative capabilities.

• You can create, modify, and delete roles by using the roleadd, rolemod, and roledel commands, respectively, which work pretty much like the useradd, usermod, and userdel commands with the same options.

• The syslogd daemon, is responsible for logging the messages into the message files. You can manage syslog either by using the syslogd command or by using the SMF command svcadm on the service identifier svc:/system/system-log:default.