Chapter 9: Too Much Information About /etc

Overview

The /etc directory holds the basic configuration information needed to boot a UNIX system. Every time I encounter an unfamiliar UNIX, one of the first things I do is scope out /etc.

The fastest way to go from a junior UNIX admin to a mid−grade one is to read /etc. Yes, all of it. Yes, this is a lot of reading. But understanding /etc means that you understand how the system hangs together. As you progress as a UNIX admin you're going to pick up this information piecemeal anyway, so you might as well make it easy on yourself and assemble this portion of your toolkit at the beginning.

Many /etc files are discussed in a chapter where they're most relevant (such as /etc/services in Chapter 5. This chapter will cover the important files that don't quite fit anywhere else.

Varieties of /etc Files

Different UNIX systems use different /etc files. In many cases, these files are simply renamed or restructured files from BSD4.3 or BSD4.4. The first time I encountered an IBM AIX box, for example, I went looking for a BSD−style /etc/fstab. It wasn't there. But a little hunting led me to /etc/filesystems, which turned out to be an IBM−specific rearranged version of /etc/fstab. Knowing that the information existed somewhere in /etc, and knowing what files it obviously wasn't in, made the search quite short.

Even radically different FreeBSD systems have almost identical /etc directories. While some add−on programs insert their own files here, you can expect certain files to be on every FreeBSD system you encounter.

Note Before you touch any /etc files, review the information on RCS (Revision Control System) in Chapter 3. I strongly recommend that you create an /etc/RCS directory and use it religiously when experimenting. Changes in /etc can completely disable your system. While recovering a system's scrambled filesystem table can help turn a competent administrator into a good one, it's one of the least pleasant ways to get there.

Default Files

The files in FreeBSD's /etc/defaults/ directory each contain variable assignments. These files are not intended to be edited by the administrator; instead, they're designed to be overridden by a file of the same name directly under /etc.

For example, the upgrade process completely replaces the files in /etc/defaults. While every new version of FreeBSD has a slightly different default configuration, the developers go to great lengths to ensure that changes to these files are backward−compatible. This means that you won't have to go through the upgraded configuration and manually merge in your changes; at most you'll have to check out the new defaults file for nifty new configuration opportunities.

185

/etc/defaults/rc.conf

One commonly used file is /etc/defaults/rc.conf. It contains dozens of lines like this:

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

"named_enable="NO"

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

To change this setting, edit /etc/rc.conf, not /etc/defaults/rc.conf. When editing /etc/rc.conf, list the variable you want to change and what you want to set it to. Your /etc/rc.conf entry will then override what's in /etc/defaults/rc.conf. (Do not just copy the default file to /etc! This causes any number of problems.)

Note While the system install process creates /etc/rc.conf, it's normal to find that you need to create other override files in /etc.

Once you understand the various default files, you can easily assess an unfamiliar FreeBSD system simply by checking the corresponding override files in /etc.

/etc/adduser.conf

Creating new users on some UNIX systems is a pain, requiring you to manually edit /etc/passwd, rebuild the password database, edit /etc/group, create a home directory, install the various dotfiles, and so on. FreeBSD's adduser(8) program makes it much simpler to add users by running all these other programs for you. The adduser.conf file holds adduser's default settings. These variables are easily set just by putting the name, an equal sign, and the value. You can add comments just by putting a pound sign in front of them. Here's a sample entry from this file, with its related comment:

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

# verbose = [0−2]

verbose = 1

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

Verbose

