CVS backs up, distributes, and simplifies your configuration files. In this article, Teodor Zlatanov discusses how to save time, energy and frustration when working with Linux configuration files by using your CVS tree. (This introductory-level article was first published by IBM developerWorks, June 10, 2004, at http://www.ibm.com/developerWorks).
You probably already have CVS installed on your machine. If not, get it (see the Resources section) and install it. If you are using another versioning system, try to set up something similar to what I show below.
First of all, you need to create a CVS repository. I'll assume you have access to a machine that can be used as a CVS server through OpenSSH or Pserver CVS access (Pserver is the communication protocol for CVS; see Resources for more information). Then, you need to create a module called config, which I will use to hold the sample configuration files. Finally, you need to arrange a way to use your CVS repository remotely non-interactively, through OpenSSH, Pserver, or whatever is appropriate. This last point is highly dependent on your particular system administration skills, level of paranoia, and environment, so I can only point you to some information in the Resources. I will assume you have configured non-interactive (ssh-agent) logins through OpenSSH for the rest of this article.
Listing 1. Set up the CVS repository on a machine
# assume that /cvsroot is your repository's home > setenv CVSROOT /cvsroot # this will use $CVSROOT if no -d option is specified > cvs init # check that it worked > ls /cvsroot # you should see one directory called CVSROOT CVSROOT
Now that the repository is set up, you can continue using it remotely (you can do the steps below on the CVS server, too -- just leave CVSROOT as in Listing 1).
Listing 2. Remotely add the config module to CVS
# user tzz, machine home.com, directory /cvsroot is the CVSROOT > setenv CVSROOT tzz@home.com:/cvsroot # use SSH as the transport > setenv CVS_RSH ssh # use a temporary directory for the module creation > cd /tmp > mkdir config > cd config
# tzz is the "vendor name" and initial is the "release tag", they can # be anything; the -m flag tells CVS not to ask us for a message
# if this fails due to SSH problems, see the Resources > cvs import -m '' config tzz initial No conflicts created by this import # now let's do a test checkout > cd ~ > rm -rf /tmp/config > cvs co config cvs checkout: Updating config # check everything is correct > ls config CVS
Now you have a copy of the config CVS module checked out in your home directory; we'll use that as our starting point. I'll use my user name tzz and home directory /home/tzz in this article, but, of course, you should use your own user name and directory as appropriate.
Let's create a single file. The CVS options file, cvsrc, seems appropriate since we'll be using CVS a lot more.
Listing 3. Create and add the cvsrc file
> cd ~/config > echo "cvs -z3" > cvsrc > echo "update -P -d" >> cvsrc > cvs add cvsrc # you really don't need log messages here > cvs commit -m '' > ln -s ~/config/cvsrc ~/.cvsrc
From this point on, all your CVS options will live in ~/config/cvsrc, and you will update that file instead of ~/.cvsrc. The specific options you added tell CVS to retrieve directories when they don't exist, and to prune empty directories. This is usually what users want. For the remaining machines you want to set up this way, you need to check out the config module again and make the link again.
Listing 4. Check out the config module and make the cvsrc link
> cd ~ # set the following two for remote access > setenv CVSROOT ... > setenv CVS_RSH ... # now check out "config" -- this will get all the files > cvs checkout config > cd ~/config > ln -s ~/config/cvsrc ~/.cvsrc
You may also know that Linux allows for hard links in addition to the symbolic ones you just created. Because of the limitations of hard links, they are not suitable to this scheme. For instance, say you create a hard link, ~/.cvsrc, to ~/config/cvsrc and later you remove ~/config/cvsrc (there are many ways this could happen). The ~/.cvsrc file would still hold the old contents of what used to be ~/config/cvsrc. Now, you check out ~/config/cvsrc again. The ~/.cvsrc file, however, will not be updated. That's why symbolic links are better in this situation.
Let's say you change cvsrc to add one more option:
Now, to update ~/.cvsrc on every other machine you use, just do the following:
Listing 6: Modify and commit cvsrc
> cd ~/config > cvs update
This is nice and easy. What's even nicer is that the CVS update shown above will update every file in ~/config, so all the files you keep under this CVS scheme will be up-to-date at once with one command. This is the essence of the configuration scheme shown here; the rest is just window dressing.
Note that once you've checked out a module, there's a directory in it called "CVS." The CVS directory has enough information about the CVS module that you can do update, commit, and other CVS operations without specifying the CVSROOT variable.
Visit developerWorks for thousands of developer articles, tutorials, and resources related to open standard technologies, IBM products, and more. See developerWorks.