Mark W. Krentel
Part of the SyrLUG meetings is a section called the SysConfig Corner. This is a brief (10-15 minute) presentation on configuring some aspect of a Linux system, designed mainly for the home user and usually involving a file in /etc. These notes are a summary of those presentations. And although the notes are written mainly for Linux and sometimes Red Hat, most of the topics apply to all Unix and Linux systems. But there are differences between systems, so be sure to check your local man pages.
For more information, start with the suggested man pages. The notation "logrotate(8)" means that there is a man page for logrotate in section 8 and suggests that you read it with "man 8 logrotate". Section 1 is for user commands, section 8 is for system administrator commands and section 5 is for file formats. See man(7) for the complete list. Some of the topics are covered in the Linux Howtos, although sadly, most are not. The Unix System Administration Handbook (Prentice Hall) by Nemeth, Snyder, Seebass and Hein and its Linux version, the Linux Administration Handbook, are excellent books and cover most of these topics.
Note: Neither the presentations nor these notes are intended to be a full treatment of their subject. They merely introduce some topic, give a few examples of common usage and indicate where to look for further information.
Logrotate is the standard Linux program to rotate log files. Since the log files grow continuously, the usual solution is to keep some number of backup copies and rotate them at regular intervals. For example, for /var/log/messages, suppose you keep three backup copies, messages.0, messages.1 and messages.2. Then, at regular intervals, logrotate deletes messages.2, moves messages.1 to messages.2, moves messages.0 to messages.1, moves messages to messages.0 and creates a new messages file.
Logrotate.conf Logrotate is usually run as a daily cron job, either from a script in /etc/cron.daily or directly from /etc/crontab. It uses a config file, commonly /etc/logrotate.conf, and a state file, commonly /var/lib/logrotate.status, although these path names can be changed on the command line. In addition, logrotate.conf usually contains an include option for a directory such as /etc/logrotate.d which tells logrotate to read and include every file in that directory.
The first part of /etc/logrotate.conf contains global options. The two main things to decide are how often to rotate the files and how many backup copies to keep. There are many other options (see man logrotate), but here are some that I find useful.
# Global options for logrotate.conf.
# Can rotate files daily, weekly or monthly.
monthly
# Number of backup copies.
rotate 10
# Don't compress backup copies.
nocompress
# Don't rotate zero-byte files.
notifempty
# Sets the mode, owner and group of the new file.
create 0640 root root
# Includes every file in this directory.
include /etc/logrotate.d
After the global options, list the files that you want rotated followed by curly braces after each file. Inside the braces, you can add options that apply to that file only. Note that you must list every file that you want rotated, even if it doesn't have any special options. For example:
# Files to rotate, can override global options here.
/var/log/cron {
weekly
rotate 5
}
/var/log/secure {
create 0600 root root
}
/var/log/xferlog {
}
Open File Descriptors There is one very important complication here. Many system daemons such as Apache and syslog open their log files and hold them open throughout the lifetime of the program. Not all programs do this, but for the ones that do, you can't just rotate their log files out from under them without informing the program. One solution is to stop the program before rotation and restart it immediately afterward. Logrotate uses the prerotate and postrotate options for this. For example:
# Stop Apache before rotation and restart afterward.
/var/log/httpd/access_log {
prerotate
/etc/rc.d/init.d/httpd stop
endscript
postrotate
/etc/rc.d/init.d/httpd start
endscript
}
Although the above solution will work, it is somewhat heavy-handed. A better solution, if the program allows it, is to leave the program running and inform it later that its files have been rotated. Many daemons use a signal for this. For example, a HUP signal tells syslogd to close and reopen its log files without actually killing it.
# HUP tells syslogd to close and reopen its files.
/var/log/messages {
postrotate
kill -HUP `cat /var/run/syslogd.pid`
endscript
}
Config Tips The default logrotate.conf normally has sufficient entries for the system log files, but you may wish to change the frequency of rotation, number of backups, file permissions, etc. When you install a new program that writes a log file, check that it also has an entry. And read its documentation to see if it keeps an open file descriptor on that file and add a postrotate script as needed.
Logrotate can only rotate files daily, weekly or monthly (or by size). In practice, this is not a serious limitation, but if you want to rotate a file on a different schedule, there is a simple workaround. Write a separate config file for this file only and run logrotate directly from cron with the -f option (force rotation). This gives you the full granularity of cron.
See Also The man page for logrotate(8).
Sysctl, system control, provides a way to get and set parameters from a running kernel. All versions of Unix use sysctls, but the parameters are tied directly into the kernel, so they are very system dependent. In Linux, the distribution does not matter, only the kernel.
Here are some examples of reading and writing values with sysctl. The parameters are arranged hierarchically with dot as the separator. The -a option prints all parameters, -w is used to write a value and there must be no spaces surrounding the equal sign. You must be root to write a value.
# Prints the OS type, "Linux" in this case.
sysctl kernel.ostype
# Turns on packet forwarding, used on gateways.
sysctl -w net.ipv4.ip_forward=1
# Sets the machine's hostname, the quotes are optional.
sysctl -w kernel.hostname="foo.bar.com"
# Prints a list of all parameters and their values.
sysctl -a
Proc File System In Linux, sysctl is handled through the /proc file system. For every sysctl, there is a file below /proc/sys with dot replaced by slash. Reading and writing these files is exactly equivalent to using sysctl. So, the previous examples can also be done by the following.
cat /proc/sys/kernel/ostype
echo 1 >/proc/sys/net/ipv4/ip_forward
echo "foo.bar.com" >/proc/sys/kernel/hostname
ls -R /proc/sys
Sysctl.conf To have sysctls run automatically at boot time, put them in the file /etc/sysctl.conf. In this file, spaces around the equal sign are optional and you should avoid quotes (because the quoting rules are not the same as in the shell). For example:
net.ipv4.ip_forward = 1
kernel.hostname = foo.bar.com
Config Tips In practice, there are almost no sysctls that need to be changed from the defaults. Net.ipv4.ip_forward should be turned on (set to 1) only on a gateway/firewall that forwards packets and turned off (set to 0) on other machines. And although kernel.hostname will set the machine's hostname, the sysctl is the wrong way to do that. Instead, use the /etc/sysconfig scripts or the hostname(1) command.
See Also The man pages for sysctl(8) and sysctl.conf(5). Some of the sysctls are described in the Documentation/sysctl subdirectory of the kernel source. The networking sysctls are described in Documentation/networking/ip-sysctl.txt. Look in /usr/src/linux/Documentation or in /usr/share/doc/kernel-doc-2.4.xx for the kernel docs.
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/tty12
After 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.