Help, I've Fallen

Copyright © 1998 Gary Kline and Dirk Myers

In this issue the Dirk and Gary Show has had OpenBSD input from three people: David Leonard d@fnarg.net.au, Nikolay Sturm sturm@physik.rwth-aachen.de , and Robert Vogel rvogel@ntexas.net . Nikolay's and Robert's feedback is scattered throughout the column; David wrote the column entry on the -stable vs -current release issues and other tidbits.

These debts having gratefully been acknowledged, it's on with the third issue and several questions & answers of Help, I've Fallen. We do our best to come up with the correct answers for each of the Berkeley releases, but bear in mind that your mileage may vary. (Does that translate into metric?)

• I can telnet to my FreeBSD system and login as myself just fine, but when I try to login as root, it fails. The system accepts `root' and my password, then just gives me a new "login:" prompt. What's wrong?

• I want to be able to su to root from my own login and understand that I have to put myself in the groups file as wheel. Can you explain exactly what need to do?

• What's the easiest way to change my full name in the password data base? Do I have to su to root?

• Should I run NetBSD-1.3.2 or NetBSD-current?

• Can you explain the difference between the FreeBSD-STABLE and FreeBSD-CURRENT versions? Which one should I use?

• Can you explain the difference between OpenBSD releases and current? Which one should I use?

• How do I install a pre-built package somewhere other than the default directory?

• What's the difference between ~/.Xdefaults and ~/.Xresources? I was trying to alter some default settings (height and width) for my xcoral editor, but couldn't figure it out.

• Can you discuss backups in general. Which way(s) are best?

• How do I get the "at" command to execute a run that I want to begin in the wee hours of the night? The "at" utility seems like a good way to do what I want to, but the man page isn't entirely clear.

• %%% Tip of the month:

Q: I can telnet to my FreeBSD system and login as myself just fine, but when I try to login as root, it fails. The system accepts `root' and my password, then just gives me a new "login:" prompt. What's wrong?

[ Note: NetBSD shows the message login refused on this terminal ]

% man su

will explain the utility.

