Installation on Linux and Unix

• CVSNT works equally well on Linux and Unix installations. Here are some notes to help get started on a Unix installation. If you have questions not covered by this document, search the archives or post a message to the CVSNT email list.

Prerequisites

• CVSNT should build out of the box on most GNU compliant Unixes which run gcc and GNU autoconf. The primary development environment is Linux, and Richard Wirth looks after the Solaris port.

  At the moment AIX does not work. This is because it has is no working libtool that can produce shared libraries.

  There is a version of CVSNT in the FreeBSD Ports system, patched to build correctly on that platform.

  Gentoo users can get/compile/install CVSNT by using an ebuild as detailed at GentooEbuild.

  In addition:

  • For PAM support PAM libraries and headers must be installed.
    For Kerberos support MIT Kerberos V5 libraries and headers must be installed.
    For sserver (SSL) support OpenSSL libraries and headers must be installed.
    

Get, Configure, Make, and Install

• Get the cvsnt source from Download. Extract.

         tar -zxf cvsnt-2.0.xx.tar.gz

• Make sure you uninstall any other CVS you may have installed, e.g. assuming it was installed from an RPM:

        rpm -e cvs 

• in cvsnt-x.y.z run:

        ./configure
        make
        make install

Install from RPM's

• There are RPM's available for Redhat (and Redhat based distributions such as Fedora and CentOS).

• As above, make sure you uninstall any other CVS you may have installed from an RPM:

        rpm -e cvs 

• ungzip and untar the archive with the following command:

        tar -zxvf cvsnt-*-rpm.tar.gz

• The star is a wildcard character so that the above command will work with any version of the cvsnt RPM's you download from March-Hare.

• This will leave you with several RPM's in the current directory.

        cvsnt-2.5.03.2382-1.i386.rpm
        cvsnt-database-mysql-2.5.03.2382-1.i386.rpm
        cvsnt-database-odbc-2.5.03.2382-1.i386.rpm
        cvsnt-database-sqlite-2.5.03.2382-1.i386.rpm
        cvsnt-protocol-gserver-2.5.03.2382-1.i386.rpm
        cvsnt-protocol-sserver-2.5.03.2382-1.i386.rpm

• The first RPM is required, but you should only install the database and protocol RPM's that you plan to use.

• Use this command to install all of the RPM's:

        rpm -ivh cvsnt*.rpm

CVS Server configuration

• Copy /etc/cvsnt/PServer.example to /etc/cvsnt/PServer and customize it.

  Repository section, uncomment and revise to your actual path where you want to store the repository (this step is required).

CVS Inetd configuration

You need to set up CVS to run under xinetd, inetd, or on startup with an init script. The typical configuration is to run CVSNT using xinetd or inetd depending on the distribution.

CVS run with xinetd

• Check /etc/xinetd.d/cvs for correctness. Note especially the "server" and "server_args". Wrong information here will result in "connection actively refused" when trying to authenticate. If you're using normal inetd, not xinetd, read the section following this.

        service cvspserver
        {
                disable        = no
                socket_type    = stream
                wait           = no
                user           = root
                group          = root
                log_type       = FILE /var/log/cvspserver
                env            = 'HOME=/home/cvsroot'
                server         = /usr/local/bin/cvsnt
                server_args    = authserver
        }

CVS run with inetd

For inetd systems (e.g. Debian), simply add the following line to your /etc/inetd.conf. The account for starting cvs has to be 'root' to make PAM support work. Make sure your /etc/services knows about 'cvspserver'.

        cvspserver      stream  tcp     nowait  root     /usr/local/bin/cvsnt cvsnt authserver

Lockserver configuration

LockServer is a replacement for file based locks that eliminates some problems. LockServer reports not just that a lock exists, but also who is holding it and automatically removes stale locks. Because Lockserver is used by all CVS users and needs to persist across CVS sessions, you should run it as a daemon instead of with xinetd or inetd.

• Note: old CVS clients won't understand LockServer in local mode. Make sure you only access the CVSNT repository with a CVSNT client or through normal client-server protocols.

  Edit your startup scripts to run cvslockd on boot (DebianLockdScript here). For testing purposes it is sufficient to run cvslockd from the command line.

    $ cvslockd

• Note: The Lockserver is configured in each repository. As of CVSNT 2.0.24 (or so) it is active by default. You can configure which port to look for Lockserver on. In order to customize which port the Lockserver is listening on, change your startup scripts to use "cvslockd -p {port}".

Example Lockserver startup script: Red Hat 9

An example script to start your Lockserver at boot on Red Hat 9 is attached. To install it:

    su -
    cp cvslockd /etc/init.d/cvslockd
    chkconfig --add cvslockd
    chkconfig --list | grep cvslockd

Repository Setup

• To set up your initial repository, type:

    cvs -d :local:/path/to/new/repository  init

Permissions

To be completed

