Reviewing a File's Revision History

Notice that in the previous section I didn't bother to leave a log message in revision 1.3 (z). To see what changed, I use rcsdiff, which takes three arguments: two revisions and a filename, as shown here.

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

# rcsdiff −r1.2 −r1.3 /etc/rc.conf

===================================================================

RCS file: /etc/RCS/rc.conf,v retrieving revision 1.2 retrieving revision 1.3 diff −r1.2 −r1.3

6c6

< inetd_enable="NO"

v > inetd_enable="YES"

#

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

Apparently I turned inetd on between the revisions (v), which is important information (especially if yours is a production system, especially one administered by several people). We'll discuss inetd in Chapter 13.

You can also use rcsdiff between arbitrary revision numbers, allowing you to view all the changes made between any two revisions. In the preceding example, we chose the differences between two consecutive versions. I could have asked for the differences between revisions 1.1 and 1.4, however, and seen everything that had changed since the file was first checked in.

Ident and ident Strings

Identification strings are used to make it easy for someone to see who has changed a file, and when it was changed. For example, if I have a server that has been behaving oddly for the last week, I just want to know what changed a week ago. I could go around running rlog on every system configuration file to see when things were changed, but that's a bit annoying. It would be much nicer to just look at the file and have that information presented to me. That's where identification strings come in. You can put ident strings in your system configuration files. When you check a file out, RCS will automatically update them.

RCS supports many ident strings, each with the form $string$. For example, the RCS ident string $Id$ puts information about the last change in the file. I always put #$Id$ in the first line of my systems’ /etc/rc.conf and check it in. It appears as:

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

#$Id: rc.conf,v 1.5 2000/10/05 18:29:49 mwlucas Exp mwlucas $

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