The first entry, verbose, controls how much you see when running adduser. With verbose = 0, adduser prompts you for the new user information and nothing else. If you set verbose = 1, adduser lets you rewrite /etc/adduser.conf before adding a new user. If you set verbose = 2, adduser gives you a great many warnings, questions, and other information. (While the default is 1, you can easily set this to 0 once you're familiar with the process, and have adduser.conf set up the way you like it.)

Defaultpasswd

The defaultpasswd entry, either yes or no, controls whether users have a password set by default. If you have a passwordless account on your system, anyone who knows the username can connect to your system. In any circumstance where you have even the mildest concern for security, set this to yes.

186

Dotdir

The dotdir entry contains the path for sample user dotfiles, such as .cshrc, .login, and so on. The default directory contains reasonable defaults. If you want to create custom dotfiles for your system, it's best to make your own directory under /usr/local/share/skel so that system upgrades won't overwrite your changes (see Chapter 6).

Send_message

If you put a full path to a file in send_message, adduser sends each new user a welcome message. If you set this to no, no message will be sent.

The adduser message uses variables; you can add your own by editing /usr/sbin/adduser. If you're familiar with Perl, this isn't difficult; if not, you're better off just using the variables offered: $username, $fullname, and $password. (Since this message is mailed to the new user, including the password is somewhat useless in addition to foolish. Too, the user has presumably used his password to retrieve this message, so he should have it.) Go ahead and create your own message instead of using the brief and generic default if you wish. I generally use an /etc/adduser.message somewhat like this, substituting the appropriate company name as needed:

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

$fullname,

Welcome to The Company.

Help is available at 800−555−1212, or online at

http://helpdesk.companyname.com.

Use of this account is governed by our acceptable use policy, available at http://aup.companyname.com or on this system in /usr/local/share/company/aup.

Thank you for your business. We look forward to serving you.

The Company Support Staff.

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

Logfile

The logfile setting tells adduser where to write a log of everything it does. The default works.

Home

If your system has unusual partitioning, you might want user directories in a different place than the usual /home. You can control this with the home setting.

Path

If you install software in an unusual location, you might need to change the path entry. (Some systems have their additional programs stored in /opt.)

187

Shellpref

The shellpref setting stores the list of available shells, in order of preference. If you add or remove a shell, you need to correct this.

Defaultshell

The defaultshell setting contains, as you might guess, the default user shell.

Defaultgroup

The defaultgroup entry is a little different. FreeBSD assigns a unique group to each user. For example, when you add the user mwlucas, it tries to create a group mwlucas (which allows greater flexibility when assigning permissions). To have every user be a member of a particular group, put the name of the group here; otherwise, leave this set to USER.

Defaultclass

The defaultclass line controls what login.conf (see /etc/login.conf) class that adduser assigns by default. You can leave this empty, or assign a class from those you have previously configured in /etc/login.conf.

Uid_start

Finally, the uid_start variable determines the user ID (UID) number that adduser will begin with; the default is 1000. You might want to change this number to match UIDs across multiple operating systems; various Linux distributions start with different UID numbers, for example. But if UID synchronization isn't important to you, don't worry about this setting.

/etc/crontab

The crontab file controls the FreeBSD job scheduler, cron, which allows the administrator to have the system run a command at any time.

Each user has a separate crontab file, which can be edited with crontab −e. The /etc/crontab file is the system's file. Unlike user crontabs, /etc/crontab lets the sysadmin specify which user will run a job. For example, the sysadmin can basically say, "Run this job at 10 PM Tuesdays as root, and run this other job at 7 AM every day as nobody." Other users can only run jobs as themselves.

Note The /etc/crontab file is considered a FreeBSD system file. Be careful not to overwrite this file when you upgrade (see Chapter 6). One way to simplify upgrading /etc/crontab is to set your custom entries at the end of the file, marked off with a few lines of hash marks (#).

Environment Statements

The /etc/crontab file begins with some environment statements because cron needs to set up a shell environment for the programs it starts. If you're familiar with shell programming, you can alter these statements to fit your system, but be careful when making blanket changes because changes made at the top of /etc/crontab affect all programs run from the crontab. (You can specify environment variables on the command line for each command you run from cron.)

188

Here are some typical environment variables as set in /etc/crontab on a FreeBSD 4.5−STABLE system.

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

#

SHELL=/bin/sh

PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin

HOME=/

#

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

The hash marks are comments or empty lines used to separate entries and make the file somewhat easier to read.

Beneath the environment information, the crontab file is divided into eight columns, forming a table. The first six columns represent the time the command should run: minute, hour, day of the month, month of the year, and day of the week, in that order. An asterisk (*) in any column means "every one," while a number means "at this exact time."

Following the time columns is the username the job runs as, then the command.

User crontab files are almost identical, lacking only the username column.

Specifying Times

You must use a valid number for times in crontab. The rule is that minutes, hours, and days of the week start with 0, and days of the month and months begin with 1. Also, thanks to an ancient disagreement between AT&T and BSD, the day of the week uses both 7 and 0 for Sunday.

For example, to have user dbadmin run the program /usr/local/bin/db backup.sh at 55 minutes after each hour, every day to infinity, your crontab line would look like this:

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

55 * * * * * dbadmin /usr/local/bin/db−backup.sh

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

Asterisks tell cron to run this job every hour, every day of the month, every month, and every weekday.

To run this job only at 1:55 PM each day, you would use the following:

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

55 13 * * * * dbadmin /usr/local/bin/db−backup.sh

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

Here, 13 represents 1:00 PM on the 24−hour clock, and 55 the number of minutes past the hour.

One common mistake people make when using cron is to specify a large unit of time, but miss the small one. For example, suppose you entered the following, intending to run a job every day at 8

189

AM:

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

* 8 * * * * dbadmin /usr/local/bin/db−backup.sh

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

In this case, you'd find that the job would run at 8 AM, all right, as well as at 8:01, 8:02, 8:03, and so on, until 9:00 AM. If your job takes more than one minute to run, you'll quickly bring your system to its knees.

The correct way to specify 8 AM and only 8 AM would be to enter this:

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

0 8 * * * * dbadmin /usr/local/bin/db−backup.sh

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

To specify ranges of time, such as running this program once an hour, every hour, between 8 AM and 6 PM, Monday through Friday, use something like this:

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

1 8−18 * * * 1−5 dbadmin /usr/local/bin/db−backup.sh

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

To specify exact times, separate them with commas:

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

1 8,10,12,15,18 * * * 1−5 dbadmin /usr/local/bin/db−backup.sh

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

Or, more interestingly, you can specify fractions of time, or steps. For example, to run a program every five minutes, enter the following:

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

*/5 * * * * * dbadmin /usr/local/bin/db−backup.sh

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

You can also combine ranges with steps. For example, if you want your job to run every five minutes, but want it offset by one minute from the preceding job, you could use this:

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

1−56/5 * * * * * dbadmin /usr/local/bin/db−backup.sh

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

You can control the day a job runs with two fields: the day of the month and the day of the week. If you specify both a day of the month and a day of the week, the job will run whenever either condition is met. For example, you might tell cron to "Run this job on the 1st and the 15th, plus every Monday" as follows:

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

55 13 * 1,15 * 1 dbadmin /usr/local/bin/db−backup.sh

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

If you find that a job requires a nonstandard environment, set the environment on the command line just as you would in the shell. For example, if your db−backup.sh program requires a

190