Managing System Logging
If one of your mail services crashes, you will want to be notified. If a daemon fails, or if someone is trying to hack into the network, you will want to know as well. Solaris provides a centralized logging service, called syslog, to keep track of these types of events through system logging. The syslogd daemon manages system logging. It is responsible for retrieving and logging messages, as well as forwarding alerts to the proper users and consoles.
Thus far in this chapter, the scope of system logging has been limited to critical events. However, syslog messages can range from emergency-type alerts to notices that don't require immediate attention to informational postings. One of the benefits of syslog is that it's very flexible.
The syslogd daemon depends on the presence of the m4 macro processor to operate properly. The m4 macro processor is a UNIX-standard front-end processor intended for use with the C, assembler, and other programming languages. m4 helps syslogd process messages and is also capable of performing integer arithmetic, file inclusions, conditional macro expansions, and string and substring manipulations. Macros, in general, enable you to create short programs to automate repetitive tasks, thus saving you work. Because the logging and sending of messages generated from auditing is a repetitive task, the m4 macro processor fits in perfectly with system auditing. The support files for m4 are located in /usr/ccs/bin/m4. For more information, type man m4 at the command prompt.
During boot, syslogd is started by the /etc/rc2.d/S74syslog script. The syslogd daemon reads the STREAMS log driver (/dev/log), the /etc/netconfig file, and the /etc/ syslog.conf file for configuration information, and then creates the /etc/syslog.pid file, which contains its process ID. Rebooting the system or sending a HUP (hangup) signal to syslogd will cause it to restart and reconfigure itself. Information on the behavior of syslogd is stored in /etc/default/syslogd. For example, in /etc/default/syslogd, you can configure syslogd to log remote messages in addition to local messages with the line LOG_FROM_REMOTE=YES. A value of NO disables remote logging. By default, this line is commented out.
Most error messages collected by syslogd are logged in the /var/adm directory and written to the local console. However, logging behavior is configurable through the /etc/syslog.conf file.
Configuring syslog.conf
The single most critical configuration file for system auditing and messaging is the /etc/ syslog.conf file. Entries in the syslog.conf file have two fields: a selector and an action. These fields are separated by tabs. The selector field consists of a pair of keywords, a facility and a level, and classifies both the source of the message and the level of severity of the problem. The action field can take one of four forms and defines the action to take based on the message type received.
Table 14.1 lists the valid facility keywords.
| Value | Description |
|---|---|
| user | Messages generated by user processes. Also used for applications, programs, or other facilities not explicitly listed in this file. |
| kern | Messages generated by the system kernel. |
| | sendmail messages. |
| daemon | Messages generated by recognized system daemons. |
| auth | The Solaris authorization system, such as login, su, and getty. |
| lpr | Printing messages and errors. |
| news | The USENET network news system. |
| uucp | Reserved for future UUCP logging, as UUCP currently does not use syslog. |
| cron | cron/at messages. Includes crontab, atq, and associated commands. |
| local0-7 | Reserved for local system use. |
| mark | Timestamp messages produced by syslogd. |
| * | Indicates all facilities except for mark. |
Facilities are paired with levels to complete the selector field. The valid level values are listed in Table 14.2, in decreasing order of severity.
| Value | Description |
|---|---|
| emerg | Panic conditions, normally broadcast to all logged-in users. |
| alert | Situations that should be corrected immediately, such as a corrupted system database. |
| crit | Critical conditions, such as unrecoverable device errors. |
| err | Other errors. |
| warning | Warning messages. |
| notice | Conditions that are not error messages but might require special handling. |
| info | Informational messages. |
| debug | Messages used for the debugging of programs. |
| none | Does not send a message from the facility to the log file. Using the none keyword effectively turns off auditing for that facility. |
| Note | The severity level priorities are defined in the sys/syslog.h file (the actual physical location will depend on your computer's platform). |
After the selector field is the action field. There are four possibilities for actions:
-
A filename indicating where to write messages generated by the selector field. New messages will be appended to the existing message file. If the file specified does not exist, logging will silently fail.
-
The name of a remote host, in the form of @computer. The message will be forwarded to syslogd on the remote host and processed accordingly.
-
A list of usernames, separated by commas. If the specified users are logged in, a message will be written to the console they are logged into.
-
An asterisk, which means that the message generated will be written to all logged-in users.
Here is a sample /etc/syslog.conf file:
#ident "@(#)syslog.conf 1.5 98/12/14 SMI" /* SunOS 5.0 */ # # Copyright (c) 1991-1998 by Sun Microsystems, Inc. # All rights reserved. # # syslog configuration file. # # This file is processed by m4 so be careful to quote (`') names # that match m4 reserved words. Also, within ifdef's, arguments # containing commas must be quoted. # *.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 * )
Blank lines are ignored, and lines beginning with a pound sign (#) are comments (they're not processed-they're there only for our information). The syslog.conf file can use ifdef statements to explain actions to the m4 processor. In other words, "If A exists, do B." In the syslog.conf file, ifdef statements allow for three arguments (enclosed in parentheses and separated by commas). The first is the if condition, the second is the def condition for when the if exists, and the third is the def condition for when the if does not exist. For more information, type man m4 at the command prompt.
Now that you know what the ifdef statement means, take a look at the selector and actions pairs, separate from the rest of the file:
*.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 *
The first line logs all errors, kernel notices, and authorization notices to the /dev/sysmsg file. The second line sends all errors, kernel debugs, daemon notices, and critical mail problems to the /var/adm/messages file. The third line sends all alerts, kernel errors, and daemon errors to the operator user. The fourth line sends all alerts to the root, if they are logged in, and the last line will, in the event of an emergency, write a message to the console of every logged-in user.
To illustrate some of the other options, here are a few more lines:
mail.debug /var/spool/mqueue/logfile auth.* @server1
The first line will send any mail debug messages to the /var/spool/mqueue/logfile file, and the second line will send any messages involving Solaris authorization to the server1 computer. You can also disable messaging for a service, such as with this option:
*.debug;mail.none /var/adm/messages
This will log all debug messages but disable mail messages. Because the mail system, sendmail, logs a lot of messages, this might not be a bad idea. Just keep in mind, though, that if you're troubleshooting an e-mail problem, the messages generated by sendmail can be extremely helpful.
Managing Log Files
Solaris has a number of built-in log files that it uses to store information. Most of the log files are located in the /var/adm directory, although you can place log files in any file system you want (but it's best to avoid /tmp for obvious reasons).
Here is a list of some of the more important log files:
-
/var/adm/messages lists information that prints to the local console. This file will usually include all root logins and can grow very large very fast.
-
/var/adm/lastlog contains the most recent login time for each user in the system.
-
/var/adm/utmpx stores user access and accounting information. Running the who command will display information from this file.
-
/var/adm/wtmpx holds a history of user access to the system. Running the last command will pull information on the last logged-in user, from this file.
-
/var/adm/sulog shows all su attempts, both successful and failed.
-
/var/log/syslog displays logged system information.
-
/var/cron/log tracks all cron and at activity.
Because most logs are located in /var/adm anyway, most administrators will create their own specific logs there as well. But as was mentioned earlier in this chapter, if you attempt to log to a file that does not exist, the logging will silently fail. Therefore, if you intend to use your own unique log file, you need to ensure that it's created and ready for use. For example, if you wanted to create a log file named /var/adm/adminlog, you could follow these steps:
# touch /var/adm/adminlog # chmod 600 adminlog
You'll also want to verify the ownership of the log file because you don't want the log falling into the wrong hands.
Log files can get very large, so you will want to periodically clean out old log files to save hard disk space. Also, log files are rotated by Solaris through the logadm command listed in the root crontab file. (The old method of using the /usr/lib/newsyslog script is no longer used.) To define the system log rotation, edit the /etc/logadm.conf file. Old log files are renamed with a numeric extension. For example, when a new syslog file is created, the old file becomes syslog.0, and the next recent file becomes syslog.1, and so on.
Using the logger Command
System logging is an automatic process. You configure it, and then logging happens automatically based on system events occurring. Although automatic logging is convenient, at times you might want to manually add an entry into the system log. For example, you might want to add a line to the system log as a bookmark (perhaps you've reviewed the log up to that point), or you might want to log a note describing why you manually rebooted the server. You can do this from the command line with the logger command.
Here is the syntax for logger:
# logger arguments message
The logger command supports four arguments. They are listed in Table 14.3.
| Argument | Description |
|---|---|
| -f file | Logs the contents of the specified file. |
| -i | Includes the process ID of the logger command with each line logged. |
| -p priority | Enters the message with the specified priority, in the form of facility.level. The default priority is user.notice. |
| -t tag | Marks each line added to the log with the specified tag. |
You can supply one message to log at a time, unless you use a file to log. In that case, each line of the file is logged separately. You'll notice that the default priority is user.notice. If you look at the default /etc/syslog.conf file provided earlier in this chapter, you will see no default destinations for user.notice. So, if you want logger to actually log something, you will either need to reconfigure your syslog.conf file (and restart syslogd), or use another priority, such as user.err (or another facility.level pair that's already set up for logging).
| Warning | If you use *.emerg with the default syslog.conf, the message you log will be written to all users logged into your Solaris computer, so be careful what you say! |
Configuring the inetd Process
The Internet services daemon (inetd) is a critical process for logging connections over networks. Started during the Solaris boot process, inetd actively listens for remote service requests on the TCP or UDP ports associated with the services listed in its configuration file. When a request is received, inetd starts the local process associated with the request.
inetd is responsible for allowing remote connections and is capable of logging all remote TCP or UDP connections. Both IPv4 and IPv6 are supported by inetd. The configuration file for inetd is /etc/inetd.conf. Another important file for the inetd daemon is /etc/ default/inetd, which contains the parameter to enable connection logging.
The /etc/default/inetd file has two parameters: ENABLE_CONNECTION_LOGGING and ENABLE_TCPWRAPPERS. Both settings are commented out (as well as set to NO) by default. If you want to log all incoming connections, you need to change ENABLE_CONNECTION_LOGGING to YES and uncomment the line.
| Tip | Disabling unneeded connection types in the inetd.conf file is a good way to increase your network security. If the services are disabled, no one can connect to your computer by using them nor use the ports that those services use as a back door to hack your computer. |
For security purposes, it's a good idea to log all incoming requests on important machines such as servers. This is especially true for servers that can be directly accessed from the Internet, such as e-mail, web, or FTP servers.
 |
You have been the Solaris administrator at your company for just over a year. Most of the time, the network operates with few problems. Occasionally, however, "mysterious" problems develop, and it seems to take you a long time to figure out why the problem is happening. After you track down the problem, you can usually fix it quickly. The more common problems involve the e-mail server and printing, but you're also concerned about potential security breaches.
You're constantly looking for tools to help you in your troubleshooting. One of the things you can do is use system messaging to your advantage. Create separate log files for the e-mail and print servers, and set up the syslog.conf file (with the mail and lpr facilities) to log e-mail and printer messages to their respective files. You can also set up an additional log file to track all user logins, using the auth facility in the syslog.conf file.
The log files themselves won't fix your problems, but at least the messages contained within can help you track down the problem in less time than it would take you otherwise.
|
|
|
EAN: 2147483647
Pages: 194