Chapter 8 System Administration

From 2.0.5R to 2.2.1R, the primary configuration file is /etc/sysconfig. All the options are to be specified in this file and other files such as /etc/rc (see rc(8)) and /etc/netstart just include it.

Look in the /etc/sysconfig file and change the value to match your system. This file is filled with comments to show what to put in there.

In post-2.2.1 and 3.0, /etc/sysconfig was renamed to a more self-describing rc.conf(5) file and the syntax cleaned up a bit in the process. /etc/netstart was also renamed to /etc/rc.network so that all files could be copied with a cp /usr/src/etc/rc* /etc command.

And, in 3.1 and later, /etc/rc.conf has been moved to /etc/defaults/rc.conf. Do not edit this file! Instead, if there is any entry in /etc/defaults/rc.conf that you want to change, you should copy the line into /etc/rc.conf and change it there.

For example, if you wish to start named, the DNS server included with FreeBSD in FreeBSD 3.1 or later, all you need to do is:

    # echo named_enable="YES" >> /etc/rc.conf

To start up local services in FreeBSD 3.1 or later, place shell scripts in the /usr/local/etc/rc.d directory. These shell scripts should be set executable, and end with a .sh. In FreeBSD 3.0 and earlier releases, you should edit the /etc/rc.local file.

The /etc/rc.serial is for serial port initialization (e.g. locking the port characteristics, and so on.).

The /etc/rc.i386 is for Intel-specifics settings, such as iBCS2 emulation or the PC system console configuration.

Use the adduser(8) command. For more complicated usage, the pw(8) command.

To remove the user again, use the rmuser(8) command. Once again, pw(8) will work as well.

See the Disk Formatting Tutorial at www.FreeBSD.org.

Whether it is a removable drive like a ZIP or an EZ drive (or even a floppy, if you want to use it that way), or a new hard disk, once it is installed and recognized by the system, and you have your cartridge/floppy/whatever slotted in, things are pretty much the same for all devices.

