On a newly installed system, you'll also see a file /kernel.GENERIC, which is the generic install kernel. On systems that have been running for a while, you might also find a variety of other kernels, some of which will be old, while others are alternates for particular circumstances or experiments that didn't work out. The FreeBSD team makes configuring and installing kernels as simple as possible. Let's take a look.

Configuring Your Kernel

FreeBSD provides two main ways to configure an existing kernel: sysctl(8) and the boot loader.

Sysctl

The sysctl program allows you to peek at values used by the kernel, and in some cases to set them. Just to make things confusing, these values are also sometimes known as sysctls. Sysctl is a powerful feature because, in many cases, it will let you solve performance issues without rebuilding the kernel or reconfiguring an application. Unfortunately, this power also gives you the ability to kick the legs out from under a running program and make your users really, really unhappy.

All sysctl operations are performed with the sysctl(8) command. Throughout this book, I will be pointing out particular sysctls that change system behavior, but you should understand what they are first.

Before we begin playing with sysctl operations, take a look at the sysctls available on your system. The following command will save them to a file so you can study them easily:

...............................................................................................

# sysctl −A > sysctl.out

...............................................................................................

After running this command, the file sysctl.out will contain hundreds of sysctl variables and their values, most of which will mean absolutely nothing to you at this point, but some are easily understood:

...............................................................................................

kern.hostname: bigbox.blackhelicopters.org

...............................................................................................

This particular sysctl is named kern.hostname and has a value of "bigbox.blackhelicopters.org". The system I ran this command on happens to be called "bigbox.blackhelicopters.org". From the name of the sysctl, it's fairly easy to guess that this is the kernel's name for the computer it's running on. Easy enough to figure out, no?

Some are much more curious:

...............................................................................................

p1003_1b.memory_protection: 0

...............................................................................................

71

As a user, I have no idea what this value means. Still, if I'm having trouble and ask for help from a software vendor or on a mailing list, I can produce this information upon request. They might ask me to adjust it to better support their software.

The sysctls are organized in a tree format called a Management Information Base, or MIB, with several broad categories, such as net, vm, and kern. (The Management Information Base tree is used in several other parts of system administration; we'll see another example later in this book.) Each of these categories is further subdivided; for example, the net category covers all networking sysctls and is divided into categories such as IP, ICMP, TCP, and UDP. The terms sysctl MIB and sysctl are frequently used interchangeably. There are many sorts of MIB—we'll see examples of SNMP MIBs in Chapter 19—but throughout this chapter, we're only discussing sysctl MIBs.

We saw the kern.hostname MIB earlier, and if you look at the sysctls available on your machine, you'll see that a whole bunch of them begin with "kern". These are all general kernel values. If you go down a little further, you'll see a whole bunch that begin with "kern.ipc.", such as these:

...............................................................................................

kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128

. . .

...............................................................................................

These sysctls describe the kernel's IPC[1] behavior. This branching of sysctls can go on for several layers.

You will eventually wind up with individual MIBs, such as net.inet.raw.recv−space. Each MIB has a value that represents some buffer, setting, or characteristic used by the kernel. By changing the value, you change how the kernel operates. For example, some sysctls control how much memory is used for each network connection. If your network performance is poor, you could increase the amount of system reserved for network connections. Some of the roots of the sysctl MIB tree are listed in Table 4.1.

Table 4.1: Some roots of the sysctl MIB tree

Sysctl	Function
kern	core kernel functions
vm	virtual memory
vfs	filesystems
net	networking

72

debug	debugging information
hw	hardware information
machdep	platform−dependent variables (i.e., Alpha,
	i386, etc.)
user	userland interface information
p1003_1b	[2]
	POSIX behavior

[2]POSIX is an international standard for UNIX program behavior and kernel features. Most of FreeBSD complies with POSIX.

Each sysctl value is either a string, integer, binary value, or opaque. Strings are free−format text of arbitrary length; integers are ordinary whole numbers; binary values are either 0 (off) or 1 (on); and opaques are in machine code and only specialized programs can interpret them.

Unfortunately, sysctls are not well documented, and rather than there being a single document listing all available sysctl MIBs and their functions, what MIB documentation there is generally appears in the man page for what it controls. For example, the original documentation for the MIB kern.securelevel (discussed more in Chapter 7) is in init(8). Many have no documentation. Appendix A includes a list of some common sysctls and their uses.

Fortunately, some MIBs are obvious. For example, if you scan your file of saved MIBs, near the top you'll see this one:

...............................................................................................

kern.bootfile: /kernel

...............................................................................................

This is an important MIB if you regularly boot different kernels. (We'll look later in this chapter at how to boot an alternate kernel.) If you're debugging a problem and have to reboot with several different kernels in succession, you can easily identify which kernel you're using by checking this MIB. More than once I've booted a test kernel, tested a problem and found it fixed, and realized that I had forgotten which kernel I'd booted.

To view a subtree of the MIBs available in a particular tree, such as kern, enter this command:

...............................................................................................

# sysctl kern kern.ostype: FreeBSD

kern.osrelease: 5.0−CURRENT kern.osrevision: 199506

...

...............................................................................................

This list goes on for quite some time. If you're just becoming familiar with sysctls, you might want to look and see what's available. To get the exact value of a particular sysctl, give the full MIB as an argument:

...............................................................................................

# sysctl kern.securelevel

73

kern.securelevel: −1

#

...............................................................................................

In this case, kern.securelevel has the integer value –1. We'll discuss exactly what this means in Chapter 7).

Changing Sysctls

Some sysctl values are read−only. For example, take a look at the hw (hardware) and machdep (machine dependencies) MIB trees.

...............................................................................................

hw.machine: i386

...............................................................................................

Since the FreeBSD project has yet to develop the technology to change Intel−based hardware into PowerPC hardware via a software setting, this setting is read−only; all you'd accomplish by changing a MIB like this is to hose your system. FreeBSD protects you by making these sorts of MIBs read−only. Trying to change it won't hurt anything, but you'll just get a warning that the MIB cannot be changed.

On the other hand, consider the following MIB:

...............................................................................................

MIBvfs.usermount: 0

...............................................................................................

This one, which controls whether or not users can mount media such as CDROMs and floppy disks, can be changed. By default it is set to 0, or off. To turn it on, use sysctl's −w flag to set it to 1.[3].

...............................................................................................

# sysctl −w vfs.usermount=1

vfs.usermount: 0 −> 1

#

...............................................................................................

Sysctl returns a nice little message showing the previous value and the change to the new value. That's all there is to changing a sysctl.

Setting Sysctls at Boot

Sysctls you want set at boot−time should be entered in /etc/sysctl.conf. To do so, list each sysctl you want to set, and the desired value, in the sysctl.conf file.

74