Тaking control

Log files

Various components of FreeBSD report problems or items of interest as they happen. For example, there can always be problems with mail delivery, so a mail server should keep some kind of record of what it has been doing. If hardware problems occur, the kernel should report them. If somebody tries to break into the machine, the components affected should report the fact.

FreeBSD has a generalized system for logging such events. The syslogd daemon takes messages from multiple sources and writes them to multiple destinations, usually log files in the directory /var/log. You can change this behavior by modifying the file /etc/syslog.conf. See syslog.conf(5) for further details. In addition to syslogd, other programs write directly to files in this directory. The following files are of interest:

• XFree86.0.log contains the log file for the last (or current) X session started on display 0. This is a prime source of information if you run into problems with X.
• auth.log contains information about user authentication. For example, you might see:

  Dec 10 10:55:11 bumble su: grog to root on /dev/ttyp0
  Dec 10 12:00:19 bumble sshd[126]: Server listening on :: port 22.
  Dec 10 12:00:19 bumble sshd[126]: Server listening on 0.0.0.0 port 22. 
  Dec 10 12:06:52 bumble sshd[167]: Accepted publickey for grog 
    from 223.147.37.80 port 49564 ssh2
  Dec 10 12:06:58 bumble su: BAD SU grog to root on /dev/ttyp0
  

  The first line is a successful su invocation; the last line is an unsuccessful one (because the password was mistyped). The messages at 12:00:19 are from sshd startup, and the message at 12:06:52 is a successful remote login with ssh.
• cron is a log file for cron. It's relatively uninteresting:

  Jan  5 16:00:00 bumble newsyslog[2668]: logfile turned over
  Jan  5 16:05:00 bumble /usr/sbin/cron[2677]:  (root) CMD (/usr/libexec/atrun)
  Jan  5 16:05:00 bumble /usr/sbin/cron[2678]:  (root) CMD (/usr/libexec/atrun)
  Jan  5 16:10:00 bumble /usr/sbin/cron[2683]:  (root) CMD (/usr/libexec/atrun)
  

  If you have problems with cron, that could change rapidly.
• dmesg.today and dmesg.yesterday are created by a cron job at 2 am every day. The dmesg message buffer wraps around, overwriting older entries, so they can be of use.
• Lastlog is binary file recording last login information. You don't normally accesses it directly.
• Maillog contains information about mail delivery.
• message is the main log file.
• The files mount.today and mount.yesterday show the currently mounted file systems in the format needed for /etc/fstab.
• The file ppp.log contains information on PPP connections. We look at it on page 353.
• The files setuid.today and setuid.yesterday contain a list of setuid files. The daily security check compares them and sends a mail message if there are any differences.
• The file vinumhistory contains information about vinum activity.
• The file wtmp contains information about logins to the system. Like lastlog, it's in binary form. See utmp (5) for the format of both last log and wtmp.

A number of the more important log files are kept through several cycles. As the example above shows, cron runs the newsyslog command every hour new syslog checks the size of the files, and if they are larger than a certain size, it renames the old ones by giving them a numerical extension one higher than the current one, then renames the base file with an extension .0 and compresses it. The result looks like this:

-rw-r--r--  1  root  wheel  31773  Jan   5  13:01 messages
-rw-r--r--  1  root  wheel   8014  Jan   2  01:00 messages.0.bz2
-rw-r--r--  1  root  wheel  10087  Dec  15  14:00 messages.1.bz2
-rw-r--r--  1  root  wheel   9940  Dec   3  17:00 messages.2.bz2
-rw-r--r--  1  root  wheel   9886  Nov  16  11:00 messages.3.bz2
-rw-r--r--  1  root  wheel   9106  Nov   5  18:00 messages.4.bz2
-rw-r--r--  1  root  wheel   9545  Oct  15  17:00 messages.5.bz2

newsyslog has a configuration file /etc/newsyslog.conf, which we discuss on page 572.