(this section is based on Mark Mayo's ZIP FAQ)

If it is a ZIP drive or a floppy , you have already got a DOS filesystem on it, you can use a command like this:

    # mount -t msdos /dev/fd0c /floppy

if it is a floppy, or this:

    # mount -t msdos /dev/da2s4 /zip

for a ZIP disk with the factory configuration.

For other disks, see how they are laid out using fdisk(8) or sysinstall(8).

The rest of the examples will be for a ZIP drive on da2, the third SCSI disk.

Unless it is a floppy, or a removable you plan on sharing with other people, it is probably a better idea to stick a BSD file system on it. You will get long filename support, at least a 2X improvement in performance, and a lot more stability. First, you need to redo the DOS-level partitions/filesystems. You can either use fdisk(8) or /stand/sysinstall, or for a small drive that you do not want to bother with multiple operating system support on, just blow away the whole FAT partition table (slices) and just use the BSD partitioning:

    # dd if=/dev/zero of=/dev/rda2 count=2
    # disklabel -Brw da2 auto

You can use disklabel or /stand/sysinstall to create multiple BSD partitions. You will certainly want to do this if you are adding swap space on a fixed disk, but it is probably irrelevant on a removable drive like a ZIP.

Finally, create a new file system, this one is on our ZIP drive using the whole disk:

    # newfs /dev/rda2c

and mount it:

    # mount /dev/da2c /zip

and it is probably a good idea to add a line like this to /etc/fstab (see fstab(5)) so you can just type mount /zip in the future:

    /dev/da2c /zip ffs rw,noauto 0 0

This is normally caused by editing the system crontab (/etc/crontab) and then using crontab(1) to install it:

    # crontab /etc/crontab

This is not the correct way to do things. The system crontab has a different format to the per-user crontabs which crontab(1) updates (the crontab(5) manual page explains the differences in more detail).

If this is what you did, the extra crontab is simply a copy of /etc/crontab in the wrong format it. Delete it with the command:

    # crontab -r

Next time, when you edit /etc/crontab, you should not do anything to inform cron(8) of the changes, since it will notice them automatically.

If you want something to be run once per day, week, or month, it is probably better to add shell scripts /usr/local/etc/periodic, and let the periodic(8) command run from the system cron schedule it with the other periodic system tasks.

The actual reason for the error is that the system crontab has an extra field, specifying which user to run the command as. In the default system crontab provided with FreeBSD, this is root for all entries. When this crontab is used as the root user's crontab (which is not the same as the system crontab), cron(8) assumes the string root is the first word of the command to execute, but no such command exists.

This is a security feature. In order to su to root (or any other account with superuser privileges), you must be in the wheel group. If this feature were not there, anybody with an account on a system who also found out root's password would be able to gain superuser level access to the system. With this feature, this is not strictly true; su(1) will prevent them from even trying to enter the password if they are not in wheel.

To allow someone to su to root, simply put them in the wheel group.

When you get the prompt to enter the shell pathname, simply press ENTER, and run mount / to re-mount the root filesystem in read/write mode. You may also need to run mount -a -t ufs to mount the filesystem where your favourite editor is defined. If your favourite editor is on a network filesystem, you will need to either configure the network manually before you can mount network filesystems, or use an editor which resides on a local filesystem, such as ed(1).

If you intend to use a full screen editor such as vi(1) or emacs(1), you may also need to run export TERM=cons25 so that these editors can load the correct data from the termcap(5) database.

Once you have performed these steps, you can edit /etc/rc.conf as you usually would to fix the syntax error. The error message displayed immediately after the kernel boot messages should tell you the number of the line in the file which is at fault.

The secondary DOS partitions are found after ALL the primary partitions. For example, if you have an ``E'' partition as the second DOS partition on the second SCSI drive, you need to create the special files for ``slice 5'' in /dev, then mount /dev/da1s5:

    # cd /dev
    # sh MAKEDEV da1s5
    # mount -t msdos /dev/da1s5 /dos/e

Digital UNIX

UFS CDROMs can be mounted directly on FreeBSD. Mounting disk partitions from Digital UNIX and other systems that support UFS may be more complex, depending on the details of the disk partitioning for the operating system in question.

Linux

As of 2.2, FreeBSD supports ext2fs partitions. See mount_ext2fs(8) for more information.

NT

A read-only NTFS driver exists for FreeBSD. For more information, see this tutorial by Mark Ovens at http://ukug.uk.FreeBSD.org/~mark/ntfs_install.html.

Any other information on this subject would be appreciated.

If you want to make a bit-by-bit copy of a CD (so you can, for example, duplicate it with a CD burner), use dd(1). The example given here assumes that you have a IDE CDROM device that shows up as acd0. If you have a SCSI CD or different type of drive, you will want to substitute the correct device name. A c must be appended to the end of the device name, indicating the entire partition, or in the case of CDROMs, the entire disc.

    # dd if=/dev/acd0c of=file.iso bs=2048

The file generated will be a standard ISO file, which can be used with cdrecord, burncd, or any other program supporting this standard CD data format. This method does not work with audio CDs.

For more on working with CDROMs, see the Creating CDs Section in the Storage chapter in the Handbook.

This procedure is slightly different for 2.2.x and 3.x (with the 3-stage boot) systems.

The general idea is that you copy the first sector of your native root FreeBSD partition into a file in the DOS/NT partition. Assuming you name that file something like c:\bootsect.bsd (inspired by c:\bootsect.dos), you can then edit the c:\boot.ini file to come up with something like this:

    [boot loader]
    timeout=30
    default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
    [operating systems]
    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT"
    C:\BOOTSECT.BSD="FreeBSD"
    C:\="DOS"

For 2.2.x systems this procedure assumes that DOS, NT, FreeBSD, or whatever have been installed into their respective fdisk partitions on the same disk. This example was tested on a system where DOS & NT were on the first fdisk partition, and FreeBSD on the second. FreeBSD was also set up to boot from its native partition, not the disk's MBR.

Mount a DOS-formatted floppy (if you have converted to NTFS) or the FAT partition, under, say, /mnt.

    # dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1

Reboot into DOS or NT. NTFS users copy the bootsect.bsd and/or the bootsect.lnx file from the floppy to C:\. Modify the attributes (permissions) on boot.ini with:

    C:\> attrib -s -r c:\boot.ini

Edit to add the appropriate entries from the example boot.ini above, and restore the attributes:

    C:\> attrib +s +r c:\boot.ini

If FreeBSD is booting from the MBR, restore it with the DOS fdisk command after you reconfigure them to boot from their native partitions.

For FreeBSD 3.x systems the procedure is somewhat simpler.

If FreeBSD is installed on the same disk as the NT boot partition simply copy /boot/boot1 to C:\BOOTSECT.BSD However, if FreeBSD is installed on a different disk /boot/boot1 will not work, /boot/boot0 is needed.

/boot/boot0 needs to be installed using sysinstall by selecting the FreeBSD boot manager on the screen which asks if you wish to use a boot manager. This is because /boot/boot0 has the partition table area filled with NULL characters but sysinstall copies the partition table before copying /boot/boot0 to the MBR.

When the FreeBSD boot manager runs it records the last OS booted by setting the active flag on the partition table entry for that OS and then writes the whole 512-bytes of itself back to the MBR so if you just copy /boot/boot0 to C:\BOOTSECT.BSD then it writes an empty partition table, with the active flag set on one entry, to the MBR.

If you have FreeBSD and Linux on the same disk, just follow LILO's installation instructions for booting a non-Linux operating system. Very briefly, these are:

Boot Linux, and add the following lines to /etc/lilo.conf:

    other=/dev/hda2
            table=/dev/hda
            label=FreeBSD

(the above assumes that your FreeBSD slice is known to Linux as /dev/hda2; tailor to suit your setup). Then, run lilo as root and you should be done.

If FreeBSD resides on another disk, you need to add loader=/boot/chain.b to the LILO entry. For example:

    other=/dev/dab4
            table=/dev/dab
            loader=/boot/chain.b
            label=FreeBSD

In some cases you may need to specify the BIOS drive number to the FreeBSD boot loader to successfully boot off the second disk. For example, if your FreeBSD SCSI disk is probed by BIOS as BIOS disk 1, at the FreeBSD boot loader prompt you need to specify:

    Boot: 1:da(0,a)/kernel

On FreeBSD 2.2.5 and later, you can configure boot(8) to automatically do this for you at boot time.

The Linux+FreeBSD mini-HOWTO is a good reference for FreeBSD and Linux interoperability issues.

Install LILO at the start of your Linux boot partition instead of in the Master Boot Record. You can then boot LILO from BootEasy.

If you are running Windows-95 and Linux this is recommended anyway, to make it simpler to get Linux booting again if you should need to reinstall Windows95 (which is a Jealous Operating System, and will bear no other Operating Systems in the Master Boot Record).

The installation procedure allows you to chose two different methods in partitioning your harddisk(s). The default way makes it compatible with other operating systems on the same machine, by using fdisk table entries (called ``slices'' in FreeBSD), with a FreeBSD slice that employs partitions of its own. Optionally, one can chose to install a boot-selector to switch between the possible operating systems on the disk(s). The alternative uses the entire disk for FreeBSD, and makes no attempt to be compatible with other operating systems.

So why it is called ``dangerous''? A disk in this mode does not contain what normal PC utilities would consider a valid fdisk table. Depending on how well they have been designed, they might complain at you once they are getting in contact with such a disk, or even worse, they might damage the BSD bootstrap without even asking or notifying you. In addition, the ``dangerously dedicated'' disk's layout is known to confuse many BIOSsen, including those from AWARD (eg. as found in HP Netserver and Micronics systems as well as many others) and Symbios/NCR (for the popular 53C8xx range of SCSI controllers). This is not a complete list, there are more. Symptoms of this confusion include the ``read error'' message printed by the FreeBSD bootstrap when it cannot find itself, as well as system lockups when booting.

Why have this mode at all then? It only saves a few kbytes of disk space, and it can cause real problems for a new installation. ``Dangerously dedicated'' mode's origins lie in a desire to avoid one of the most common problems plaguing new FreeBSD installers - matching the BIOS ``geometry'' numbers for a disk to the disk itself.

``Geometry'' is an outdated concept, but one still at the heart of the PC's BIOS and its interaction with disks. When the FreeBSD installer creates slices, it has to record the location of these slices on the disk in a fashion that corresponds with the way the BIOS expects to find them. If it gets it wrong, you will not be able to boot.

``Dangerously dedicated'' mode tries to work around this by making the problem simpler. In some cases, it gets it right. But it is meant to be used as a last-ditch alternative - there are better ways to solve the problem 99 times out of 100.

So, how do you avoid the need for ``DD'' mode when you are installing? Start by making a note of the geometry that your BIOS claims to be using for your disks. You can arrange to have the kernel print this as it boots by specifying -v at the boot: prompt, or using boot -v in the loader. Just before the installer starts, the kernel will print a list of BIOS geometries. Do not panic - wait for the installer to start and then use scrollback to read the numbers. Typically the BIOS disk units will be in the same order that FreeBSD lists your disks, first IDE, then SCSI.

When you are slicing up your disk, check that the disk geometry displayed in the FDISK screen is correct (ie. it matches the BIOS numbers); if it is wrong, use the g key to fix it. You may have to do this if there is absolutely nothing on the disk, or if the disk has been moved from another system. Note that this is only an issue with the disk that you are going to boot from; FreeBSD will sort itself out just fine with any other disks you may have.

Once you have got the BIOS and FreeBSD agreeing about the geometry of the disk, your problems are almost guaranteed to be over, and with no need for ``DD'' mode at all. If, however, you are still greeted with the dreaded ``read error'' message when you try to boot, it is time to cross your fingers and go for it - there's nothing left to lose.

To return a ``dangerously dedicated'' disk for normal PC use, there are basically two options. The first is, you write enough NULL bytes over the MBR to make any subsequent installation believe this to be a blank disk. You can do this for example with

    # dd if=/dev/zero of=/dev/rda0 count=15

Alternatively, the undocumented DOS ``feature''

    C:\> fdisk /mbr

will to install a new master boot record as well, thus clobbering the BSD bootstrap.

You need to understand what du and df really do. du goes through the directory tree, measures how large each file is, and presents the totals. df just asks the filesystem how much space it has left. They seem to be the same thing, but a file without a directory entry will affect df but not du.

When a program is using a file, and you delete the file, the file isn't really removed from the filesystem until the program stops using it. The file is immediately deleted from the directory listing, however. You can see this easily enough with a program such as more. Assume you have a file large enough that its presence affects the output of du and df. (Since disks can be so large today, this might be a very large file!) If you delete this file while using more on it, more doesn't immediately choke and complain that it cannot view the file. The entry is simply removed from the directory so no other program or user can access it. du shows that it is gone -- it has walked the directory tree and the file isn't listed. df shows that it is still there, as the filesystem knows that more is still using that space. Once you end the more session, du and df will agree.

Note that softupdates can delay the freeing of disk space; you might need to wait up to 30 seconds for the change to be visible!

This situation is common on web servers. Many people set up a FreeBSD web server and forget to rotate the log files. The access log fills up /var. The new administrator deletes the file, but the system still complains that the partition is full. Stopping and restarting the web server program would free the file, allowing the system to release the disk space. To prevent this from happening, set up newsyslog(8).

The best way is to increase the size of your swap partition, or take advantage of this convenient excuse to add another disk. The general rule of thumb is to have around 2x the swap space as you have main memory. However, if you have a very small amount of main memory you may want to configure swap beyond that. It is also a good idea to configure sufficient swap relative to anticipated future memory upgrades so you do not have to futz with your swap configuration later.

Adding swap onto a separate disk makes things faster than simply adding swap onto the same disk. As an example, if you are compiling source located on one disk, and the swap is on another disk, this is much faster than both swap and compile on the same disk. This is true for SCSI disks specifically.

When you have several disks, configuring a swap partition on each one is usually beneficial, even if you wind up putting swap on a work disk. Typically, each fast disk in your system should have some swap configured. FreeBSD supports up to 4 interleaved swap devices by default. When configuring multiple swap partitions you generally want to make them all about the same size, but people sometimes make their primary swap partition larger in order to accommodate a kernel core dump. Your primary swap partition must be at least as large as main memory in order to be able to accommodate a kernel core.

IDE drives are not able to allow access to both drives on the same channel at the same time (FreeBSD does not support mode 4, so all IDE disk I/O is ``programmed''). It is still suggested that you put your swap partition on a separate driver, however: the drives are so cheap, it is not worth worrying about.

Swapping over NFS is only recommended if you do not have a local disk to swap to. Swapping over NFS is slow and inefficient in FreeBSD releases prior to 4.x, but reasonably fast in releases greater or equal to 4.0. Even so, it will be limited to the network bandwidth available and puts an additional burden on the NFS server.

Here is an example for 64Mb vn-swap (/usr/swap0, though of course you can use any name that you want).

Make sure your kernel was built with the line

    pseudo-device   vn 1   #Vnode driver (turns a file into a device)

in your config-file. The GENERIC kernel already contains this.

1. create a vn-device

       # cd /dev
       # sh MAKEDEV vn0
   

2. create a swapfile (/usr/swap0)

       # dd if=/dev/zero of=/usr/swap0 bs=1024k count=64
   

3. set proper permissions on (/usr/swap0)

       # chmod 0600 /usr/swap0
   

4. enable the swap file in /etc/rc.conf

       swapfile="/usr/swap0"   # Set to name of swapfile if aux swapfile desired.
   

5. reboot the machine

To enable the swap file immediately, type

    # vnconfig -e /dev/vn0b /usr/swap0 swap

Please have a look at the Handbook entry on printing. It should cover most of your problem. See the Handbook entry on printing.

Some printers require a host-based driver to do any kind of printing. These so-called ``WinPrinters'' are not natively supported by FreeBSD. If your printer does not work in DOS or Windows NT 4.0, it is probably a WinPrinter. Your only hope of getting one of these to work is to check if the ports/print/pnm2ppa port supports it. From its package description:

This software creates output using the PPA (printer performance architecture) protocol. This protocol is used by some HP "Windows-only" printers, including the HP Deskjet 820C series, the HP DeskJet 720 series, and the HP DeskJet 1000 series. [...]

WWW: http://pnm2ppa.sourceforge.net/

The kbdcontrol program has an option to load a keyboard map file. Under /usr/share/syscons/keymaps are a number of map files. Choose the one relevant to your system and load it.

    # kbdcontrol -l uk.iso

Both the /usr/share/syscons/keymaps and the .kbd extension are assumed by kbdcontrol(1).

This can be configured in /etc/sysconfig (or rc.conf(5)). See the appropriate comments in this file.

In 2.0.5R and later, everything related to text fonts, keyboard mapping is in /usr/share/examples/syscons.

The following mappings are currently supported:

• Belgian ISO-8859-1

• Brazilian 275 keyboard Codepage 850

• Brazilian 275 keyboard ISO-8859-1

• Danish Codepage 865

• Danish ISO-8859-1

• French ISO-8859-1

• German Codepage 850

• German ISO-8859-1

• Italian ISO-8859-1

• Japanese 106

• Japanese 106x

• Latin American

• Norwegian ISO-8859-1

• Polish ISO-8859-2 (programmer's)

• Russian Codepage 866 (alternative)

• Russian koi8-r (shift)

• Russian koi8-r

• Spanish ISO-8859-1

• Swedish Codepage 850

• Swedish ISO-8859-1

• Swiss-German ISO-8859-1

• United Kingdom Codepage 850

• United Kingdom ISO-8859-1

• United States of America ISO-8859-1

• United States of America dvorak

• United States of America dvorakx

The following is an excerpt from a post to the freebsd-current mailing list.

	The ``can't assign resources'' messages indicate that the devices are legacy ISA devices for which a non-PnP-aware driver is compiled into the kernel. These include devices such as keyboard controllers, the programmable interrupt controller chip, and several other bits of standard infrastructure. The resources cannot be assigned because there is already a driver using those addresses.
--Garrett Wollman <wollman@FreeBSD.org>, 24 April 2001

• Do not turn on quotas on /,

• Put the quota file on the file system that the quotas are to be enforced on. ie:

  Filesystem	Quota file
  /usr	/usr/admin/quotas
  /home	/home/admin/quotas
  ...	...

The symptom of this is:

    # ccdconfig -C
    ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format

This usually happens when you are trying to concatenate the c partitions, which default to type unused. The ccd driver requires the underlying partition type to be FS_BSDFFS. Edit the disklabel of the disks you are trying to concatenate and change the types of partitions to 4.2BSD.

The symptom of this is:

    # disklabel ccd0
    (it prints something sensible here, so let's try to edit it)
    # disklabel -e ccd0
    (edit, save, quit)
    disklabel: ioctl DIOCWDINFO: No disk label on disk;
    use "disklabel -r" to install initial label

This is because the disklabel returned by ccd is actually a ``fake'' one that is not really on the disk. You can solve this problem by writing it back explicitly, as in:

    # disklabel ccd0 > /tmp/disklabel.tmp
    # disklabel -Rr ccd0 /tmp/disklabel.tmp
    # disklabel -e ccd0
    (this will work now)

Yes, FreeBSD supports System V-style IPC. This includes shared memory, messages and semaphores. You need to add the following lines to your kernel config to enable them.

    options    SYSVSHM          # enable shared memory
    options    SYSVSEM          # enable for semaphores
    options    SYSVMSG          # enable for messaging

Recompile and install your kernel.

The sendmail configuration that ships with FreeBSD is suited for sites that connect directly to the Internet. Sites that wish to exchange their mail via UUCP must install another sendmail configuration file.

Tweaking /etc/sendmail.cf manually is considered something for purists. Sendmail version 8 comes with a new approach of generating config files via some m4(1) preprocessing, where the actual hand-crafted configuration is on a higher abstraction level. You should use the configuration files under /usr/src/usr.sbin/sendmail/cf.

If you did not install your system with full sources, the sendmail config stuff has been broken out into a separate source distribution tarball just for you. Assuming you have got your CDROM mounted, do:

    # cd /cdrom/src
    # cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail

Do not panic, this is only a few hundred kilobytes in size. The file README in the cf directory can serve as a basic introduction to m4 configuration.

For UUCP delivery, you are best advised to use the mailertable feature. This constitutes a database that sendmail can use to base its routing decision upon.

First, you have to create your .mc file. The directory /usr/src/usr.sbin/sendmail/cf/cf is the home of these files. Look around, there are already a few examples. Assuming you have named your file foo.mc, all you need to do in order to convert it into a valid sendmail.cf is:

    # cd /usr/src/usr.sbin/sendmail/cf/cf
    # make foo.cf
    # cp foo.cf /etc/mail/sendmail.cf

A typical .mc file might look like:

    VERSIONID(`Your version number')
    OSTYPE(bsd4.4)
    
    FEATURE(accept_unresolvable_domains)
    FEATURE(nocanonify)
    FEATURE(mailertable, `hash -o /etc/mail/mailertable')
    
    define(`UUCP_RELAY', your.uucp.relay)
    define(`UUCP_MAX_SIZE', 200000)
    define(`confDONT_PROBE_INTERFACES')
    
    MAILER(local)
    MAILER(smtp)
    MAILER(uucp)
    
    Cw    your.alias.host.name
    Cw    youruucpnodename.UUCP

The lines containing accept_unresolvable_domains, nocanonify, and confDONT_PROBE_INTERFACES features will prevent any usage of the DNS during mail delivery. The UUCP_RELAY clause is needed for bizarre reasons, do not ask. Simply put an Internet hostname there that is able to handle .UUCP pseudo-domain addresses; most likely, you will enter the mail relay of your ISP there.

Once you have got this, you need this file called /etc/mail/mailertable. If have only one link to the outside that is used for all your mails, the following file will be enough:

    #
    # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable
    .                             uucp-dom:your.uucp.relay

A more complex example might look like this:

    #
    # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable
    #
    horus.interface-business.de   uucp-dom:horus
    .interface-business.de        uucp-dom:if-bus
    interface-business.de         uucp-dom:if-bus
    .heep.sax.de                  smtp8:%1
    horus.UUCP                    uucp-dom:horus
    if-bus.UUCP                   uucp-dom:if-bus
    .                             uucp-dom:

As you can see, this is part of a real-life file. The first three lines handle special cases where domain-addressed mail should not be sent out to the default route, but instead to some UUCP neighbor in order to ``shortcut'' the delivery path. The next line handles mail to the local Ethernet domain that can be delivered using SMTP. Finally, the UUCP neighbors are mentioned in the .UUCP pseudo-domain notation, to allow for a uucp-neighbor !recipient override of the default rules. The last line is always a single dot, matching everything else, with UUCP delivery to a UUCP neighbor that serves as your universal mail gateway to the world. All of the node names behind the uucp-dom: keyword must be valid UUCP neighbors, as you can verify using the command uuname.

As a reminder that this file needs to be converted into a DBM database file before being usable, the command line to accomplish this is best placed as a comment at the top of the mailertable. You always have to execute this command each time you change your mailertable.

Final hint: if you are uncertain whether some particular mail routing would work, remember the -bt option to sendmail. It starts sendmail in address test mode; simply enter 3,0, followed by the address you wish to test for the mail routing. The last line tells you the used internal mail agent, the destination host this agent will be called with, and the (possibly translated) address. Leave this mode by typing Control-D.

    % sendmail -bt
    ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
    Enter <ruleset> <address>
    > 3,0 foo@example.com
    canonify           input: foo @ example . com
    ...
    parse            returns: $# uucp-dom $@ your.uucp.relay $: foo < @ example . com . >
    > ^D

If you have got a statically assigned IP number, you should not need to adjust anything from the default. Set your host name up as your assigned Internet name and sendmail will do the rest.

If you have got a dynamically assigned IP number and use a dialup ppp connection to the Internet, you will probably be given a mailbox on your ISPs mail server. Lets assume your ISPs domain is myISP.com, and that your user name is user. Lets also assume you have called your machine bsd.home and that your ISP has told you that you may use relay.myISP.com as a mail relay.

In order to retrieve mail from your mailbox, you will need to install a retrieval agent. Fetchmail is a good choice as it supports many different protocols. Usually, POP3 will be provided by your ISP. If you have chosen to use user-ppp, you can automatically fetch your mail when a connection to the 'net is established with the following entry in /etc/ppp/ppp.linkup:

    MYADDR:
      !bg su user -c fetchmail

If you are using sendmail (as shown below) to deliver mail to non-local accounts, put the command

      !bg su user -c "sendmail -q"

after the above shown entry. This forces sendmail to process your mailqueue as soon as the connection to the 'net is established.

I am assuming that you have an account for user on bsd.home. In the home directory of user on bsd.home, create a .fetchmailrc file:

    poll myISP.com protocol pop3 fetchall pass MySecret

Needless to say, this file should not be readable by anyone except user as it contains the password MySecret.

In order to send mail with the correct from: header, you must tell sendmail to use user@myISP.com rather than user@bsd.home. You may also wish to tell sendmail to send all mail via relay.myISP.com, allowing quicker mail transmission.

The following .mc file should suffice:

    VERSIONID(`bsd.home.mc version 1.0')
    OSTYPE(bsd4.4)dnl
    FEATURE(nouucp)dnl
    MAILER(local)dnl
    MAILER(smtp)dnl
    Cwlocalhost
    Cwbsd.home
    MASQUERADE_AS(`myISP.com')dnl
    FEATURE(allmasquerade)dnl
    FEATURE(masquerade_envelope)dnl
    FEATURE(nocanonify)dnl
    FEATURE(nodns)dnl
    define(`SMART_HOST', `relay.myISP.com')
    Dmbsd.home
    define(`confDOMAIN_NAME',`bsd.home')dnl
    define(`confDELIVERY_MODE',`deferred')dnl

Refer to the previous section for details of how to turn this .mc file into a sendmail.cf file. Also, don't forget to restart sendmail after updating sendmail.cf.

Do not worry. toor is an ``alternative'' superuser account (toor is root spelt backwards). Previously it was created when the bash(1) shell was installed but now it is created by default. It is intended to be used with a non-standard shell so you do not have to change root's default shell. This is important as shells which are not part of the base distribution (for example a shell installed from ports or packages) are likely be to be installed in /usr/local/bin which, by default, resides on a different filesystem. If root's shell is located in /usr/local/bin and /usr (or whatever filesystem contains /usr/local/bin) is not mounted for some reason, root will not be able to log in to fix a problem (although if you reboot into single user mode you will be prompted for the path to a shell).

Some people use toor for day-to-day root tasks with a non-standard shell, leaving root, with a standard shell, for single user mode or emergencies. By default you cannot log in using toor as it does not have a password, so log in as root and set a password for toor if you want to use it.

Do not Panic! Simply restart the system, type boot -s at the Boot: prompt (just -s for FreeBSD releases before 3.2) to enter Single User mode. At the question about the shell to use, hit ENTER. You will be dropped to a # prompt. Enter mount -u / to remount your root filesystem read/write, then run mount -a to remount all the filesystems. Run passwd root to change the root password then run exit(1) to continue booting.

If you are using syscons (the default console driver) in FreeBSD 2.2.7-RELEASE or later, build and install a new kernel with the line

    options SC_DISABLE_REBOOT

in the configuration file. If you use the PCVT console driver in FreeBSD 2.2.5-RELEASE or later, use the following kernel configuration line instead:

    options PCVT_CTRL_ALT_DEL

For older versions of FreeBSD, edit the keymap you are using for the console and replace the boot keywords with nop. The default keymap is /usr/share/syscons/keymaps/us.iso.kbd. You may have to instruct /etc/rc.conf to load this keymap explicitly for the change to take effect. Of course if you are using an alternate keymap for your country, you should edit that one instead.

Simply use this perl command:

    % perl -i.bak -npe 's/\r\n/\n/g' file ...

file is the file(s) to process. The modification is done in-place, with the original file stored with a .bak extension.

Alternatively you can use the tr(1) command:

    % tr -d '\r' < dos-text-file > unix-file

dos-text-file is the file containing DOS text while unix-file will contain the converted output. This can be quite a bit faster than using perl.

Use killall(1).

The error comes from the Kerberos distributed authentication system. The problem is not fatal but annoying. You can either run su with the -K option, or uninstall Kerberos as described in the next question.

To remove Kerberos from the system, reinstall the bin distribution for the release you are running. If you have the CDROM, you can mount the cd (we will assume on /cdrom) and run

    # cd /cdrom/bin
    # ./install.sh

Alternately, you can remove all "MAKE_KERBEROS" options from /etc/make.conf and rebuild world.

If you have lots of telnet, ssh, X, or screen users, you will probably run out of pseudoterminals. Here is how to add more:

There is no snd device. The name is used as a shorthand for the various devices that make up the FreeBSD sound driver, such as mixer, sequencer, and dsp.

To create these devices you should

    # cd /dev
    # sh MAKEDEV snd0

Go into single user mode and then back to multi user mode.

On the console do:

    # shutdown now
    (Note: without -r or -h)
    
    # return
    # exit

``Sandbox'' is a security term. It can mean two things:

• A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system.

  The process is said to be able to ``play'' inside the walls. That is, nothing the process does in regards to executing code is supposed to be able to breech the walls so you do not have to do a detailed audit of its code to be able to say certain things about its security.

  The walls might be a userid, for example. This is the definition used in the security and named man pages.

  Take the ntalk service, for example (see /etc/inetd.conf). This service used to run as userid root. Now it runs as userid tty. The tty user is a sandbox designed to make it more difficult for someone who has successfully hacked into the system via ntalk from being able to hack beyond that user id.

• A process which is placed inside a simulation of the machine. This is more hard-core. Basically it means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data.

  The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chroot'd (i.e. / for that process is this directory, not the real / of the system).

  Another common use is to mount an underlying filesystem read-only and then create a filesystem layer on top of it that gives a process a seemingly writeable view into that filesystem. The process may believe it is able to write to those files, but only the process sees the effects - other processes in the system do not, necessarily.

  An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it.

Unix implements two core sandboxes. One is at the process level, and one is at the userid level.

Every Unix process is completely firewalled off from every other Unix process. One process cannot modify the address space of another. This is unlike Windows where a process can easily overwrite the address space of any other, leading to a crash.

A Unix process is owned by a particular userid. If the userid is not the root user, it serves to firewall the process off from processes owned by other users. The userid is also used to firewall off on-disk data.

The securelevel is a security mechanism implemented in the kernel. Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. At the time of this writing, the securelevel mechanism is capable of, among other things, limiting the ability to,

• unset certain file flags, such as schg (the system immutable flag),

• write to kernel memory via /dev/mem and /dev/kmem,

• load kernel modules, and

• alter ipfirewall(4) rules.

To check the status of the securelevel on a running system, simply execute the following command:

    # sysctl kern.securelevel

The output will contain the name of the sysctl(8) variable (in this case, kern.securelevel) and a number. The latter is the current value of the securelevel. If it is positive (i.e., greater than 0), at least some of the securelevel's protections are enabled.

You cannot lower the securelevel of a running system; being able to do that would defeat its purpose. If you need to do a task that requires that the securelevel be non-positive (e.g., an installworld or changing the date), you will have to change the securelevel setting in /etc/rc.conf (you want to look for the kern_securelevel and kern_securelevel_enable variables) and reboot.

For more information on securelevel and the specific things all the levels do, please consult the init(8) manual page.

Ordinary users can be permitted to mount devices. Here is how:

All users can now mount the floppy /dev/fd0 onto a directory that they own:

    % mkdir ~/my-mount-point
    % mount -t msdos /dev/fd0 ~/my-mount-point

Users in group operator can now mount the CDROM /dev/cd0c onto a directory that they own:

    % mkdir ~/my-mount-point
    % mount -t msdos /dev/cd0c ~/my-mount-point

Unmounting the device is simple:

    % umount ~/my-mount-point

Enabling vfs.usermount, however, has negative security implications. A better way to access MSDOS formatted media is to use the mtools package in the ports collection.

The best way is to reinstall the OS on the new disk, then move the user data over. This is highly recommended if you have been tracking -stable for more than one release, or have updated a release instead of installing a new one. You can install booteasy on both disks with boot0cfg(8), and dual boot them until you are happy with the new configuration. Skip the next paragraph to find out how to move the data after doing this.

Should you decide not to do a fresh install, you need to partition and label the new disk with either /stand/sysinstall, or fdisk(8) and disklabel(8). You should also install booteasy on both disks with boot0cfg(8), so that you can dual boot to the old or new system after the copying is done. See the formatting-media article for details on this process.

Now you have the new disk set up, and are ready to move the data. Unfortunately, you cannot just blindly copy the data. Things like device files (in /dev), flags, and links tend to screw that up. You need to use tools that understand these things, which means dump(8). Although it is suggested that you move the data in single user mode, it is not required.

You should never use anything but dump(8) and restore(8) to move the root file system. The tar(1) command may work - then again, it may not. You should also use dump(8) and restore(8) if you are moving a single partition to another empty partition. The sequence of steps to use dump to move a partitions data to a new partition is:

For example, if you are going to move root to /dev/ad1s1a, with /mnt as the temporary mount point, it is:

    # newfs /dev/ad1s1a
    # mount /dev/ad1s1a /mnt
    # cd /mnt
    # dump 0af - / | restore xf -

Rearranging your partitions with dump takes a bit more work. To merge a partition like /var into it's parent, create the new partition large enough for both, move the parent partition as described above, then move the child partition into the empty directory that the first move created:

    # newfs /dev/ad1s1a
    # mount /dev/ad1s1a /mnt
    # cd /mnt
    # dump 0af - / | restore xf -
    # cd var
    # dump 0af - /var | restore xf -

To split a directory from it's parent, say putting /var on it's own partition when it wasn't before, create both partitions, then mount the child partition on the appropriate directory in the temporary mount point, then move the old single partition:

    # newfs /dev/ad1s1a
    # newfs /dev/ad1s1d
    # mount /dev/ad1s1a /mnt
    # mkdir /mnt/var
    # mount /dev/ad1s1d /mnt/var
    # cd /mnt
    # dump 0af - / | restore xf -

You might prefer cpio(1), pax(1), tar(1) to dump(8) for user data. At the time of this writing, these are known to lose file flag information, so use them with caution.

Short answer: it is just a name. RC stands for ``Release Candidate''. It signifies that a release is imminent. In FreeBSD, -BETA is typically synonymous with the code freeze before a release.

Long answer: FreeBSD derives its releases from one of two places. Major, dot-zero, releases, such as 3.0-RELEASE and 4.0-RELEASE, are branched from the head of the development stream, commonly referred to as -CURRENT. Minor releases, such as 3.1-RELEASE or 4.2-RELEASE, have been snapshots of the active -STABLE branch. Starting with 4.3-RELEASE, each release also now has its own branch which can be tracked by people requiring an extremely conservative rate of development (typically only security advisories).

When a release is about to be made, the branch from which it will be derived from has to undergo a certain process. Part of this process is a code freeze. When a code freeze is initiated, the name of the branch is changed to reflect that it is about to become a release. For example, if the branch used to be called 4.0-STABLE, its name will be changed to 4.1-BETA to signify the code freeze and signify that extra pre-release testing should be happening. Bug fixes can still be committed to be part of the release. When the source code is in shape for the release the name will be changed to 4.1-RC to signify that a release is about to be made from it. Once in the RC stage, only the most critical bugs found can be fixed. Once the release, 4.1-RELEASE in this example, has been made, the branch will be renamed to 4.1-STABLE.

Short answer: You are probably at security level greater than 0. Reboot directly to single user mode to install the kernel.

Long answer: FreeBSD disallows changing system flags at security levels greater than 0. You can check your security level with the command:

    # sysctl kern.securelevel

You cannot lower the security level; you have to boot to single mode to install the kernel, or change the security level in /etc/rc.conf then reboot. See the init(8) man page for details on securelevel, and see /etc/defaults/rc.conf and the rc.conf(5) man page for more information on rc.conf.

Short answer: You are probably at security level greater than 1. Reboot directly to single user mode to change the date.

Long answer: FreeBSD disallows changing the time by more that one second at security levels greater than 1. You can check your security level with the command:

    # sysctl kern.securelevel

You cannot lower the security level; you have to boot to single mode to change the date, or change the security level in /etc/rc.conf then reboot. See the init(8) man page for details on securelevel, and see /etc/defaults/rc.conf and the rc.conf(5) man page for more information on rc.conf.

No, there is no memory leak, and it is not using 256 Mbytes of memory. It simply likes to (i.e., always does) map an obscene amount of memory into its address space for convenience. There is nothing terribly wrong with this from a technical standpoint; it just throws off things like top(1) and ps(1).

rpc.statd(8) maps its status file (resident on /var) into its address space; to save worrying about remapping it later when it needs to grow, it maps it with a generous size. This is very evident from the source code, where one can see that the length argument to mmap(2) is 0x10000000, or one sixteenth of the address space on an IA32, or exactly 256MB.

You are running at an elevated (i.e., greater than 0) securelevel. Lower the securelevel and try again. For more information, see the FAQ entry on securelevel and the init(8) manual page.

The reason why .shosts authentication does not work by default in more recent versions of FreeBSD is because ssh(1) is not installed suid root by default. To ``fix'' this, you can do one of the following:

• As a permanent fix, set ENABLE_SUID_SSH to true in /etc/make.conf and rebuild ssh (or run make world).

• As a temporary fix, change the mode on /usr/bin/ssh to 4555 by running chmod 4755 /usr/bin/ssh as root. Then add ENABLE_SUID_SSH= true to /etc/make.conf so the change takes effect the next time make world is run.

Yes; see the security/cfs port.

You can't do that with the standard boot manager without rewriting it. There are a number of other boot managers in the sysutils ports category that provide this functionality.