The FreeBSD Diary |
(TM) | Providing practical examples since 1998If you buy from Amazon USA, please support us by using this link. |
Creating your own cvsupd server
17 December 2000
|
With the upcoming work I'm going to be doing on FreshPorts, I thought it best to start up a cvsup server
for the source code. This server will be used to share the data amongst the other
FreshPorts developers. This article starts that process. I first wrote about cvsupd on 6 August 1999. That article is still around, but now that I'm installing a cvsupd server for my own needs, instead of creating a mirror, I found my existing notes a bit lacking. Hence, this article. I used John Polstra's CVSUP FAQ for this exercise. Of note is the section on setting up a test server. It's what I used as the basis for this article. |
The install
|
Well, seeing as I had all the port skeletons installed, I
just had to do the following:
NOTE: in more recent versions of FreeBSD, cvsupd can be found in net/cvsup-without-gui. Yet cvsupd is started by /usr/local/etc/rc.d/cvsupd which is installed by net/cvsup-mirror cvsupd_enable="YES" in /etc/rc.conf cvsupd_flags="-c sup:/home/repositories/sup" Turn off your old cvsupd to avoid accidents. |
Setting up a test server
|
In this section, I'm going to show you the bare minimum required to get
the server running so you can talk to it from a client.
|
Start the server
|
Here's where we start the server with a very simple situation:
We have not specified a base directory. cvsupd will use the default
directory, which we also used to create our base directory. We
have not specified the -e option, which means cvsupd will run from the command
line and not go into the background. Here is what it looks like when
This method is fine for testing, but I actually run cvsupd as the nobody and ensure that everything it serves is readable by everyone. cvsupd does not create or write files, so from a security point of view, the risk of cvsupd being tricked into damaging your system is actually quite low. I start cvsupd automatically at system startup by creating
|
Setting up a test client
|
We will now set up the test client to use our test server. We are
doing this on the same box as cvsupd is running. Create the directory ~/cvs-test .
In this directory, create supfile and place the following
in it:
This is our cvsup configuration file. We have specified that we will be connecting to the cvsup server on localhost (i.e. this box) and that we will be obtaining the cvs release. From that release, we want the test collection. To run cvsup on the client and pull down the collection, issue the following command:
Here is a successful connection and cvsup:
In this case, it's brought down the files associated with my repository. |
In this example, I'm going to add a very simple collection, test2 ,
which contains only contrib/top .
This isn't really a practical example, but it might help to illustrate how the
various components of cvsup fit together.I'll create the collection directory:
In that directory, I'll specify the releases associated with this collection by
creating
This indicates that the repository actually exists at Then I create the
I can use the same supfile as in the previous example, but I change Now when I cvsup, I get this:
Compare the above list of files you can find in the CVS repository for And if I check my directory, I see this:
And if I look in top, I see the same files as are listed above. |
Adding another bit to test2
|
Now lets try another example. Let's add contrib/awk to
the test2 collection.I'll assumed you have already created the example
from the previous section. To add
Now run cvsup again. You should see this:
and your main directory should contain this:
|
Putting things in a different place
|
The supfile example contains a base specifiation of base=.
which puts everything from cvsup into the current directory. That's not the ideal
situation, but it's what we used for our testing. Now let's change that. Let's
put everything into /home/dan/mysupfiles . The first step is to modify
our supfile from the previous examples and change base to look like this:
Don't forget to create the directory before you run cvsup:
Then we cvsup again:
Now if I check my directory, I'll find this:
NOTE: If you get this error:
Then you didn't create |
This section will concentrate on restricting access to your cvsup server
by authenticating the connections. Authentication is controlled by the existence of
the file cvsupd.access which must appear in the base directory (in the example
above, the base directory is /usr/local/etc/cvsup ). If this file does not
exist, no authentication takes place.The file
mysecretkey can be any key you choose. The second line was created using cvpasswd:
The password I entered was "secret". So this is what I placed in
That should be enough to authenticate everyone. |
Access Control
|
Perhaps you don't want everyone accessing your cvsup server. I know I don't. So I've added some
rules to my packet filter to restrict access. People scanning the box can't
even tell there is a cvsup server there. But multiple layers of protection can be a good thing. That's
why I added more. If you read the man page for cvsupd, you'll see that that cvsupd.access
is your friend. I added a few rules to this file, which normally resides under
/usr/local/etc/cvsup , which permitted certain trusted host unlimited access to my server.
Using the above scenario, I didn't have to do anything special for boxes on my 10.0.0.* network
and the cvsup server could access itself. Everyone else, including my remote boxes, must
authenticate using the methods described in the previous section.
|
Secrecy
|
From man cvsupd :
I tried to get this to work, but I failed. If anyone has a practical example, please add it to the comments section. Thanks.
|
Common problems and solutions
|
If you encounter this message:
...it means the information contained in the releases file is
incorrect. In my case, I had put my data at If you encounter this message:
...it means the collection specified in your client's supfile does not exist on the
server. Once of them is wrong. In our example, it means This message:
...means that cvsupd isn't accepting connections. Make sure it's running. Make sure you are allowed to connect. Check your authentication. If you get this:
...then you have the wrong authentication information at either the client or the server. Check both and try again. |