Multiple processor support

FreeBSD Release 5 can support most current Intel and AMD multiprocessor motherboards with the ia32 architecture. It also supports some Alpha, SPARC64 and Intel ia64 motherboards. Documentation on SMP support is currently rather scanty, but you can find some information at http://www.freebsd.org/~fsmp/SMP/SMP.html.

The GENERIC kernel does not support SMP, so you must build a new kernel before you can use more than one processor. The configuration file /usr/src/sys/i386/conf/GENERIC contain the following commented-out entries:

# To make an SMP kernel, the next two are needed
#options  SMP          #Symmetric Multiprocessor Kernel
#options  APIC_IO      #Symmetric (APIC) I/O

For other platforms, you don't need APIC_IO. See "Custom kernels" for information on how to build a new kernel.

PC Card devices

As we have already seen, PC Card devices are special because they can be hot-plugged. They are also intended to be recognized automatically. Starting with Release 5, FreeBSD recognizes card insertion and removal in the kernel and invokes the appropriate driver to handle the event. When you insert a card you will see something like this on the system console:

ata2 at port 0x140-0x14f irq 11 function 0 config 1 on pccard0
ad4: 7MB <LEXAR ATA FLASH>  [251/2/32]  at ata2-master BIOSPIO

This is a compact fash memory card, which the system sees as an ATA disk. The kernel has created the necessary structures, but it can't know how to mount the device, for example. We'll look at what we can do about this in the next section.

devd: The device daemon

The device daemon, devd, provides a way to run user land programs when certain kernel events happen. It is intended to handle userland configuration of PC Card devices such as Ethernet cards, which it can do automatically. We'll look at this automatic usage on page 304.

devd reads the kernel event information from the device /dev/devctl and processes it according to rules specified in the configuration file /etc/devd.conf, which is installed with the system. If you want to use it for other devices, you must modify /etc/devd.conf. This file contains a number of sections, referred to as statements in the man page:

• The options statement describes file paths and a number of regular expressions (patterns) to look for in the messages it reads from /dev/devctl.
• attach statements specify what action to perform when a device is attached. For example:

  attach 0 {
    device-name "$scsi-controller-regex";
    action "camcontrol rescan all";
  };
  

  The device-name entry uses the regular expression $scsi-controller-regex to recognize the name of a SCSI controller in the attach message. The action entry then specifies what action to take when such a device is attached to the system. In this case, it runs the camcontrol program to rescan the SCSI buses and recognize any new devices that have been added.

  Multiple attach statements can match a specific event, but only one will be executed. The order in which they are checked is specified by a priority, a numerical value after the keyword action. The statements are checked in order of highest to lowest numerical priority.
• detach statements have the same syntax as attach statements. As the name suggests, they are executed when a device is detached.

  It's not always possible or necessary to perform any actions when a device is removed. In the case of SCSI cards, there is nodetach statement. We'll look at this issue in more detail below.
• Finally, if the kernel was unable to locate a driver for the card, it generates a no match event, which is handled by the nomatch statement.

So what does devd do when we insert the compact flash card? By default, nothing. The ATA driver recognizes and configures the card. It would be nice to get devd to mount it as well. That's relatively simple:

• Ensure that you have an entry for the device in /etc/fstab. Digital cameras create a single MS-DOS file system on fash cards. An appropriate entry in /etc/fstab for this device might be:

  /dev/ad4s1   /camera   msdos     rw,noauto   0 0
  

  This is a removable device, so you should use the noauto keyword to stop the system trying to mount it on system startup.
• In the options section of /etc/devd.conf add an expression to recognize the names of ATA controllers:

  set ata-controller-regex
      "ata[0-9]+";
  
• Add an attach section for the device:

  attach 0 {
    device-name "$ata-controller-regex";
    action "mount /camera";
  };
  
• Restart devd:

  # killall devd
  # devd
  

After this, the file system will be automatically mounted when you insert the card.