(To allow ordinary users to become the superuser, they must be in the `wheel' group. See the following question.)

Q: I want to be able to su to root from my own login and understand that I have to put myself in the groups file as wheel. Can you explain exactly what need to do?

A: Log out of your personal account and log in (from the console) as root. Edit /etc/group:

% vi /etc/group

Add your login, say "smith" to the wheel line.

Edit this:

	   wheel:*:0:root
	   daemon:*:1:daemon
	   kmem:*:2:root

to this:

	   wheel:*:0:root,smith
	   daemon:*:1:daemon
	   kmem:*:2:root

Be careful not to add spaces to the entry. Also, don't delete root from the wheel group.

If you repeatedly perform the same root tasks, you may want to look into the "sudo" program. It's available in the ports/packages system, and allows specific users to execute specific commands as root. [For OpenBSD, "sudo" is part of the base install.]

Q: What's the easiest way to change my full name in the password data base? Do I have to su to root?

A: No, you don't. The command

% chfn

will do what you want. chfn allows users to change some entries in /etc/master.passwd. It uses whichever EDITOR is defined in the current environment (vi by default). Carrying the subject a bit further, chsh will let you change your shell, and

% passwd

as yourself (without root-level permission) will allow you to change your password.

chfn and chsh are the links to the same program, chpass, and present the same data to be edited so it doesn't matter which you use.

% chpass

will present the same screen.

% man chpass

will give you many more details.

Unix generally, and *BSD in particular, gives its users substantial control over the details of their personal environments: these password-file-editing utilities are examples.

Q: Should I run NetBSD-1.3.2 or NetBSD-current?

That's not a question that we can answer for you, but we can give you some information to help you make your decision.

For NetBSD, the released versions (i.e., 1.3.2) are believed to be generally stable and bug-free at the time of release. The overall code base is frozen with a major and minor number. The final digits are incremented as bug fixes (and, occasionally, minor enhancements) are added to the code. If you're looking for stable, well-tested code, this is where to find it.

-current, on the other hand, reflects the current state of the main source tree. At a given moment, the code might be rock-solid, or it might not even compile. The state of -current is discussed on NetBSD's current-users mailing list. If you're going to use -current, you should subscribe to this list. -current changes rapidly, and something that doesn't work on one day is often fixed the next day.

Many NetBSD portmasters (or kindly volunteers) build tarred snapshots of -current for their ports at various intervals. This can be a relatively painless way to bring a machine up to -current. Be warned, though, that these snapshots just reflect the state of -current at a particular moment. They're not any better or worse than -current itself.

So why run -current? Lots of reasons. -current has often been improved over the latest release version. It's fun to watch the system grow and evolve on your own machine. If you want to contribute to the development of the system, you probably need to run -current.

One final caveat: If you're going to upgrade from a released version to -current, upgrade your user programs as well as your kernel. The internals of -current may be radically different from the released version (in fact, as of this writing, -current for many ports uses the UVM virtual memory system, whereas 1.3.2 uses an older virtual memory system.)

Q: Can you explain the difference between the FreeBSD-STABLE and FreeBSD-CURRENT versions? Which one should I use?

A: As with the NetBSD discussion above, it depends upon what you want. Do you need rock-solid stability, or are you more interested in a cutting-edge system with more risk? The -current versions of FreeBSD are really pretty solid, but, as with any development project, carry some risks.

Most of this material is adapted from the FreeBSD handbook which is getting to be a remarkably usable resource.

First about -stable.

-stable is the development branch containing a more conservative set of changes meant for the next mainstream FreeBSD release. Experimental or untested changes do not go into this branch.

If your main concern is stability, then you probably want to use the -stable branch. Then keep track of the release by subscribing to freebsd-stable@freebsd.org, the list that details issues with -stable.

FreeBSD-current:

-current is a daily snapshot of the working sources for FreeBSD.

These include work in progress, experimental changes and transitional mechanisms that may or may not be present in the next official release.

There are periods of time when the sources are literally un-compilable. These problems are generally resolved as expeditiously as possible, but whether or not FreeBSD-current sources bring disaster or greatly desired functionality can literally be a matter of which part of any given 24 hour period you grabbed them in!

You may wish to use -current if you are working on part of the source tree or just want to study the code, run it, and track its development.

Over the past few years -current has proven an exceptionally stable, almost production-quality system.

It is essential to track the developments by subscribing to the freebsd-current@freebsd.org mailing list.

To stay current with the actual code release you need to read up on the cvsup utility. The URL

www.freebsd.org/handbook/cvsup.html

is the place to begin.

Nik Clayton has a tutorial on rebuilding and installing your world from retrieved code. The information at http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html will lead you by the hand.

Q: Can you explain the difference between OpenBSD releases and current? Which one should I use?

A: The answer to this is much the same as for the FreeBSD and NetBSD discussions above.

Releases

Production-quality releases generally appear every six months and CD ROM distributions can be obtained through www.openbsd.org. These stable releases have been carefully checked before release, and security patches are made available on the web site and announced through the announce mailing list as rapidly as possible.

Releases are essentially the product of a `release cycle'. This is where the current sources for the operating system are `frozen' for a few weeks and only fixes, essential and polishing changes are allowed during this time. The developers also build and test the installation of distributions built from the release cycle sources. This goes a long way to ensuring that the operating system will work cleanly `straight out of the box'.

Current

You should only be tracking the current, 'live' OpenBSD source tree if you are already using the OS and are more interested in living at the bleeding edge, than in running a stable, tested release. Current is not for production environments. It is intended for those users with significantly advanced software development skills, significant CPU and storage resources, and who understand the vicissitudes of large, fast-moving software projects.

One of OpenBSD's foci is in providing a quality open system: just having access to the latest sources has many benefits. These benefits include the ability to delve into the sources to find out exactly what a program's behaviour is. It also allows for the rapid isolation and identification of bugs for the concerned site: you can fix the fault and be up and running again without having to wait for the vendor to `get back to you'.

There are a couple of ways of tracking current with OpenBSD. Both require some form of network connectivity.

AnonCVS

If you have direct IP access to the Internet, you can use anonymous CVS. This allows you to use the CVS tool to keep a mirror of the OpenBSD source tree at your site.

The CVS repository keeps all past and present variants of all files that have ever been in the source tree, as well as change comments that explain why a change was made. It also has the advantage that you are able to make custom changes to the sources and they will automatically be merged with the next update.

OpenBSD's CVS repository is mirrored in about a dozen places around the world. Generally, each mirror is synchronised every few hours.

CTM

If you don't have direct IP access, or have a very slow link, you can subscribe to the CTM mailing list and receive nightly deltas of the source tree or CVS repository itself. These email messages are (often automatically) fed to a program that applies the delta to your local copy of the tree.

It may take quite a while to get set up with CTM as you will need to download quite a slew of previous deltas, but receiving deltas this way is much cheaper than using AnonCVS.

Although the current source tree is available through CTM, it is worth tracking the CVS repository so that you have all the advantages of CVS as described above (and only if you have the space of course!)

Snapshots

Halfway between current and the releases are the 'snapshots'. These can be found on OpenBSD FTP mirror sites. They are occasionally created and made available made by developers for particular architectures and obviate the need to have the resources to 'make build'. If you are interested in snapshots, you should nudge the appropriate developer for your platform through email.

Q: How do I install a pre-built package somewhere other than the default directory?

A: First of all, this is somewhat risky for pre-built packages. The program may have been compiled to look under the default directory for various .conf or other support files. If that's the case, the program won't work in a different location.

The "pkg_add" command provides a way to redirect the installation of the package to a different directory, by using the '-p' flag.

% pkg_add -p <directory> <name of package>

The -p flag sets the "prefix" for the package installation. However, this flag just substitutes the <directory> you specify for the _first_ change directory command in the package file. Typically, this will be to "/usr/pkg" and all the other commands will be expressed relative to this directory. (Note that the actual directory use is a case where there's some variation between Free/Net/OpenBSD. FreeBSD uses "/usr/local", and I (Dirk) think this is the case for OpenBSD as well.)

Not all packages are built this way, though. To check whether the package you want to install will work with the '-p' flag, extract the +CONTENTS file from the archive, and make sure that the @cwd directives after the first @cwd /usr/pkg are relative, rather than absolute pathnames. (Remember, the first @cwd might go to somewhere other than "/usr/pkg", depending on your system.)

To extract +CONTENTS file from the package, first make a copy of the package.

% cp thepackage.tgz newfile.tgz

Next, use the 'gunzip' utility to uncompress the package back into tar format:

% gunzip newfile.tgz

This will replace "newfile.tgz" with "newfile.tar". Finally, use the following command to get the +CONTENTS file from the tar archive. In this 'tar' command, the 'x' instructs tar to extract files from the archive. The 'f' indicates that tar should use the filename immediately following the 'f' (in this case, "newfile.tar") as the archive to extract from. The final "+CONTENTS" is the name of the file tar should extract from the archive.

% tar -xf newfile.tar +CONTENTS

After you've got the +CONTENTS file, you can go ahead and delete the "newfile.tar" archive:

% rm newfile.tar

Now, look over the "@cwd" directives in the file. As long as the first "@cwd" is the only one that refers to "/usr/pkg" (or "/usr/local"), the -p flag will work. Otherwise, you'll have to do the installation in two steps.

% pkg_add -M <package name> > newcontents

The -M flag, which stands for "Master" will extract the package to a temporary directory, and place the name of the temporary directory and the contents of the +CONTENTS file into the newcontents file. You can then edit the newcontents file so that the @cwd directives place the package files where you want them. When you're ready to actually install the package, pipe the revised newcontents file to pkg_add with the -S ("Slave") flag.

% cat newcontents | pkg_add -S

Q: What's the difference between ~/.Xdefaults and ~/.Xresources? I was trying to alter some default settings (height and width) for my xcoral editor, but couldn't figure it out.

A: Whether a given program will use .Xdefaults or .Xresources depends on how the program was written.

~/.Xresources details those types of resources used by and within the Xt intrinsics. Programs built with Xt define these resources within the source code, and use the corresponding entries within the ~/.Xresources file (e.g.: geometry, font type, background and foreground color.)

X Window programs built directly upon Xlib (which is in some ways more "primitive", and at the same time gives the X-programmer more capability) cannot use the .Xresources file. They rely upon ~/.Xdefaults directly.

xrvt is one program built directly out of Xlib; the powerful French editor, xcoral is another; magicpoint and xfedor yet others.

Whenever you alter your Xdefaults file, before rxvt, xcoral any of the other non-Xt X Window programs will be aware of the changes, you must type

% xrdb ~/.Xdefaults

To find out more about X in general, try

% man X

and to learn more about the X resource database utility, use

% man xrdb

Q: Can you discuss backups in general. Which way(s) are best?

A: You are probably looking for an overview on nightly backups onto tape, diskette, disk, or doing an rcp to a networked machine. But first a few words on doing intra-day backup.

To protect yourself from losing files during the day (between your nightly backups), you might consider using RCS. RCS is a Revision Control System. What this means in this context is that it keeps track of changes to files. RCS will grow on you. --This is by no means a tutorial on RCS

Getting started is simple.

In your working directory, type:

% mkdir RCS

then to save a given text file, checkin to RCS with ci:

% ci Makefile README development.notes main.c atom.c

The checkin program ci will ask for a comment like this when you check in a new text file:

enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>>

In this test, you can simply type a dot (".") and ci will be happy. The files above will disappear from your current working directory and be saved away in the RCS subdirectory.

To check the file out of the RCS directory, and lock it, use co -l:

% co -l Makefile README development.notes main.c atom.c

If you are doing any kind of serious development, it makes sense to save the file(s) after every significant change. This allows to you to return to earlier versions of your work if you need to.

Saving your work in this way will save you from accidents wrought by commands like

% rm * .o

(As an aside, RCS is a good revision control tool. If you're using your *BSD machine for a large or complex project you will profit by spending some time with the 'rcs' man page. If more than one person is working on the project read up on CVS.)

Saving things this way or creating a .SAVE directory and copying everything into this directory is a quick and dirty way.

% cp -rp * .SAVE

If there is any chance of your machine crashing from a power outage during the day and you are networked to another system it might be worth considering a small shell script to tar up your work and copy--or uuencode and mail--elsewhere.

% rcp <tarball> smith@some.othersite.com:/tmp

99.9+% of the time this will be overkill. The other ~.1% of the time, it will save hours to months of labor. You can't appreciate this until you've lost months of non-replaceable data!

Nightly backups

tar to tape

The name of the first SCSI tape drive is "rst0". A second SCSI tape device would be "rst1", the third, "rst2", and so forth.

If you have enough space to backup your entire system on one tape, this tar command will do it

% tar -cvf /dev/rst0 /

This is the now-familiar tar command, but rather than writing to an actual file, the output is sent to /dev/rst0 -- which is the raw tape drive itself, disguised as a file.

If you want to back up your entire system with compression and have your tape ejected when the back up in complete, try

% tar -czvf /dev/est0 /

The tar -z flag uses gzip compression, and the "e" in the device name tells the driver to eject the tape upon completion.

You may want to back up just your /home directories:

% tar -cvf /dev/rst0 /home

Or multiple directories -- say /home, /var, /pub, /usr/local/src, and /etc:

% tar -cvf /dev/nrst0 /home /var /pub /usr/local/src /etc

Note that the "n" in /dev/nrst0 means "do not rewind" the tape. This allows you to make multiple archives on one tape. Otherwise, the tape will rewind in between directories -- you'll end up with an archive of /etc that's overwritten the other archives.

To check the list of files archived, use

% tar -t

The -t flag, which stand for "list", lets you see the contents of an archive. In this case, since we're using /dev/rst0 (the default), we don't need to specify where tar will find the archive. The -t flag is a way of checking, however minimally, that what you thought was being archived is actually in the tar file.

To actually retrieve files from your tape backup,

% gtar -xvf /dev/rst0 "*home/smith/letters*"

will extract the "letters" directory from the tape. You can search with "-tvf <pattern>" first if you are not certain of the file or directory name.

tar is an amazingly flexible program. You can write to any device you have attached, and read the list of files to archive from a file rather than specifying it on the command line

% tar -cvf /dev/fd0 -T backup.list

writes whatever you have listed in "backup.list" to (in this example) floppy drive 0.

The "backup.list" file just needs to contain the files you want backed up. For example, you might have a file that looks like this:

         /home/smith/my.important.files/doc.1
         /home/smith/my.important.files/doc.20
         /home/smith/my.important.files/doc.33
         /home/smith/my.important.files/doc.47
         /home/smith/my.important.files/doc.1

When you're backing up, make certain that your media is good and that you have a valid backup. Be aware of how fast it will wear out, and throw it away (or store it) before you expect trouble. For example, a floppy that's written to a couple of times a day, every day, will need to be replaced periodically. Check your floppy backups regularly!

More next time

Q: How do I get the "at" command to execute a run that I want to begin in the wee hours of the night? The "at" utility seems like a good way to do what I want to, but the man page isn't entirely clear.

A: You're right, the "at" command will do what you're looking for. at can run either a list of commands contained in a file:

% at -f Filename_With_List_Of_Commands now + 120 minutes

or you can give it commands interactively:

% at now + 120 minutes<return>

	type in commands
	type in additional commands
	type in additional commands ...
	...
	^D

or, it can accept commands from standard input:

% echo 'command' | at now + 5 minutes

The results of your run will be neatly mailed to you by the "Atrun Service" rather than sent to stdout (your screen).

Note that your login name must be in /var/at/at.allow to allow the at command to work.

%%% Tip of the month:

For the security of your system, here is a safer way of setting one's user path.

(The first example is for the Bourne sh and its sibling shells such as ksh, zsh. An example for the csh follows, and bash is last.)

The point of this Tip is not how to set your path variable, but a better way to include your local, current-working-directory.

path=( /home/smith/bin /bin /usr/bin /usr/local/bin /usr/X11R6/bin .)

For csh and tcsh, the following syntax sets your PATH variable.
setenv PATH "~/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:."

bash also uses the colon to separate the target directories:
export PATH=/home/smith/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:.

If you must include . in your PATH, put it last. The reason is that it is not unheard of for someone looking to break into your system to place a trojan horse imitating a common command (say, ls) somewhere in your system. Since the shell matches things in the order specified in your path, a program called ls in your current working directory will be run rather than /bin/ls if "." appears earlier than "/bin" in your path.

The trojan "ls" might, for example, delete every file in your personal account. Or something equally malicious. Trojan horse programs are not common; but they're also not difficult for an attacker to write. Also note that if the trojan horse calls the program you meant to run after it does its dirty work, you may not even notice you didn't get the regular program!

It is perhaps wisest not to put "." in your PATH at all; to force you to type "./a.out" whenever exec'ing your own, non-standard binary. Make safety and security measures second-nature!

Gary Kline kline@thought.org, and Dirk Myers dirkm@buster.dhis.org