|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
|
|
 |
 |
 |
The syslog system is one of the most delightful things about Unix. Unlike some operating systems that force you to use the limited range of logs that they condescend to provide, Unix allows you to log almost anything, at almost any level of detail. While system logging hooks are provided for the most common Unix resources, administrators can choose a logging configuration that meets their needs. My networks usually have a single logging host that handles not only the FreeBSD boxes, but Cisco routers, switches, and any other syslog-speaking systems.
The system logger is actually fairly straightforward. Programs send log entries to the system logging daemon, syslogd. Syslogd compares each submission to the entries in /etc/syslog.conf. When it finds a matching entry, it processes the log entry in the manner described.
/etc/syslog.conf has two columns. The first is the system providing the information to be logged. The second is the action to be taken when a log message matches. The most confusing part is understanding exactly how to specify a logging information source.
The standard method of specifying a logging source is by facility and level. A facility is a log entry source, or a program that sends messages to syslogd. These facilities are described below.
auth Anything having to do with user authorization, such as login and su.
authpriv This is identical to auth, except it logs to a file that only selected users can read.
console Messages that are normally printed to the system console can be captured by using the console facility.
cron Messages from the system scheduler.
daemon This is a catch-all for all system daemons that don't have other explicit handlers.
ftp You can configure your FTP daemon to log its transfers. See /etc/inetd.conf.
kern This is for messages from the kernel.
lpr Messages from the printing system
Messages from the mail system
mark This isn't an actual log from a system; instead, the mark facility puts a notification in your log every 20 minutes. This is useful combined with some other log.
news Messages from the Internet News daemons.
ntp Messages from Network Time Protocol
security Messages from various security systems, such as ipf(8) and ipfw(8).
syslog Yes, the log service can log to itself. Just don't log when you log logs from the log system, or you'll make yourself dizzy.
user The catch-all messages facility. If you don't specify a logging facility for user programs, they'll use this.
uucp Logs from the Unix-to-Unix Copy Protocol. This is a piece of Unix history you'll probably never encounter.
local0 through local7 These are reserved for administrator use. Many programs have an option to set a logging facility; choose one of these if at all possible.
Most systems don't log everything their programs send to syslog; rather, they discard trivial messages and only record the important stuff. One man's trivial is another's vital data. This is where the level comes in.
Also in Big Scary Daemons:
FreeBSD offers eight levels of syslog importance. You can use these levels to tell syslog what to record and what to discard. The levels follow, in order from most to least important.
- emerg -- System panic. Messages are flashed on every terminal. The system is basically hosed, or at best horribly, horribly unstable.
- alert -- This is bad, but not as bad as the emerg level. The system can continue to operate, but this error should be attended to immediately.
- crit -- These are critical errors, such as hardware problems or serious software issues. If your hard drive has bad blocks, they'll show up as critical errors. You can continue running, if you're brave.
- err -- Miscellaneous errors. They're bad, and should be fixed, but aren't going to destroy the system.
- warning -- Miscellaneous warnings.
- notice -- General information that should be logged, in case you need it, but probably doesn't really require action on your part.
- info -- General system information.
- debug -- This level is usually only of use to programmers, and occasionally to system admininistrators who are trying to figure out just why some program behaves in this way. Debugging logs can contain whatever information the programmer felt necessary to debug the code; this might include information that will violate this users' privacy.
- none -- This special level means "don't log anything from this facility here." It's most commonly used when excluding information from wildcard entries.
Information sources include both a facility and a level, separated by a period. When you specify a level, the system defaults to recording messages of that level or greater. For example, look at this entry from /etc/syslog.conf.
mail.info /var/log/maillogMessages from the mail system, with a level equal to or above info, are logged to /var/log/maillog.
If you like, you can use wildcards in your information source. To log absolutely all messages from the mail system, you would use this.
mail.* /var/log/maillogTo log everything from everywhere, uncomment the all.log entry.
*.* /var/log/all.logThis works, but it's far too full of information to be of any real use; you'll find yourself building complex grep commands just to find what you want.
Also, this would include all sorts of private information, thanks to the debug level. You probably don't want to record that sort of thing. You can exclude authentication information with the authpriv facility and the none level. The semicolon allows you to combine entries on a single line.
*.*;authpriv.none /var/log/all.logYou can also use comparison operators in /etc/syslog.conf. The valid operators are < (less than), = (equals), and > (greater than). You might want to have a log for mail traffic, and another for mail debugging.
mail.info /var/log/maillog mail.=debug /var/log/maillog.debugThis way, you don't have to sort through debugging information to learn what your mail server thinks it's doing.
Similarly, you might have a program that wants to log to local3. You can set this up as such.
local3.* /var/log/whateverYou can also use a program name as an information source. If a program supports a facility, use it. If you're out of facilities, however, or if your program simply doesn't support syslogd, you can use the name.
An entry for a name requires at least two lines. The first is the program name with a leading exclamation point. The second is the logging information. For example, look at the sample entry for logging PPP.
!ppp *.* /var/log/ppp.logIt starts by specifying the program name, and then tells syslogd to append absolutely everything to a file. You can't be certain a random third-party program will have reasonable logging facilities, so it's safest to record everything.
Finally, we have the log message destination. The most common destination is a log file, specified by full path name, but there are other destinations.
You can send log messages to another host with the @ symbol. The following example would dump everything your syslog receives to the logging host on my network.
*.* @loghost.blackhelicopters.orgThe /etc/syslog.conf on the loghost will be used to send messages to their final destinations.
You can list user names, separated by commas. If they're logged in when the log message arrives, the system will write the message on its terminal.
If you want the messages to be written to all users' terminals, use a destination of "*".
Finally, if you want another program to handle the logs, you can use a pipe symbol to redirect the messages to that program.
mail.* |/usr/local/bin/mailstats.plNow that you have logging running, all you have to worry about is your logs eventually filling your disk. We'll cover that next time, when we discuss newsyslog.
Michael Lucas lives in a haunted house in Detroit, Michigan with his wife Liz, assorted rodents, and a multitude of fish. He's the author of Absolute BSD and Absolute OpenBSD, and is currently preparing a book about NetBSD.
|
|
|
|
|
|
One of the most neglected area of Unix is handling system events. Daily checks for system messages is crucial for the security and health conditions of a computer system.
System logs contain much "noise" - messages which have no importance - and on the contrary important events, which should not be lost in the load of messages. With current tools it's difficult to select which messages we are interested in.
A message is sent to different destinations based on the assigned facility/priority pair. There are 12+8 (12 real and 8 local) predefined facilities (mail, news, auth etc.), and 8 different priorities (ranging from alert to debug).
One problem is that there are facilities which are too general (daemon), and these facilities are used by many programs, even if they do not relate each other. It is difficult to find the interesting bits from the enourmous amount of messages.
A second problem is that there are very few programs which allow setting their "facility code" to log under. It's at best a compile time parameter.
So using facilities as a means of filtering is not the best way. For it to be a good solution would require runtime option for all applications, which specifies the log facility to log under, and the ability to create new facilities in syslogd. Neither of these are available, and the first is neither feasible.
One of the design principles of syslog-ng was to make message filtering much more fine-grained. syslog-ng is able to filter messages based on the contents of messages in addition to the priority/facility pair. This way only the messages we are really interested in get to a specific destination. Another design principle was to make logforwarding between firewalled segments easier: long hostname format, which makes it easy to find the originating and chain of forwarding hosts even if a log message traverses several computers. And last principle was a clean and powerful configuration file format.
This article tries to give you an overview on syslog-ng's internals, for more detailed information see http://www.balabit.hu/products/syslog-ng and select the documentation link.
|
|
|
|
|
|
This paper is intended to assist a data center manager in setting up a centralized syslog server. There are a variety of commercial packages that deal with security and troubleshootp0111/syslog.html">Daemon News Logging Syslog to a Database
I'm working on set of scripts and tools to automate log management, but they are not yet finished. You can always contact me for more information at [email protected].
I would like to thank Kamil Andrusz and Maciej Kozak for support.
[1] - stunnel - SSL tunnel - http://www.stunnel.org/
[2] - syslog-ng - Syslog next generation - http://www.balabit.hu/en/products/syslog-ng/
[3] - msyslog - Modular syslog - http://www.corest.com/solutions/products.html
[4] - sqlsyslogd - SQL syslog extension. - http://www.frasunek.com/
[5] - syslogd+mysql - Patched FreeBSD syslogd - http://keves.org/dev/files/syslogd+mysql.tgz
|
|
|
|
|
|
System messages in a UNIX system are handled by syslog. The responsibilities of syslog are to filter and disperse program generated messages based on a priority code contained in each message. Filtering with priority codes is not sufficient to generate enough usable information for the system administrator. Utilities which do regular expression parsing of syslog messages typically do not run continuously and thus are limited by a lack of state in detecting potentially important patterns in syslog messages.
Classic way to resolve this problem is peephope optimizers that look into a fixed window (last N messages). They improves the monitoring of systems by extending the existing syslog infrastructure with programmable (usually Perl-based) modules. These modules use a library with a simple API to perform near real time analysis based on the messages they register to receive. System administrators peephole optimizers to improve the services provided by their systems without the need for constant manual evaluation of message logs.
The "system logger'', or syslog, gives programs a standard interface to report interesting events to the administrator. These messages are read by a background daemon and routed accordingly. The data which a program passes to syslog is called a message. A message consists of two parts: priority and textual data [9]. The priority of a message also contains two parts: an encoded facility and level. The facility of a message is a general category into which the message fits. The level of a message is a way for the program to rate the severity of the message, typically ranging from emerg to debug. The textual data of a syslog message is a string provided by the program that describes the event being logged.
I used the logger utility(this was provided by Michael Kriss) that allowed me to test out these entries by issuing the following:
logger -p local0.debug "this is a test"
logger -p cron.info " this is a test"The syslog daemon, syslogd, acts as the router for system messages. When it receives a message from a program, it in turn must decide what to do with the it. Most commonly this action involves writing the message to disk, but other potential actions include printing it to the system console, notifying online users, or forwarding the message to another system. syslogd makes these decisions based on a configuration file written by the system administrator. The rules in this configuration file are based entirely on the priority of the message.
The standard syslog daemon [Note 1] lacks many important features. These features impact the the reliability of message delivery and the integrity of messages after delivery.
There is no standard structure for writing syslog messages. A cleverly written program could bypass the syslog library calls and write directly to the listening syslogd socket. When syslogd reads this message, it will prepend default priority information and route the message according to these defaults. While the lack of message structure is not critical for system operation, it does not encourage good security.
Some versions of syslog have the ability to route messages based upon regular expression filtering. This allows greater discrimination and handling of messages than is possible with priority filtering. Sophisticated classification and processing of messages is still difficult with regular expression filtering. Extending syslog in this manner violates the UNIX design philosophy of simple tools doing one thing well. Extra processing must be performed with each message, which decreases message handling capacity.
Syslog permits file redirection via pipe symbol.
Standard facility for logging in Unix env. is syslogd diamon. Depending on the configuration of /etc/syslog.conf, it accept messages form subsystems and write it in an appropriate system log, writes it to the system console, forwards it to a list of users, or forwards it to syslogd on another host over the network.
Each logged message includes a message header and a message body. The message header consists of a facility indicator, a severity level indicator, a timestamp, a tag string, and optionally the process ID.
The message body is generated from the message and arguments to the call in the same manner as if these were arguments to printf function and include severity level and facility that indicates the application or system component generating the message.
Possible values of severity level include:
- LOG_EMERG A panic condition. This is normally broadcast to all users.
- LOG_ALERT A condition that should be corrected immediately, such as a corrupted system database.
- LOG_CRIT Critical conditions, such as hard device errors.
- LOG_ERR errors
- LOG_WARNING Warning messages.
- LOG_NOTICE Conditions that are not error conditions, but that may require special handling.
- LOG_INFO Informational messages.
- LOG_DEBUG Messages that contain information normally of use only when debugging a program.
Possible facility values include:
- LOG_KERN Messages generated by the kernel. These cannot be generated by any user processes.
- LOG_USER Messages generated by random user processes. This is the default facility identifier if none is specified.
- LOG_MAIL The mail system.
- LOG_DAEMON System daemons, such as in.ftpd(1M) .
- LOG_AUTH The authorization system: login(1) , su(1M) , getty(1M) .
- LOG_LPR The line printer spooling system: lpr(1B) , lpc(1B) .
- LOG_NEWS Reserved for the USENET network news system.
- LOG_CRON The cron/at facility; crontab(1) , at(1) , cron(1M) .
- LOG_LOCAL0 -- LOG_LOCAL7 Reserved for local use.
Syslog, the system logger, is a daemon that accepts log messages from programs and writes them to the appropriate log file. Some programs such as Apache and MySQL write their log files directly, while other programs such as sendmail and the ftp and telnet daemons write them indirectly through syslog.
There are two keys to understanding syslog. First, the syslog daemon does not generate the log messages, it merely sorts them into files. The log messages are generated by all of the other servers and daemons, and not every program even uses syslog. Second, the messages that are processed through syslog are all tagged with a facility and priority, where the facility describes the subsystem that generated the message. Syslog uses the facility and priority to decide what to do with the message. These are their possible values.
Facility: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, syslog, user, uucp, local0, ..., local7.
Priority (high to low): emerg, alert, crit, err, warning, notice, info, debug.
Note that these are the only legal values, you can't make up new ones like http for the Apache web server. And now we can see which programs are likely to use syslog. Old programs that have a facility defined for them will probably use syslog. Newer programs that don't have an obvious facility will bypass syslog and write their log files directly.
Syslog.conf Syslog uses the file /etc/syslog.conf to decide where to write the messages it receives. In its simplest form, each line contains a facility and priority separated by dot and then a file name. This applies to the given priority and anything higher. You can also use multiple facility.priority pairs separated by semicolon, an asterisk to mean any facility or priority and the special priority none. Messages are written to every file on a matching line. So, depending on your rules, a message may go to multiple files or none at all. For example:
# Logs mail facility at priority info or higher. mail.info /var/log/maillog # Logs both auth and authpriv facilities. auth.info;authpriv.info /var/log/secure # Logs news facility at any priority. news.* /var/log/news # Logs any facility at priority crit or higher. *.crit /var/log/critical # Logs all facilities except mail and news. *.info;mail.none;news.none /var/log/messages # Displays all messages on virtual terminal 12. *.* /dev/tty12After editing the syslog.conf file, you must stop and restart the syslog daemon for the changes to take effect. Early versions of syslog required tabs between facility.priority and the file name, but now most versions allow spaces or tabs.
Logger You can manually send messages to the syslog daemon with the logger(1) program. This is useful for testing your config file and for shell scripts. The logger program reads the message either from the command line or from standard input. For example:
logger -p news.warning "This is a news.warning message."Config Tips Normally, the default syslog.conf file is fine for the home user and does not need to be changed. But suppose you're having trouble with some server that uses syslog. In that case, you may wish to increase its log level. And remember that it's the server that generates the log messages, so refer to the server's documentation for how to make it generate more or fewer log entries.
Security Syslog is a network daemon and reads its input on UDP port 514. If you want to prevent other machines from writing messages into your log files, then you should block that port in your firewall rules. Also, some messages contain sensitive security information, especially the auth and authpriv facilities. So, be careful what permissions you put on those files.
See Also The man pages for syslogd(8), syslog.conf(5) and logger(1). There is an excellent chapter in the Unix System Administration Handbook.
|
|
|
Checking Event Logging on System Failure - daily>Duix system log files are produced by the daemons syslogd and binlogd that are automatically started by init at system startup. The error log daemons monitor system activity and produce a set of log files stored in /var/adm/ subdiretories, therefore the /var/adm/ file system must be mounted otherwise syslogd will produce invalid information. When syslogd starts, it creates /var/run/syslog.pid to store its own PID thus allowing to stop syslogd safely at shutdown in normal operation or on request in case of troubles.
In case of system problems like system failure, hang or crash or device errors either when the system is running or during reboot, perform the following error checks to isolate problems.
- check message file /var/adm/messages that stores all system logs in ASCII text format
- check directory /var/adm/syslog.dated/ that stores the last 6 or 7 days information in directories that have date and time names like 01-Sep-08:45 . The current directory is pointed by the link current
Each directory stores a set of .log ASCII text files with system activity log, as described in the following table.
dated log files auth.log ssh activity log daemon.log daemon connection activity log kern.log kernel activity log lpr.log printer activity log mail.log tftp activity log syslog.log syslog status log user.log user activity log - run uerf -R | more to check error log. uerf displays log information on system activity in reverse chronological order in a format similar to the output produced by the VMS analyze utility
- run last | more to check all user logins in reverse chronological order
To run syslogd manually use the following syntax:
# /usr/sbin/syslogd [-d] [-fconfig_file] [-mmark_interval]
# /usr/sbin/binlogd [-d] [-fconfig_file]Stop syslogd and binlogd using the following commands:
# kill `cat /var/run/syslog.pid`
# kill `cat /var/run/binlogd.pid`Changes made to the /etc/syslog.conf and/or /etc/binlog.conf configuration files are applied without reboot using the following commands:
# kill -HUP `cat /var/run/syslog.pid`
# kill -HUP `cat /var/run/binlogd.pid`
|
|
|
In today's article, I'd like to tie together some of the concepts we've learned so far from the previous articles in the series. Let's apply our newfound skills to see what we can find out about FreeBSD and system logs.
You know there are logs on your FreeBSD system somewhere; you've probably also heard that it is a good thing to read these logs on a regular basis. You may have even heard horror stories about logs filling up a user's hard drive. So how do we go about finding these mysterious logs? Let's start by taking a look at the layout of our FreeBSD system using the trusty old command:
man hier
Need some help viewing manpages?
We'll then search for the word "log" within this manpage by typing:
/logOur first hit shows that the multi-purpose logs live in /var:
/var/ multi-purpose log, temporary, transient, and spool files
If you repeat the search by repeating the "n" key twice, you'll see that there are 2 subdirectories of /var that contain logs: cron and log.
cron/ log cron log files; see cron(8) log/ misc. system log filesIf you repeat the search one more time by pressing the "n" key, you'll get a "Pattern not found" message, so it looks like we've found all the logs that came with our directory structure.
We're interested in the system log files, so let's take a look at the contents of /var/log:
ls /var/logcron messages setuid.today dmesg.today ppp.logs setuid.yesterday dmesg.yesterday security slip.log lpd-errs sendmail.st wtmp maillog sendmail.st.0
For more on permissions, see:
Your output may vary slightly depending upon your version of FreeBSD, which ports you have installed on your FreeBSD system, and how long it's been since you've been in this directory. Being the curious type, you'll probably want to have a peek at each log to see what it contains. But before you start looking at files you didn't create, you'll want to first check that you have permission to view their contents by typing:
ls -ltotal 324 drwxr-xr-x 3 root wheel 1024 Nov 5 00:00 ./ drwxr-xr-x 18 root wheel 512 Sep 26 10:53 ../ -rw------- 1 root wheel 81964 Nov 5 09:15 cron -rw-r----- 1 root wheel 3435 Nov 3 02:06 dmesg.today -rw-r----- 1 root wheel 3382 Nov 2 02:06 dmesg.yesterday -rw-rw-r-- 1 root wheel 0 Jul 28 09:10 lpd-errs -rw-rw-r-- 1 root wheel 16821 Nov 5 08:41 maillog -rw-rw-r-- 1 root wheel 78888 Nov 5 08:40 messages -rw------- 1 root wheel 80332 Oct 30 14:17 ppp.log -rw------- 1 root wheel 0 Jul 28 09:10 security -rw-rw-r-- 1 root wheel 616 Nov 5 08:41 sendmail.st -rw-rw-r-- 1 root wheel 616 Nov 4 19:33 sendmail.st.0 -rw-r----- 1 root wheel 7791 Nov 3 02:06 setuid.today -rw-r----- 1 root wheel 6587 Nov 2 02:06 setuid.yesterday -rw------- 1 root wheel 0 Jul 28 09:10 slip.log -rw-r--r-- 1 root wheel 2684 Nov 2 21:12 wtmpIt looks like a regular user only has permission to view about half of the log files. If that user lives in the wheel group, they can view a few more, but only the superuser can view all of the system log files.
One last thing before looking at these files: You did not make these files, so you don't know what type of data they contain. Remember, you never open up an unknown file without first testing it with the file utility. Let's check the whole directory at once:
file *cron: ASCII text dmesg.today: English text dmesg.yesterday: English text lpd-errs: empty maillog: ASCII text messages: English text ppp.log: mail text security: empty sendmail.st: data sendmail.st.0: data setuid.today: ASCII text setuid.yesterday: ASCII text slip.log: empty wtmp: dataAny file that has a type called data is usually non-printable. This means that you shouldn't try to send the sendmail* or wtmp files to your terminal using the more or cat commands or your favorite editor. It looks like the lpd-errs, security and slip.log files are empty. The other files contain text, so they can be viewed by any user who has "r" permission to that file. Some of these files are quite large; if you are only concerned with the last bit, that is, the most recent part of the log, use the tail command like so:
tail maillogThis will display the last 10 lines of the maillog file; you'll note that maillog has very long lines that will wrap around your screen.
Now you know which log files you can safely look at and satisfy your curiosity regarding their contents. But who put that information into those log files, and how can you specify what type of information you'd like to see in your log files? Sounds like we need to use the apropos command to see which manpages will shed some light on this subject. If you type:
apropos system logyou'll receive a couple of screens full of possible manpages. Let's narrow our search a bit by adding some quotation marks:
apropos "system log"The " " tell apropos that you only want manpages that contain both words; the original search told apropos to return manpages that contained either word. This last search yielded a lot fewer results:
logger(1) - make entries in the system log
newsyslog(8) - maintain system log files to manageable sizes
syslog(3), vsyslog(3), openlog(3), closelog(3), setlogmask(3) - control system logWe seem to be getting closer; it appears that FreeBSD uses the word "syslog" instead of system logs. Let's try:
apropos syslognewsyslog(8) - maintain system log files to manageable sizes
syslog(3), vsyslog(3), openlog(3), closelog(3), setlogmask(3) - control system log
syslog.conf(5) - syslogd 8 configuration file
syslogd(8) - log systems messages
Sys::Syslog(3), openlog(3), closelog(3), setlogmask(3), syslog(3) - Perl interface to the UNIX syslog|(3) callsAnd we've hit paydirt; syslogd is the daemon responsible for logging system messages, and syslog.conf is its configuration file.
So, do you have permission to muck about with this syslog.conf file? To find out, type:
ls -l /etc/syslog.conf-rw-r--r-- 1 root wheel 903 Jul 28 09:10 /etc/syslog.confLooks like anyone can read it, but only the superuser will be able to modify it. Let's just take a peek at it as a regular user using the more command:
more /etc/syslog.confView the results from this command here.
Some parts of this file are self-explanatory, but we'll have to take this file's advice and read the syslog.conf(5) manpage before we start making any changes to it. I'll cover the highlights; you'll have to do a man 5 syslog.conf to get all the details.
Each line in syslog.conf has two fields: the selector field (on the left), which specifies the type of message, and an action field (on the right), which specifies the action to be taken if a message matches the selection criteria. The selector field is separated from the action field by one or more tabs.
The selector field itself is divided into two parts separated by a period, like this:
facility.levelwhere facility is what generated the message and level is the severity of the message. The possible values for facilities and levels are explained in syslog(3). The following tables provide a summary of the facilities and levels:
Table 1: Facilities
Facility Name
What Program It Represents
AUTH
The authorization system: login(1), su(1), getty(8), etc.
AUTHPRIV
The same as AUTH, but logged to a file readable only by selected individuals.
CRON
The cron daemon: cron(8).
DAEMON
System daemons, such as routed(8), that are not provided for explicitly by other facilities.
FTP
The file transfer protocol daemons: ftpd(8), tftpd(8).
KERN
Messages generated by the kernel. These cannot be generated by any user processes.
LPR
The line printer spooling system: lpr(1), lpc(8), lpd(8), etc.
The mail system.
NEWS
The network news system.
SECURITY
Security subsystems.
SYSLOG
Messages generated internally by syslogd(8).
USER
Messages generated by random user processes. This is the default facility identifier if none is specified.
UUCP
The uucp system. ipfw(4).
*
Specifies all facilities or programs except mark.
MARK
A special facility used by syslogd.
Table 2: Levels
Level Name
What It Represents
EMERG
A panic condition. This is normally broadcast to all users.
ALERT
A condition that should be corrected immediately, such as a corrupted system database.
CRIT
Critical conditions, e.g., hard device errors.
ERR
Errors.
WARNING
Warning messages.
NOTICE
Conditions that are not error conditions, but should possibly be handled specially.
INFO
Informational messages.
DEBUG
Messages that contain information normally of use only when debugging a program.
NONE
Special level to disable the facility.
Let's use these tables to decipher what type of messages are sent to the console, that is, those irritating bold-white messages that show up on your first terminal. The corresponding line in /etc/syslog.conf reads as:
*.err;kern.debug;auth.notice;mail.crit /dev/consoleNote that the selector field is a bunch of "facility.levels" tied together with semicolons. Reading from left to right, this line tells syslogd to send the following types of messages to the console:
- error messages from all programs
- debug messages generated by the kernel
- notices regarding logins and su's
- critical mail conditions
You should be able to use the same logic to see what types of messages are sent to which logs in the next five lines:
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/log/cronHowever, to understand the rest of the file, we need to know the five possible actions listed in the following table:
Table 3: Actions
Syntax of Action
What It Does
/pathname
Messages are added to the end of the specified file.
@hostname
Messages are forwarded to the syslogd(8) program on the specified computer.
user1,user2,etc.
Messages are written to those users if they are logged in.
*
Messages are written to all logged-in users.
|command
Pipes the message to the specified command.
Also note that two of the lines in the file begin with an exclamation mark and don't have an action field after them like so:
!startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.logOccasionally you'll want to log the messages of a program that isn't covered by one of the built-in facilities. To add this program to /etc/syslog.conf, type the name of the program's executable on a line by itself with a ! in front of the name. On the next line, input the selector and action fields as you normally would.
You'll find that man 5 syslog.conf has excellent examples covering just about every scenario you'll ever come across when configuring logging. If you do ever edit your syslog.conf file, you will have to send a HUP signal to syslogd to force it to read the changes. To do this:
more /var/run/syslog.pidand make note of the number you receive; this is the PID (process ID) being used by the syslog daemon. Then, as the superuser:
kill -1 numberwhere number is the number you received above.
The last thing I want to cover today is the newsyslog utility. When you originally looked in your /var/log directory, you may have received a listing of a lot of files that ended in .0, .1, etc., and some of these files may have also been compressed (they had a .gz extension). This is a result of the workings of newsyslog, which we mentioned briefly in the Getting Cron to Do Our Bidding article. Let's take a quick look in this utility's manpage:
man newsyslogNAME
newsyslog - maintain system log files to manageable sizes
Newsyslog is a program that should be scheduled to run periodically by cron(8). When it is executed it archives log files if necessary. If a log file is determined to require archiving, newsyslog rearranges the files so that "logfile" is empty, "logfile.0" has the last period's logs in it, "logfile.1" has the next to last period's logs in it, and so on, up to a user-specified number of archived logs. Optionally, the archived logs can be compressed to save space.
In other words, if a logfile becomes too large, newsyslog will rename it with a .0 extension, possibly zip it, and create a new file with the original log name. For example:
- maillog.1.gz is the oldest maillog file; it has been compressed
- maillog.0.gz is the second oldest maillog file; it is also compressed
- maillog is the current maillog that is being written to by syslogd
If you continue to read through the manpage for newsyslog, you'll learn how to tweak its configuration file (/etc/newsyslog.conf) so you can schedule when files will be renamed and compressed.
If you ever need to view the contents of a log that has already been compressed by newsyslog, you can use the zmore utility like so:
zmore maillog.0.gzIf you need to remove old log files to save space, it is safe to delete a log that ends with a either a number or a .gz from the /var/log directory. If you need to do this often, there is no need to create a cronjob; newsyslog will do this automatically. It will keep as many or as few backlogs as you desire and rotate through them when they reach a specified size. I would not recommend deleting the other logs, though, as syslogd expects to be able to find the logfiles in the paths that you've specified in /etc/syslog.conf. So, in the above example, it is safe to delete maillog.0.gz and maillog.1.gz, but don't delete maillog.
If you ever inadvertently delete an original logfile, you can create it using the touch utility:
cd /var/log rm maillog (oops) touch maillogThis will create an empty maillog file that syslogd can write to.
This should get you started working with logs on your FreeBSD system. In next week's article we'll dig a little deeper and take a look at processes, PIDs, and the ps utility.
Dru Lavigne is an instructor at Marketbridge Technologies in Ottawa and the maintainer of the Open Protocol Resource.
I started putting the data into a database for more flexible querying, using SQLSyslogd, written by Przemyslaw Frasunek, available at: http://www.frasunek.com/sources/security/sqlsyslogd/.
I like having SQL at my disposal when I need very specific information from my logs.
You can pipe to sqlsyslogd with a line like this:
destination sqlsyslogd { program("/usr/local/sbin/sqlsyslogd -u sqlsyslogd -t logs sqlsyslogd -p"); }; log { source(src); destination(sqlsyslogd); };"src" in this case is all the incoming messages, there's no filtering of messages. You still need to setup your database according to the instructions for sqlsyslogd. Read the docs that come with it.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
