It’s especially important to use a separate location if you use cvsup to keep your system up-to-date. Otherwise, your next update will notice your modified src and happily replace those missing original source files. But don’t worry; it won’t touch your new
 /usr/share/skel.

Of course, sometimes this is a very useful trick in itself. If you ever mess up a file located somewhere within /usr/src , a quick cvsup will put everything back the way it was. See “Automate Updates” [Hack #80] for details on automating cvsup .

The Other BSDs

The preceding discussion is based on FreeBSD, but it also applies to NetBSD and OpenBSD systems, save for a few tiny differences outlined here.

NetBSD. NetBSD administrators will find the skeleton home directory in /etc/skel. Specify a different location by passing the -k option to useradd .

OpenBSD. OpenBSD systems store the skeleton home directory in /etc/skel. Specify a different skeleton directory location by passing the -dotdir option to adduser .

See Also

• man adduser 
  
• The manpages returned by apropos user

The sign of a true Unix guru is the ability to perform a task quickly when confronted with an unfamiliar shell, keyboard, terminal, window manager, or operating system.

A large part of using Unix systems effectively involves configuring a comfortable environment using familiar tools available from the Unix shell prompt. It’s much easier to perform a task quickly when all of the shortcuts your fingers have learned work on the first try.

Even something as simple as setting up your prompt the way you like it can steal significant time from your productivity if you need to do it on several hosts. If you’re going to spend significant time in a Unix shell, it’s worth getting organized. A bit of onetime effort will reward you later, every time you sit down at the keyboard.

Enter unison

unison is a tool for maintaining synchronized copies of directories. I’ve used it to maintain a central repository of all of my dot files, shell scripts, signatures file, SpamAssassin configuration—basically any file I’d like to have available, regardless of which host I happen to be logged into.

You can install unison from the NetBSD pkgsrc collection:

  # cd /usr/pkgsrc/net/unison
  # make install clean

FreeBSD and OpenBSD ports also include net/unison.

Even better, this utility is available for most Unix and Windows platforms. See the main unison web site for details.

Using unison

Whenever I configure a new Unix host or get a shell on another system, I install unison . Then, I create a directory to receive the files I’ve stored in the /usr/work/sync directory at host.example.com. I call the local directory ~/sync.

To synchronize those two directories:

  % unison ~/sync ssh://username@host.example.com://usr/ work/sync
  p = /home/david/.unison; bn = .unison  
  Contacting server...
  p = /home/david/sync; bn = sync
  username@host.example.com's password:

After ssh prompts for a password or pass phrase, the unison exchange begins. On a first-time synchronization, unison will ask only one question: whether you wish to copy the remote directory to the local host.

  Looking for changes
  Warning: No archive files were found for these roots. This can happen
  either because this is the first time you have synchronized these roots,
  or because you have upgraded Unison to a new version with a different
  archive format.

Update detection may take a while on this run if the replicas are large.

unison will assume that the last synchronized state of both replicas was com pletely empty. This means that any files that are different will be reported as conflicts, and any files that exist only on one replica will be judged as new and propagated to the other replica. If the two replicas are identical, then unison will report no changes:

  Press return to continue .
  Waiting for changes from server
  Reconciling changes
  local       host.example.com
        <---- dir        / [f]
  Proceed with propagating updates? [] y 
  Propagating updates
  UNISON started propagating changes at 11:44:39 on 02 Feb 2004
  [BGN] Copying 
  from //host.example.com//usr/work/sync 
  to /home/david/sync
  bin
  dotfiles
  spamassassin
  bin/randomsig2.pl
  bin/sy
  bin/testaspam
  dotfiles/.c
  dotfiles/.cshrc
  dotfiles/.login
  dotfiles/.muttrc
  dotfiles/.profile
  dotfiles/.tcshrc
  dotfiles/.xinitrc
  spamassassin/user_prefs
  [...]
  [END] Copying
  UNISON finished propagating changes at 11:44:41 on 02 Feb 2004
  Saving synchronizer state
  Synchronization complete

I now have a populated ~/sync directory on the new system, organized into subdirectories. Each subdirectory contains the files I find useful to carry around with my various accounts on multiple Unix machines.

Notice also that although my preferred shell is tcsh , I maintain a .cshrc and .profile for use on systems where tcsh is not available.

Automating the Process

I’ve automated the process with a simple shell script called sy in my bin directory. sy runs the unison command to synchronize the ~/sync directory.

  #!/bin/sh
  unison ~/sync ssh://username@host. example.com://usr/work/ sync

Creating Portable Files

Making good use of the sync directory requires some discipline. It’s one thing to be able to copy files easily; it’s another thing to be able to use them without modification on several hosts.

To take advantage of this hack, when you copy the dot files to your home directory and notice that something doesn’t work exactly the way you like it to, make sure you don’t simply change it for the local host.

Instead, update the dot files so that they use conditional if statements, shell backticks (e.g., `hostname` ), or environment variables, to make them behave correctly on the new hosts without breaking them on the systems where you already use them. Then, copy the dot file back into your ~/sync directory and run the sy script. unison will prompt for a password or passphrase for the ssh connection, then ask you to verify that you want to update your files back to the main server.

The first few times you do this, you may introduce breakage when the new dot file is used on another host. With a bit of practice you’ll learn how to avoid that. The most important trick is to test. Open a shell to the host and update the dot file, and then open a second shell to the host without closing the first one. If you broke anything that affects your ability to log in, you can fix it with the first shell and test again.

There’s no need to resynchronize every other host you use for each file you change. I generally wait until I’m logged onto a given host and need a newer script, or need to make some additional changes to the local copy of the dot file. Then I synchronize, make the changes in the sync directory, test them locally, and resync them back to the main host.

Using this approach means that I don’t have to reinvent the wheel every time I want to perform a procedure I’ve done before. Any process useful enough to be done a couple of times becomes a script in my toolkit, and is conveniently available anywhere I have a shell. With unison , I don’t have to keep track of which files were modified on which end of the connection since my last update.

Keep in mind that using a tool like unison can provide a mechanism for someone to attempt to feed updates into your central file repository. When you log into a host and run the update, be conscious of whether unison asks for approval to send back changes. If you don’t remember making those changes, you might be helping an attacker feed a Trojan horse into your .login, which could end up giving the attacker access to every system you use that script on. unison will ask for confirmation for every file change. Presumably, your central host is secure, but you need to be partic ularly conscious when permitting file uploads.

See Also

• The unison home page (http://www.cis.upenn.edu/~bcpierce/ unison/)