Whenever the remote command contains spaces, you need to enclose the command in quotes.

That simple tar and ssh command makes creating tar archives on a remote machine about as quick and easy as it gets.

Check out Technique 13 for more information about using archives and tar. The tar man page also details tons of options you can add to the tar command to tailor this technique to your system.

When you execute the command, you’re prompted for your password on the other machine. Adding public key authentication to the SSH connection allows you to skip password authentication.

Setting up a key ring for authentication takes only a few minutes and can save you a lot of time in the long run. See Technique 33 for the lowdown on setting up ssh to accept public keys.

Backing up to tape drives on remote machines

One other quick trick you can do with tar and ssh is to back up to remote tape drives. Just replace the destination filename with the device name, and ssh delivers your archive to the tape drive. For example, if the tape drive on your remote host is named /dev/rmt0, use the following command:

$tar zcvf - /source | ssh remotehost “cat

>/dev/rmt0”

With just a few variations, the tar command provides a powerful backup tool. Use it with Task Scheduler to automate nightly backups, and you’ll really save time! (See Technique 20 for more information about scheduling automated tasks).

Backing Up to a Remote Computer with rdist and ssh

rdist is a command line tool that helps you maintain identical copies of files or directories over multiple hosts. You can use rdist with ssh to distribute sales reports, inventory lists, or other files to remote offices that need access to shared data. tar and ssh make it easy to create an archive on a single remote computer, but rdist can push complete directory trees to any number of remote systems.

You can easily back up a single system to multiple remote hosts with rdist.

You can also use rdist to back up important system and data files to a remote host. With the cost of welloutfitted computers at an all-time low, keeping a mirror image of important files is financially feasible.

Using rdist to create a mirror image of treasured files makes backing up quick and easy.

An rdist backup isn’t a perfect mirror image of your complete working system. The boot sectors of your local machine and any files being used at the time of backup will be different on the remote host.

Testing the ssh connection to the remote host

Before you can use rdist, you need to have a clean ssh connection with each of your targets. Test the ssh connection at the command line with a trial connection:

$ ssh remotehostname

If you’ve lived a good clean life, you should be able to make an ssh connection to the remote host. If the connection succeeds, you’re prompted for a password and allowed to log in to the remote system.

Save time by setting up ssh to handle publickey authentication for you so you don’t need to enter a password. Check out Technique 33 for details.

Creating the distfile

After you’ve tested the ssh connection to the remote machine, you must create a file (called distfile) that contains the information that rdist needs to run — such as the remote host name, the files you want to transfer, and any exceptions to the default rules.

To create a distfile, follow these steps:

1. Open a terminal window to your home directory and enter the following command:

$ kedit distfile

kedit opens into a fresh file, waiting for your distfile code.

2. Enter the following code (substituting your username and remotehost name):

HOSTS = ( username@remotehost )

FILES = ( ~/ )

EXCEPT = ( ~/Desktop/Trash )

${FILES} -> ${HOSTS}

install -oyounger,whole target ; except ${EXCEPT} ;

3. Click the Save icon on the toolbar and close the editor.

You’ve just created a basic distfile. The first three lines of the distfile define a few variables that make it easy to write the rest of the file:

HOSTS: This variable holds a list of one or more host names. (If you want to distribute data to more than one host, list each host name between the parentheses, separated by spaces.) If you’re using ssh to establish the connection to a remote machine, you can prefix the host name with a user name followed by an @ character, like this:

FILES: This variable contains a space-separated list of the files or directories that you want to copy to the remote host. In our example, we want to copy the $HOME directory.

EXCEPT: This variable names the files that you don’t want to send to the remote host(s). You usually don’t need a duplicate of the Trash bin.

The second half of the distfile contains the commands for rdist:

The first line tells rdist to move the files (as defined by the FILE variable at the top of the distfile) to the hosts named by the HOSTS variable (also defined at the top of the distfile).

The install command follows with the options that rdist should use for the backup. In our example, the option -oyounger tells rdist to check the timestamp on the file and update only those files that have been changed since the last backup. The target names the directory on the remote host that receives the backup. If you leave it blank, rdist creates a duplicate of the local directory tree on the host and copies the files into the mirror image.

The -o needs to be right next to the install option; otherwise, rdist copies the files into a directory named whatever install option you try to use (for example, if you typed in “-o younger” instead of the correct “-oyounger”, rdist would create a directory named younger). To use multiple install options, chain them together with commas, like this: -oyounger,quiet,remove.

The except command tells rdist to skip the files that are named in the EXCEPT variable.

Table 51-1 lists some of the more useful install options.

TABLE 51-1: USEFUL INSTALL OPTIONS

Make sure that you want to remove files from the backup before you use the remove option. In the process of testing these commands, we accidentally wiped out the CVS repository for this book and the results of a (fortunately completed) consulting project on one of our systems. remove really does remove everything. It’s a good thing we had backups!

For more options to use with rdist, visit the rdist manual page: $ man rdist.

Backing up

After you’ve tested your ssh connection and created the distfile, you’re ready to back up. Open a terminal window and enter the following command:

$ rdist -P /usr/bin/ssh

rdist takes it from there, consulting the distfile for the information it needs to complete the backup. It doesn’t get much quicker than that!

The last argument in the command must be the complete pathname to the ssh program. It would be nice if you could specify the transfer program (ssh) in the distfile, but you can’t.

As a real timesaver, set up a cron job to transfer your files every night. See Technique 20 for help using Task Scheduler to set up an automatic backup in a snap!

Save Time By

Using CVS to archive projects

Using cervisia to manage your repository

Reverting to a previous project stage in an emergency

Creating project branches and development lines

CVS (Concurrent Versions System) enables multiple developers to work on the same project without the risk of losing work. CVS tracks changes to the files that make up the project. For example,

while writing this book, we stored each technique in a separate file in a CVS repository. When we wanted to make a change to a technique, we checked out the file, made our changes, and committed the changes back to the repository. We both used the same CVS repository (in fact, Susan was writing with a Macintosh, and Korry was making typos on a Linux computer). Sometimes, the same technique was checked in and out several times before it was done. With CVS, there’s no risk of data loss. If we would have both gotten the same technique accidentally, the merge feature would have resolved the differences in the versions (not that it would ever have happened). We also had a complete history of all the changes that we ever made.

When using a CVS repository, it’s a good idea to commit your changes frequently. In addition to ensuring that your coworkers have access to the latest version of your work, if something happens to your CVS client, the CVS server will always have a copy of your latest work. This technique shows you how to use a CVS system to keep your work safe with minimal time and effort.

CVS can be used with any type of file (though it’s not particularly powerful for binary files). System administration files, sales lists, artwork, and programming projects are all good candidates for a CVS repository. If a project goes awry, and you need to revert to a previous stage in your development, CVS can reconstruct a working version from a previous point in the project. We show you how in this technique.

CVS is a great timesaver — saving you time by avoiding the potential problems that come from lost data and crossed development paths. With CVS, you can secure your files and keep creativity flowing at a pace that suits everyone.