Note The pound sign (#) is a comment that tells /etc/rc not to try to run the line. Use whatever comment marker is appropriate for the file.

The following are some typical ident strings.

65

$Id$ is the most commonly used ident string. It shows the location of the RCS file, the revision number, the date and time of the first check−in, the author, the state, and the person who last locked it.

Note RCS state is an arbitrary string that you can assign with ci(1) or rcs(1). You can set arbitrary states for a file to give a hint about what it's for or what its condition is. Many people will use this to mark a file as "experimental" or "production" or "don't change for any reason whatsoever." You don't need to worry about the file state, just accept that it defaults to Exp, or "experimental." RCS state is not generally used in systems administration.

$Header$ is another common ident string. It's identical to $Id$, except that it gives the full path for the RCS file instead of just the filename.

$Log$ is an interesting ident string that adds the RCS log message to the file itself; when you view the file, you will see the log messages. While the log messages can be overwhelming on heavily edited files, they can be useful in files that change less frequently. For example, the /etc/rc.conf on my servers doesn't change at all after a month or so of production use. If I put this ident string in the file, I will see all RCS log messages in the actual file. This makes it very obvious what's changed, who has changed it, and why.

There are several more ident strings, but they're basically subsets of the three just described. See ident(1) for a complete list.

Going Further

Revision control is a powerful tool . You can find a mostly complete tutorial at http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/rcs/.

[2]Some reviewers commented that this section might scare off new sysadmins. Others said that they'd wished they'd known about revision control when they started. Don't be intimidated; it's not that difficult and it really will make life better for you.

[3]A warning to vi users; if you or your group owns the file, a w! will force a permission change and allow you to write to the file even without checking it out. Everything will look fine, but the next person who checks out the file will overwrite your changes! Be careful using w! anything; if vi complains that you don't have permission to save, there's a good reason. Listen to it.

Single−User Mode

Unlike many other operating systems, BSD−based systems can perform a minimal boot, which is important for troubleshooting and system repair.

This minimal boot, also called single−user mode, loads the kernel and finds devices, but doesn't automatically set up your disk, start the network, enable system security, or run the standard UNIX services. Single−user mode is the first point at which the system can possibly give you a command prompt, however, so you can enable any of these services from there.

When a FreeBSD box first starts to boot, it gives you a ten−second countdown and offers you a chance to pause the system. If you press a key, it drops you to an OK prompt. To boot into single−user mode from this prompt, enter the following:

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

66

OK> boot −s

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

You'll see the regular device−probe messages flow by, and then the system will offer you a chance to choose a shell. (You can enter any shell on the root partition; I usually just take the default, /bin/sh, but you can use /bin/tcsh if you prefer.)

You can use single−user mode to reset a lost root password by simply doing this:

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

#fsck −p

#mount −a

#passwd root

#exit

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

The mount −a command mounts the filesystems listed in /etc/fstab (see Chapter 13). If one of those filesystems is misbehaving and crashing the system, you can mount filesystems individually by specifying them on the mount command line (for example, mount /usr).

If your system is even more badly damaged, you might not be able to read /etc/fstab. In this case, you can mount the root partition by using the device name as described in Chapter 13, which is probably either /dev/ad0s1a (for IDE disks) or /dev/da0s1a (for SCSI disks). You can use this to mount the partition, specifying the mount point where you want it to be accessible. For example, to mount your first IDE disk to root, enter this command:

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

# mount /dev/ad0s1a/

#

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

Here's how this has worked for me: Once I was experimenting with FreeBSD's Linux mode. I had an experimental Linux filesystem listed in /etc/fstab. When I upgraded to a recent FreeBSD−current (see Chapter 6), that filesystem stopped working.[4] When that filesystem was mounted, the computer crashed. Worse, the computer tried to mount it every time the system booted. The computer would boot halfway, crash, and try to boot again, over and over and over again. I booted into single−user mode, manually fsck'd /usr, mounted it, and used vi to edit /etc/fstab to comment out the offending filesystem.

You can use similar techniques to enable or disable anything on your system before it finishes booting, just by editing /etc/rc.conf (see Chapter 9) or the appropriate /usr/local/etc/rc.d file (see Chapter 11). This lets you do things like alter the system's securelevel (explained in Chapter 7) before the system finishes booting.

Note To activate the network while in single−user mode, use the script /etc/netstart to do so without starting any network services, such as inetd or httpd.

The commands you have available to you in single−user mode will depend on which partitions you

67

have mounted. Some basic commands are on the root partition, in /bin and /sbin. Others (such as vi and ee) live on /usr and are inaccessible until you mount that partition. Take a look in /bin and /sbin on your system to get an idea what you'll have to work with.

If you can't even boot into single−user mode, then you're left with one final option: the fixit disk.

[4]Please note that none of this is recommended. One of the nice things about FreeBSD is that it doesn't forbid you to do dangerous things; instead, it lets you learn why they're considered dangerous.

The Fixit Disk

The best way to learn UNIX is to play with it, and the harder you play, the more you learn. If you play hard enough, you'll break something for sure, and having to fix a badly broken system is arguably the fastest way of all to learn. If you've just rendered your system unbootable, or plan to learn quickly enough to risk doing that, this section is for you. You're going to learn a lot quickly—though mostly on your own.

One of the more interesting portions of FreeBSD is the fixit disk. You can boot off the installation media but choose to enter fixit mode instead of installing the OS. The choice to use fixit mode is in the first menu the installer gives you.

You must have some familiarity with systems administration to use the fixit system successfully! Essentially, the fixit disk gives you a command prompt and a variety of UNIX utilities. You get to use your brains and the boottime error messages to fix the problem. It's you against the computer. Of the half−dozen times I've resorted to the fixit disk, the computer won the first three. The time was well spent, however, as I'm now fairly capable of restoring a damaged system. Definitely finish reading this book before you even try.

It's impossible to outline a step−by−step fixit process; the exact process you need to follow depends on exactly what sort of damage you've done to your poor, innocent computer. If you're really desperate, however, fixit mode gives you a shot at recovery without a complete reinstall. I've had problems where I've accidentally destroyed my /etc or /dev directories, or fried the "getty" programs that display a login prompt. Careful use of fixit mode can repair these problems in a fraction of the time a reinstall would require.

To use fixit mode, you need a set of FreeBSD installation media (either the CD or the two boot floppies) and either a fixit floppy or the second CD from the FreeBSD release you're using. You can download the fixit floppy image from any FreeBSD FTP server. You can get recent FreeBSD release CDs from various vendors, such as Daemon News and the FreeBSD Mall.

It's important to use a fixit disk that's roughly equivalent to the FreeBSD version you're running. A point or two off won't make much difference, but you won't be happy trying to fix a 4.4−stable system with a 5.0−current fixit disk.

Boot off the installation media. When you reach the first menu, you'll see a choice to enter fixit mode. Select it. You'll then get a choice of using the CD or the floppy. Use the CD if you have it. The fixit floppy only contains the programs that will fit on a single floppy disk. If you have a fixit CD, you will have the full range of programs available on a default FreeBSD install. While it might not include your favorite editor or shell, it should have everything you need.

You can mount your existing hard drive under /mnt. Programs are either under /stand or /mnt2. The exact commands you get vary from one release of FreeBSD to another; run ls /mnt2 and ls

68

/stand to see what you have.

At times, all you can hope for is to get the hard drive mounted so that you can read data from it—the fixit CD contains all the tools you will need to get the system on the network. One of the good points of the FreeBSD installer is that you have the option to keep existing partitions. You can tar up existing data files while running on the fixit disk, and then reinstall. Once you have a running system, you can extract the tarballs, and have your system back.

Now that you understand how to recover your system, configuration, and files, let's go on and start customizing your operating system for your computer.

69