Log files

• Unix keeps lots of logs
  • syslog
  • license servers
  • httpd (web server)
  • ftp
  • mail
  • etc.
• Log files grow without bounds
• Eventually, you'll run out of disk space
• What to do?
  • Don't log the data in the first place
  • Reset log files when they get too big
  • Rotate log files
  • Archive log files

• Don't log the data
  • Either tell programs not to log anything, or to log to /dev/null
  • Pro
    • Easy
    • Uses no disk space
  • Con
    • You lose troubleshooting data
    • You lose evidence in case of break-ins
• Reset log files when they get too big
  • Wait until it's a problem, then reset the file to zero
  • Pro
    • Not much harder than no logging
    • You do have data for troubleshooting or documenting break-ins (maybe)
  • Con
    • What if you reset the log file, then discover a problem?
      • You have no data to look at
    • Uses varying disk space, from very little, to way too much
    • Run the risk of filling disks and affecting system operation
      • Might not be able to receive mail, for example
• Rotate log files
  • At regular intervals (daily, weekly, etc.), make a copy of the log file, then reset the original
  • Keep a known number of copies around
  • Pro
    • Uses a fairly constant amount of disk space
    • Can compress saved log files
      • But if you don't compress them, they'll be easier to search if you need to
    • Can be automated with a script and scheduled with cron
      • A simple such script is given on page 205
  • Con
    • Requires some up-front effort to set up cron jobs to make it all work
      • Some versions of Unix do include this functionality, including Tru64 Unix and Redhat Linux.
        • The book has nice things to say about how Redhat handles logging, and I agree that "out of the box," Redhat has the best logging setup.
      • Some programs require special treatment for their log files, so your script may need to send signals or do something else that's special
• Archive log files
  • Might be required by procedures at your organization
  • Pro
    • Complete records are available, with varying amounts of work
  • Con
    • Most labor-intensive option
    • Some accounting needed to keep track of archival data
    • Might expose you to some legal liabilities (Freedom of Information Act, "civil discovery", etc.)

• Short answer: all over the place, under varying names
  • Usually in /var/log, /var/adm or /usr/adm
  • Check startup scripts, config files for programs, syslog config file (discussed below)
  • Table 11.1 on p. 208 of the textbook gives many examples
• There are some files that may be big and are often changing, but aren't log files. Don't mess with them. (Redhat Linux pathnames given here.)
  • /var/log/lastlog
    • Sparse file, indexed by UID, giving info on last login for each user
      • A very simple explanation of a sparse file is given in footnote 4 on p. 176
    • Don't copy it!
    • No need to truncate -- it's not using all the space that ls -l says it is
      • Use du -s lastlog to see how big it really is
  • /var/run/utmp
    • Current login information
    • Provides information to who, w, etc.

• Whiz-bang logging facility
• Used on just about every flavor of Unix out there
• Written by Eric Allman (who also wrote sendmail)
• syslogd receives information written with syslog() function, and stores it according to the rules in /etc/syslog.conf syslog configuration
• Each message sent to syslog is tagged with a category, called a "facility," and a severity, called a "severity level."
  • Messages can be routed based on either or both
• /etc/syslog.conf
• Basic format: selector [TAB] action
  • The tab is important. Spaces won't work.
• Selector format
  • facility.level
  • Several facilities and levels are defined
    • Check your local man pages for which ones are on your system
  • facility may be '*' (meaning "all except for 'mark'")
  • level may be 'none' (meaning, "exclude this facility from this rule")
  • To specify a wildcard leve, you must say "debug" (which is the lowest level)
    • Some newer syslogs allow "*", but don't depend on that without confirming it first
  • multiple facilities may be separated by commas
  • multiple selectors may be separated by semicolons
  • facilities include
    • kern: kernel
    • mail: the mail system
    • auth: authorization messages
    • cron: messages from cron
    • mark: timestamps
  • levels include
    • emerg: super-ultra critical
    • alert: quite urgent
    • crit: critical
    • err: errors
    • warning: warnings
    • notice: things you might want to check out
    • info: for informational purposes only
    • debug: debugging info
  • A message for a certain facility will match an entry if its facility matches and if its level is at least that given
    • In other words, the level in syslog.conf means "messages at this level or greater are to use this action"
• Action format
  • filename
    • write the message to the filename given
      • absolute path required
      • file must already exist
  • @hostname
    • send the message to syslogd on the named host
  • @i.p.address
    • send the message to syslogd on the host at address i.p.address
  • user1,user2,...
    • write the message to the screen of user1, user2,...
    • This is a message on the terminal screen, (I) !
  • *
    • write the message to all users logged in
• Several examples in the book. Read them and understand!

*.info;mail.none;authpriv.none                          /var/log/messages

authpriv.*                                              /var/log/secure

mail.*                                                  /var/log/maillog

*.emerg                                                 *

uucp,news.crit                                          /var/log/spooler

local7.*                                                /var/log/boot.log

• Both Redhat and FreeBSD provide "enhanced" versions of syslog
• Both give some more flexibility in specifying where to send messages
• Both are explained in the book, but we won't go into them here

• Small site
  • Keep logfiles on each machine
• Large network
  • Central logging host
    • Should be a secure host
    • Can keep crackers away from logging data, so they can't cover their tracks
    • Highly customized config file
  • Other hosts
    • Basic config file, sends most info to logging host

• logger command sends messages to syslogd
• syslog -d
  • Prints table showing config
  • Prints messages to the screen as messages are processed

• As we do more with our computers, and have more computers, the amount of information logged becomes overwhelming
• Looking through logfiles, you're likely to miss important messages
  • And you soon give up on looking, because all you'll ever see is "normal stuff"
• The solution is to use some sort of filter on your logfiles
• The book discusses two
  • swatch
    • Allows you to define Perl regular expressions and actions to take if swatch sees them
  • logcheck
    • Comes with pre-defined patterns for various architectures, much easier to set up
• If you can manage it, a good scheme is to throw out all "normal" lines and report the rest
  • When you first start doing it, you may find yourself fixing problems you didn't know you had
  • This is a good thing!