Sheepdog

Summary

Sheepdog is a system¹ for managing shell .files across multiple unix machines so you can keep a fairly consistent environment (paths, aliases, etc) across all your machines while still keeping machine-specific customizations.

The main job of the script is to put files in the right places. Once things are going, you just need to make changes to the right files (by convention) and keep things up to date via your scm.

Right now the script is fairly minimal, but appears to work. Mostly. I think.

Danger! Danger!

This is pre-alpha software. It's so far from alpha it might as well be omega from the last epoch. Use at your own risk, after making backups. Seriously: this has been in use on my own machines for a few months, but there's no guarantee it works elsewhere. This is a test release.

Standard test disclaimer:

Actually, this has been a feature of Unix for years now. A process may have all of its child processes reaped without warning, lose its entire flock, and even find itself afflicted by boils, all at the whims of the scheduler. This is why the operating system refers to a suspended process as a "stopped Job". Unfortunately, most implementations fail to capitalize the name, leading to widespread confusion and mispronunciation among users. -Dan Martinez

This assumes:

• you're comfortable with . files
• you have access to some sort of version control system
• you know how to use the version control system

Script

Do not use it without reading and understanding this page. Alternatively, make peace with your new lack of files.

Download the script from here.

Details

The environment files (.profile, .cshrc, etc. -- ".files") are replaced with symbolic links pointing to scripts in the .sheepdog directory. Each script then calls files in order, if available:

1. a machine-specific script
2. a generic script
3. another machine-specific script

For example, say you have two desktop machines and a laptop, and most of your environment is the same on all three machines, but:

• One of the desktops ("desktopextra") has additional software installed, and the path for that software needs to be set up before everything else.
• You have a couple aliases you only use on the laptop ("laptop"), and don't want for the other machines (e.g. commands to connect to the desktops).

Sheepdog would make all your "generic" aliases available on all machines, and handle the two exception cases:

• For the desktop with extra software, the path would be defined before the generic path, and not be available on other machine.
• For the laptop, the additional aliases would be defined after the generic aliases, and not be available on other machines.

For example, you'll have files which look something like this:

.bashrc@ -> .sheepdog/scripts/.bashrc
.profile@ -> .sheepdog/scripts/.profile
.sheepdogrc
.sheepdog/
  scripts/
    .bashrc
    .profile
    pre/
      .profile.desktopextra
    main/
      .bashrc
      .profile
    post/
      .profile.laptop

On the desktop with extra software, .profile will consist of running pre/.profile.desktopextra and then main/.profile. On the laptop, .profile will consist or running main/.profile and then post/.profile.laptop.

How-To, with some details

1. • First* , prepare:
   • Pick which .files (e.g. .cshrc, .profile, etc.) you want to manage, and make backup copies of each.
   • Decide on a naming scheme for your machines. Each machine must have a one word name (e.g. laptop, desktop, workmachine).
2. • Next*, install on the first machine, and set up:
   • Pick a machine to start with. It's usually easiest to start with the most vanilla machine -- the one closest to the "generic" config.
   • Put the sheepdog script somewhere you can reach it (this tutorial will assume it's in your path) and make sure it's set up to allow execution.
   • sheepdog initialize This will initalize the environment.
   • cp ~/.sheepdog/configs/sample ~/.sheepdogrc
   • Edit ~/.sheepdogrc:
   • edit the "host" line to reflect your name for this host
   • edit the "files" line to name the files you want managed
   • sheepdog import This will move your existing files to ~/.sheepdog/scripts/post/[filename].[machinename]. For example, the .profile on your "work" machine should wind up in ~/.sheepdog/scripts/post/.profile.work. This step means that your original .files will now be called after any generic files (which you haven't created yet.)
   • sheepdog lninstall This creates the symbolic links.
   • Put ~/.sheepdog under version control.
3. Then, edit your files:
   • Each .file under management is now a symbolic link in your home dir, pointing to a "master" script in ~/.sheepdog/scripts.
   • This master script then calls subscripts, if available, in order:
   • ~/.sheepdog/scripts/pre/$filename.$machinename
   • ~/.sheepdog/scripts/main/$filename
   • ~/.sheepdog/scripts/post/$filename.$machinename
   • The file in main is the generic file which will be run on all machines. Files in pre and post will also be run (before and after the file in main, respectively) on the machines whose names match.
   • Move any generic commands out of the file in "post" and into the file in "main".
   • Move any non-generic commands that must run before the generic commands into the "pre" file.
   • Commit your changes back to the repository so other machines can pick them up.
4. Finally, add other machines. For each one:
   • Install sheepdog on the new machine.
   • Check .sheepdog out the new machine.
   • Create the .sheepdogrc.
   • sheepdog import Alternatively, move . files into the post dir and add an extension to the name to include the machine name (e.g. ~/.profile on your "laptop" would become ~/.sheepdog/scripts/post/.profile.laptop).
   • sheepdog lninstall Once again, creates the symlinks.
   • Remove commands and environment variables from file to file depending on whether you want them available on all machines or just specific machines. Also remove duplicates.
   • Commit your changes back to the repository. On other machines, update from the repository to pick up the changes.
5. Profit!

To Do

Some things that are probably worth doing:

• Figure out how to do exceptions rather than overrides.
• Figure out machine groupings (namespaces?)
• Get rid of the "pre" scripts -- nobody seems to use them.

Feedback

Please mail comments to faisal@faisal.com.