Fog Creek Software
Discussion Board




CVS Server setup in Redhat Linux 9

I'm trying to set up a CVS server on a fresh install of Redhat Linux 9, but from the FAQs I've read, I need to execute a "cvspserver" command ... that I don't have. I've looked through the CVS website and the RedHat website as well as the package management  in RedHat to try to find out how to set it up.  I realize that many things are not  a matter of "Click" and it's set up, but it seems like it's a bit much to have this much trouble setting up what's supposed to be a very common source control system. I'm thinking of just installing CVS for NT since that is easy to set up. I figured that I would at least find a FAQ that gave me a step by step for a current distribution.

--End Rant--

Alai
Sunday, April 27, 2003

Are you sure you're not missing a space there? "pserver" is a valid command to give to cvs.

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, April 27, 2003

I don't know if this information still applies to the latest version of RedHat, but the last time I did this, it went something like this:

The "classical" way to do this is to add an entry in /etc/services that tells the portnumber on which the server is going to run, and I believe that's where the "cvspserver" comes from:

cvspserver      2401/tcp

and then instruct the superserver to start up the CVS program when someone contact this port, by adding the following line in /etc/inetd.conf (all on one line)

cvspserver  stream  tcp  nowait  <<cvsdaemon>>  /usr/bin/cvs --allow-root=<<dir>> pserver

where <<cvsdeamon>> is the user account under which the CVS server should run, and <<dir>> is the "home" directory of this user.

Under newer versions of RedHat, I think that the superserver has been replaced with a new version that has better firewall capabilities and that it should rather be set up with the following entry in a file called /etc/xinetd.d/cvs

service cvs {
  flags = REUSE
  socket_type = stream
  wait = no
  port = 2401
  user = <<cvs-daemon>>
  group = <<group>>
  server = /usr/bin/cvs
  # following setting on one line, not two
  server_args = --allow-root=<<dir>> -b /usr/bin pserver
  only_from = 192.168.0.0/16
  disable = no
}

note that here a user <<group>> must be specified in addition to the two other parameters mentioned above and that there is a restriction on the hosts that are allowed to contact the server, and the mask must be edited accordingly.

However, you should rather consider to connect to the server with SSH instead of pserver, IMHO.

Roland Kaufmann
Sunday, April 27, 2003

One more thing; you will have to "hup" the superserver before the changes in the files take effect, using

pkill -HUP xinetd

I assume that you have already initialized the CVS repository in the "home" directory?

Roland Kaufmann
Sunday, April 27, 2003

Place this in a file named /etc/xinetd.d/cvspserver

service cvspserver
{
#        disable = yes
  socket_type = stream
  protocol    = tcp
  wait        = no
  user        = root
  passenv    = PATH
  server      = /usr/bin/cvs
  server_args = -f --allow-root=/usr/local/cvsroot pserver
}

Change /usr/local/cvsroot to the base directory of your cvs repository.

Then as root type 'service xinetd restart', and your CVS server will be ready.

Giovanni Corriga
Sunday, April 27, 2003

Warning: my solution is a nightmare from a security standpoint, but it's good enought to give you a working CVS server.
Take a look at the Cederqvist  http://www.cvshome.org/docs/manual/cvs.html to learn how to secure your CVS server.

Giovanni Corriga
Sunday, April 27, 2003

You might also look into just allowing ssh access to the machine. Then you'd just setup the repository normally and forget it! Clients access it using the :ext: protocol:

cvs -d :ext:foo@cvs.mycompany.com:/path/to/repository

It's cake to access from another unix machine, and recent Win32 CVS clients (like Tortoise CVS) make this easy on those platforms as well.

Pros: No extra ports open to the outside world; it's one fewer thing to admin; everything is encrypted by default

Cons: Some dev tools with a built-in CVS client don't do ssh well (this is changing); you need to give every developer an account on the machine

Chris Winters
Monday, April 28, 2003

Alternatively, use pserver over an SSH tunnel,
so that the server appears to be on localhost.
Then all tools will work.

Richard Rodger
Tuesday, April 29, 2003

*  Recent Topics

*  Fog Creek Home