Chapter 10 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.

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.

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 print/pnm2ppa port supports it.

Please see the Handbook section on using localization, specifically the section on console setup.

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

• Do not turn on quotas on /,

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

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

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/mail/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 you 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 [email protected]
    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 example.net, 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.example.net 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 example.net protocol pop3 fetchall pass MySecret

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 [email protected] rather than [email protected]. You may also wish to tell sendmail to send all mail via relay.example.net, 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(`example.net')dnl
    FEATURE(allmasquerade)dnl
    FEATURE(masquerade_envelope)dnl
    FEATURE(nocanonify)dnl
    FEATURE(nodns)dnl
    define(`SMART_HOST', `relay.example.net')
    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, do not forget to restart sendmail after updating sendmail.cf.

Sendmail is the default mail-server software for FreeBSD, but you can easily replace it with one of the other MTA (for instance, an MTA installed from the ports).

There are various alternative MTA's in the ports tree already, with mail/exim, mail/postfix, mail/qmail, mail/zmailer, being some of the most popular choices.

Diversity is nice, and the fact that you have many different mail-servers to chose from is considered a good thing; therefore try to avoid asking questions like ``Is Sendmail better than Qmail?'' in the mailing lists. If you do feel like asking, first check the mailing list archives. The advantages and disadvantages of each and every one of the available MTA's have already been discussed a few times.

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.

Short answer: it is just a name. RC stands for ``Release Candidate''. It signifies that a release is imminent. In FreeBSD, -PRERELEASE is typically synonymous with the code freeze before a release. (For some releases, the -BETA label was used in the same way as -PRERELEASE.)

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.5-STABLE, its name will be changed to 4.6-PRERELEASE 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.6-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.6-RELEASE in this example) and release branch have been made, the branch will be renamed to 4.6-STABLE.

For more information on version numbers and the various CVS branches, refer to the Release Engineering article.

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) manual page for details on securelevel, and see /etc/defaults/rc.conf and the rc.conf(5) manual 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) manual page for details on securelevel, and see /etc/defaults/rc.conf and the rc.conf(5) manual 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.

vnlru flushes and frees vnodes when the system hits the kern.maxvnodes limit. This kernel thread sits mostly idle, and only activates if you have a huge amount of RAM and are accessing tens of thousands of tiny files.