Tame Your Wild Config Herds with CVS
Scripting is a powerful tool in a Linux/UNIX environment, but you can quickly lose track of the many scripts you create for specific circumstances. One way to record and track changes: CVS. Carla Schroeder explains how to set up and maintain a CVS repository.
Two of the great joys of Linux are plain-text configuration files and scripting -- combined, they are easy to read, edit, reproduce, deploy and automate. I especially like the ability to create multiple configurations for a program, such as a mail server or backup script, and easily call up different configs for testing.
Every sysadmin develops their own tips and tricks and particular ways of doing things. Scripts and configuration files change and evolve over time. The wise sysadmin keeps backup copies of everything -- you never know when you're going to want to roll back to that script you wrote a year ago. One way is to simply keep copies of everything. CVS (concurrent version system) saves considerable storage space by recording and tracking only changes, and it never forgets anything.
Not Just for Programmers
CVS is widely used to manage software development projects. It keeps a complete history of changes, and who made them. It manages the concurrent editing of files by multiple authors, and controls access. It uses a central repository, and also allows users to have their own personal repositories. It is not a build system, but a way to track and record changes.
It is quite sophisticated and complex, but don't let that scare you. We'll look at the basics of setting up and using a CVS system as a sysadmin repository for managing scripts and configuration files -- it can be very useful for saving what is left of our precious sanity.
With all the different Linux distributions and their different ways of doing things, I shall now cop out and refer you to your own documentation. There are debs, rpms, and sources, take your pick.
In these days of large hard drives, adequate space should not be an issue, just make sure to have enough. Leave room to grow, as CVS is addicting, and you'll find all kinds of uses for it.
I like to put the central repository in /var/cvs, because I keep /var in its own partition, sometimes on its own drive. My local working directory is ~/cvs. /usr/share/cvsroot is also a popular option, as well as /usr/local/cvsroot. The repository is for storage only, as users check out and edit local copies of files. If you are sharing files with others, be sure they have the correct permissions to access the repository. If other users do not need access, it's perfectly fine to create a repository in your /home directory. You still need separate locations for the central repository and the working directory. Think client-server.
The CVS root directory environment variable must be defined, in /etc/profile:
Be sure there are no spaces in the CVS root directory name, such as /cvs root. This will break everything, so use underscores instead:
Take a look in /etc/group and /etc/passwd to see if your installation script created a CVS group and user. If it didn't, do it now. Treate a CVS group:
# groupadd cvs
To create a CVS user:
# useradd -g cvs -d $CVSROOT cvs
If the CVS root directory for the repository has not been created, do it now:
# mkdir $CVSROOT
Run ls to confirm the new directory:
# ls -ld $CVSROOT
Now set group ownership and permissions:
# chgrp -R cvs $CVSROOT
# chmod o-rwx $CVSROOT
# chmod ug+rwx $CVSROOT
Finally, initialize the repository tree:
# cvs init
This also enables history logging. From here, add users as needed. Root, of course, can rampage at will, however we all know that doing things as an ordinary user, as much as possible, is wiser:
# usermod -G cvs carla