• PAM might need to be configured to allow users to access CVS on your system. If your /etc/pam.d/other configuration is set to deny access, create a file (/etc/pam.d/cvsnt) in that directory that will grant appropriate users authority.

• UNIX permissions are needed to allow the users to gain access to the CVS repository.

To be added: Detail out CVS group / user and impersonation information

Active Directory Authentication

Assuming you have already set up Samba for Active Directory authentication using the winbind daemon, you can make CVSNT do likewise by adding the file /etc/pam.d/cvsnt with the contents

#%PAM-1.0
auth    sufficient      /lib/security/pam_winbind.so
auth    required        /lib/security/pam_unix.so
account sufficient      /lib/security/pam_winbind.so
account required        /lib/security/pam_unix.so

Also ensure that you do not have System''Auth=no in your CVSROOT/config file.

You can enable SSPI server support using the ntlm_wrap program that is part of the winbind installation. Uncomment the WinbindWrapper line in your /etc/cvsnt/PServer, substituting the correct location of the ntlm_wrap program.

Test

• To confirm CVSNT is installed, use  cvs -version  and look for "Concurrent Versions System (CVSNT) 2.0.24 (client/server)" (emphasis added).

  To confirm Lockserver is running and responding,  telnet localhost 2402  and look for "CVSLock 1.2 Ready".

  Then you should be able to access it via a standard CVS client. Depending on what is loaded on your system, you should be able to use pserver, ssh (requires sshd), perhaps others.

To do: List other protocols available and how to set them up! sserver, others?

Setting up :sserver:

*** THIS IS A WORK IN PROGRESS ***

(See the script on http://lena.franken.de/linux/create_certificate.html for an easier way to do this).

First, you need to generate a certificate authority (if you have not done so already):

        /usr/lib/ssl/misc/CA.pl -newca

Press enter to let the script choose the filename. Then enter a suitable pass phrase (twice). Now you must enter at least the Country Name and the Organization Name. The other fields may be left blank.

Then, make a certificate:

        /usr/lib/ssl/misc/CA.pl -newreq-nodes

Here, you must enter at least the Country Name, the Organization Name, and the Common Name. The other fields may be left blank.

Sign the certificate:

        /usr/lib/ssl/misc/CA.pl -sign

Enter the passphrase from before, and answer 'y' twice.

Copy the first part of the generated newreq.pem (the lines from -----BEGIN RSA PRIVATE KEY----- to -----END RSA PRIVATE KEY----- inclusive) file to a new file named /etc/cvsnt/key.pem.

Copy the last part of the generated newcert.pem (the lines from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- inclusive) to a new file named /etc/cvsnt/cert.pem.

Then edit /etc/cvsnt/PServer to include the lines

        CertificateFile=/etc/cvsnt/cert.pem
        PrivateKeyFile=/etc/cvsnt/key.pem

In addition to these steps, the /etc/cvsnt/cert.pem file must be made available to the clients.

TODO: now what?

Extra facilities: gserver

Note that the gserver -> Win2000 support is not entirely stable due to a lack of developer time. If security is not an issue then Unix CVSNT can also use an SSPI (NTLM) connection to the server

CVSNT can integrate with CVSNT servers running on Windows 2000 using the gserver protocol. This allows a secure, single-sign-on mechanism (particularly effective if you set up linux workstations to authenticate against ADS using LDAP). To make this work you need CVSNT compiled with the GSSAPI / gserver protocols and Kerberos5 libraries.

First get kerberos working (some basic instructions here); you should be able to do

    $ kinit 
    Password for user@COMPANY.COM:

where COMPANY.COM is your Kerberos realm, and corresponds to your Windows 2000 ADS Domain. Test with the klist command to check you got a Ticket Granting Ticket:

    Ticket cache: FILE:/tmp/krb5cc_1234
    Default principal: user@COMPANY.COM

    Valid starting     Expires            Service principal
    08/19/03 11:25:04  08/19/03 21:25:04  krbtgt/COMPANY.COM@COMPANY.COM


    Kerberos 4 ticket cache: /tmp/tkt1234
    klist: You have no tickets cached

Then you can use a CVS root like:

    $ cvs -d :gserver:w2kserver.company.com:/repository ls
   ...
   <list of modules>
   $

Extra facilities: rcs wrappers

Standard RCS will parse most CVSNT repositories, but will throw up warnings about the new keywords used - this is normal and harmless. Use of advanced features such as binary and compressed deltas will render the file unreadable by RCS.
Note: These wrappers are available on the Win32 version of CVSNT as well

CVSNT provides wrappers for all read-only parts of the RCS process, which should be enough to use eg. ViewCVS on a CVSNT repository.

If you wish to continue using the standard RCS tools rather than the CVSNT RCS wrappers, specify --disable-rcs when running configure. You may need to modify your frontend to pass the '-q' option to RCS to suppress the warnings.