BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Big Scary Daemons

CVS Mirror


If you run CVSup on two identical servers, five minutes apart, you will have a slightly different operating system on both systems. If you're running several production machines, you'd be best served if all the systems were absolutely identical. Even if they're running a version of stable somewhere between 4.3-release and 4.4-release, being able to eliminate differing software as a potential problem can help troubleshooting immensely. You don't want to think "Gee, Server 1 keeps dying. Could it be because each server has a very slightly different version of FreeBSD?" That way lies madness.

If you have several servers to upgrade, you're going to increase the load on the CVSup mirrors. And each load will be slightly different.

CVSup includes the ability to upgrade to the code as it stood on a particular date, but even that's not a guarantee. After all, the mirror operators are human, and the mirror hardware is fallible. It would be simpler to have your own source code repository on hand.

Having your own source code repository is pretty simple, actually. It's easy to do. It will make you popular with the mirror operators -- or at least, won't make you unpopular with them, which is almost as good.

The main mirror sites update their source code repository once an hour. In many cases, I don't upgrade a local cvsup server except by hand. When I have many machines and want to upgrade them all to the exact same version of -stable, I can just upgrade them from the local repository and be sure that they're all identical. I frequently upgrade one server, put it through a few rounds of load testing, and then upgrade the rest.

Running a cvsupd server isn't an easy task, but there's help to make it simpler. The port /usr/ports/net/cvsup-mirror handles all the tricky bits of configuring a mirror.

When you install the port, cvsup-mirror asks you some questions. While there are default suggestions, you need to change many of them.

Master site for your updates []?

The default,, is reserved for official FreeBSD mirror use. Access to this system is tightly controlled by authentication keys; not just any doofus can use it. See the earlier article in this series for some hints on choosing a CVSup server.

How many hours between updates of your files [1]?

The script updates /etc/crontab to run CVSup automatically. This default is intended for public mirrors. You probably don't need to upgrade more than once a day. Remember, every connection you make just increases the load on the mirrors. Are you really going to upgrade local systems every hour?

Do you wish to mirror the main source repository [y]? 
Where would you like to put it [/home/ncvs]? /repo
Do you wish to mirror the installed World Wide Web data [y]? n
Do you wish to mirror the GNATS bug tracking database [y]? n
Do you wish to mirror the mailing list archive [y]? n

Most people just need the main source repository. If you want to mirror the whole site, including the PR database and the mailing list archives, you can answer the last three questions "y." (The mailing list archives are huge. Don't download them on a lark; this lark will peck out your eyes.) The source repository itself is about 1.3G at the moment, and grows slowly but continuously. Changes that make the size jump dramatically are referred to as "repo bloat."

Use unique user and group IDs for these. Don't use "nobody," "nonroot," or "nogroup;" these users are usually used by other processes. After all, you don't want a broken Apache server to compromise your CVSup mirror, do you?

Unique unprivileged user ID for running the client [cvsupin]? 
Unique unprivileged group ID for running the client [cvsupin]? 
Unique unprivileged user ID for running the server [cvsup]? 
Unique unprivileged group ID for running the server [cvsup]?

You can use the defaults, or use user and group names that fit your local scheme.

Maximum simultaneous client connections [8]?

The maximum simultaneous client connections is easy to change, so don't sweat it. We'll see how in the cvsupd.access file, below.

The make install process adds these usernames, sets the configuration, and generally gets you ready to go.

Installing and Upgrading Your Repository

Also in Big Scary Daemons:

Running Commercial Linux Software on FreeBSD

Building Detailed Network Reports with Netflow

Visualizing Network Traffic with Netflow and FlowScan

If you took the default during the cvsup-mirror setup, your system will upgrade its repository once an hour via cron. If not, you must run the update script /usr/local/etc/cvsup/ by hand.

The first time the update script runs, it will download and configure the entire repository. This first download takes quite a while -- in my case, two hours over a cable modem. This initial download is a great candidate for a 3AM Sunday night cron job. Updates are much quicker.

Once you're sure your repository is working, you can improve performance by adding the -s option to This turns on mirror mode. In this mode, cvsupd assumes that you have not touched any repository files by hand, and it can take some shortcuts that speed things up considerably.

Using Your New CVSup Server

This is simplicity itself. Just change the client's supfile to include

*default host=local.cvsup.server.hostname

That's it!

Pages: 1, 2

Next Pagearrow

Sponsored by: