[contents]

[printable version]

[back to main page]

Central CVS Service
- HOW TO


Contents

  1. Creating a new project
    1. Preface
    2. Requesting a creation of a new project -obsolete-
    3. Warning
  2. Accessing a project
    1. Web interfaces
    2. Access using CVS clients
    3. Kerberos authentication from outside CERN
    4. Access for Windows users (WinCVS)
    5. Access for Windows users (TortoiseCVS)
    6. Configuring SSH access from Windows
    7. Configuring SSH access from Linux/Unix
    8. Troubleshooting
    9. Using WinMerge
    10. Moving out of kserver access method
  3. Administrating the project
    1. Granting write access to CVS
    2. Setting access to web interfaces
    3. Automatic lock detection/removal
    4. E-mails sent after each commit/tag
    5. Granting (and removing) anonymous access
    6. Generating passwords for pserver authentication
    7. Accessing a repository on a file-system level
    8. Changing the password of the Librarian account
    9. Changing the librarian
    10. Keeping a mirrored copy of your repository
    11. Disk quota
    12. Statistics of usage
    13. Remove history of a file
  4. Known issues
    1. Deprecation warnings
    2. Slow CVS Gserver access: identd daemon
    3. Patch to Eclipse
    4. CVS and secrets/passwords
    5. Connection refused
    6. CVS clients
  5. Help and support
Author of this documentation: Sebastian Lopienski
Please send all remarks to CVS.Support@cern.ch - thank you.


  1. Creating a new project
    1. Preface
    2. The Central CVS Service is accessible only for registered AFS/PLUS users. If you don't have a PLUS account, please contact your group administrator to request such an account. For any additional information about account creation, please write to Helpdesk@cern.ch. Additionally, CVS users must be granted access to CVS repositories of different projects by contacting the responsible librarian (see list) of each project.

    3. Requesting a creation of a new project -obsolete in CVS-
    4. A newer version control system, Subversion (also known as SVN), is available at CERN: CERN Central SVN Service. This new service replaces now CVS.

      Creation of new CVS projects (repositories) is discontinued and software librarians are requested to request SVN projects instead by filling this form.

      For more information on SVN Project creation the corresponding paragraph in the SVN service web documentation.

    5. Warning
    6. By default, files in a repository are visible for everyone at CERN via web interfaces, but anonymous pserver access is disabled. If your files contain (or will contain) any classified information (like hardcoded passwords etc.), you should take special care when setting access rights. If you want to restrict or disable Web access to your repository, please send a request to CVS.Support@cern.ch. On the other hand, if you decide to enable anonymous access, please follow the instructions.

  2. Accessing a project
  3. A project hosted in the Central CVS Service can be accessed in many ways: using CVS clients on Linux/Unix systems or Windows platform, or via read-only web interfaces. For all recommended, secure read-write access methods, one has to have a PLUS account at CERN. If you don't have one, please contact your group administrator to request such an account. For any additional information about account creation, please write to Helpdesk@cern.ch.

    1. Web interfaces
    2. Web interfaces provided by the CVS Service allow a read-only access to repository files (both current and previous versions) with a standard web browser. One can browse thru a repository, make diff between any two versions of a given file, download a tar-ball of a subtree (CVSWeb only) etc.

      For example, for a project called ui:

      Please note that some projects are not visible outside CERN, or not visible at all - depending on librarian's decision (details).

    3. Access using CVS clients
    4. There are three supported access methods for CVS clients:

      N.B. Following CERN's IT Department computing decision of stopping Kerberos IV infrastructure, kserver access will be discontinued as from Feb 2nd 2009

      1. SSH Access method
      2. SSH authorization (see configuration advice for Windows and Linux/Unix):

                CVSROOT=:ext:isscvs.cern.ch:/local/reps/PROJECT
                CVS_RSH=ssh
        
      3. Kerberos V Access method
      4. In order to access a project using Kerberos V authorization, one needs to define the following environment variable (change PROJECT by your short project name):

                CVSROOT=:gserver:isscvs.cern.ch:/local/reps/PROJECT
        

        If you do not have a valid kerberos V ticket, issue the command (change username by your username):

                 kinit username@CERN.CH
        

        N.B. KERBEROS V ACCESS IS CURRENTLY ONLY SUPPORTED ON CVS CLIENTS INCLUDING PATCH http://savannah.nongnu.org/bugs/?18830. THIS IS THE CASE FOR MOST LINUX SLC4 AND SLC5 CVS CLIENTS

        You can check your CVS client version on RPM based Linux systems by issuing the command:
        	rpm -qf /usr/bin/cvs
        If the "cern" string does not appear within the RPM package name, then your CVS client is not patched. RPM's for patched CVS clients can be found:

        For SLC4 64-bits at URL http://swrepsrv.cern.ch/swrep/x86_64_slc4/
        For SLC4 32-bits at URL http://swrepsrv.cern.ch/swrep/i386_slc4/
        For SLC5 64-bits at URL http://swrepsrv.cern.ch/swrep/x86_64_slc5/
        For SLC5 32-bits at URL http://swrepsrv.cern.ch/swrep/i386_slc5/
      5. Pserver (anonymous) Access method
      6. Anonymous read-only access (if it's enabled by the librarian, see details):

                CVSROOT=:pserver:anonymous@isscvs.cern.ch:/local/reps/PROJECT
        

        CVS server listens on default ports for gserver and also for pserver (2401).

        Make sure that you don't add a slash / at the end of the path /local/reps/PROJECT.

      The CVS client distributed with all supported Unix/Linux platforms at CERN is good enough to access the CERN Central CVS Service.

    5. Kerberos authentication from outside CERN
    6. In order to access CVS Service from outside CERN with Kerberos V authentication, do the following: If you experience any problems, you can try to:

      An example of getting a CERN Kerberos ticket:

      $  /usr/kerberos/bin/kinit manent@CERN.CH
      Password for manent@CERN.CH:
      
      $ /usr/kerberos/bin/klist
      Ticket cache: FILE:/tmp/krb5cc_4626_fHMXM18623
      Default principal: manent@CERN.CH
      
      Valid starting     Expires            Service principal
      11/27/08 10:48:02  11/28/08 10:47:56  krbtgt/CERN.CH@CERN.CH
      
      You can use aklog command which give AFS tokens as in the example below:
      aklog
      klist
      $ Ticket cache: FILE:/tmp/krb5cc_4626_FSSkE11269
      Default principal: manent@CERN.CH
      
      Valid starting     Expires            Service principal
      11/27/08 10:51:52  11/28/08 11:05:33  krbtgt/CERN.CH@CERN.CH
      	renew until 12/02/08 10:09:36
      11/27/08 10:52:01  11/28/08 11:05:33  afs@CERN.CH
      	renew until 12/02/08 10:09:36
      
      

    7. Access for Windows users (WinCVS)
    8. For Windows platform, there is no centrally distributed and supported CVS client. A working CVS Windows client recommended by the CVS Service team is called WinCVS. CVS clients are also build-in to several development tools including JDeveloper, JBuilder and NetBeans.

      Before installing WinCVS, it is advisable to configure an SSH connection as described in Configuring SSH access from Windows point. The following are the instructions on how to install and configure WinCVS version 2.0.

      1) Download the latest stable version of WinCVS from http://cvsgui.sourceforge.net/download.html#wincvs_recommended.

      2) Install the software using unzip command and run wincvs_setup.exe file (It'll also run CVSNT installer after completion). After extracted all files to a temporary directory as preconised by WinCVS, run again wincvs_setup then choose defaults (click on Next, OK or Yes buttons) when prompted during the installation process. WinCVS will be installed on C:\Program Files\GNU\WinCVS 2.0.
      Install CVSNT (required to execute CVS commands). Choose always defaults when prompted during the installation process and it will be created at: C:\Program Files\cvsnt.

      3) Download this batch file (right-click on the link, and choose Save Link as...), and save it as ssh2.bat in C:\Program Files\cvsnt directory (or any other that is in the %PATH%).

      4) Go to Programs -> WinCVS and run WinCVS.

      5) You can start by checking out an existing module from your CVS repository: Go to menu Remote -> Checkout module... In the Checkout settings tab, set the following values:

      See Using WinMerge point for information about this external diff tool and configuring it with WinCVS.

    9. Access for Windows users (TortoiseCVS)
    10. There is another Windows tool to access CVS: TortoiseCVS. It is more lightweight than WinCVS, and although it offers less functionality, it may be more intuitive for most users. It integrates directly with Windows Explorer and provides a right-click context menu for CVS files and modules. TortoiseCVS web page address is http://www.tortoisecvs.org, and a stable version can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=48103. Before installing TortoiseCVS, it is advisable to configure an SSH connection as described in Configuring SSH access from Windows point.

      When you have TortoiseCVS already installed and SSH connection configured, you can start using it. Go to a directory (or create one) where you want to check-out a CVS module to. Right-click on the directory's name and choose CVS Checkout.... Set CVSROOT to your project (as described in Access using CVS clients point), adding <your_account_name>@ before the server name. For user jbond and project ui the CVSROOT should be:

      	     :ext:jbond@isscvs.cern.ch:/local/reps/ui
      
      In case you use SSH Protocol: (Secure shell [:ssh:]) set the following values:

      Later, type in a module's name (or choose it from the list by clicking Fetch list..., if the list is available). After you click OK, the contents of the chosen module should be checked-out from CVS server. If you have enough privileges, you can try checking out the CVSROOT directory (it always exists).

      See Using WinMerge point for information about this external diff tool and configuring it with TortoiseCVS.

    11. Configuring SSH access from Windows
    12. Accessing CVS repositories from Windows using SSH authentication requires defining the variables mentioned before (CVSROOT and CVS_RSH). But in most cases it is necessary to install and configure an SSH client first.
      SSH2 protocol now is used for authentication (SSH-2 will be the default protocol at Cern in May 2007), but SSH1 will still work for a while. Follow the steps below in order to configure your Windows machine to access CVS servers without typing a password every time:

      1. If it was not already done, please install the PUTTY application via the "Control Panel - Add\Remove Programs - Add New Programs". We use PUTTY version 0.58 or 0.60 as well and future version according to NICE standard.

      2. Once it's done, please run the C:\Program Files\PuTTY\puttygen.exe application.
        Select SSH-2 RSA as "Type of key to generate", give 2048 as "Number of bits in a generated key" field, then generate private and public keys and save them on the disk (for example two files my_rsakey.ppk and my_rsakey.pub, respectively).

      3. Run /afs/cern.ch/project/cvs/dist/bin/set_ssh in LXPLUS in your AFS account in order to create links.

      4. At this time, 2 modifications must be added in my_rsakey.pub file to get a correct format.
        - Firstly you must add "ssh-rsa" text ahead of the key like:
        ---- BEGIN SSH2 PUBLIC KEY ----
        Comment: "rsa-key-20070416"
        AAAAB3NzaC1yc2EAAAABJ.....
        
        will become EXACTLY IN THE SAME FORMAT AS BELOW:
        
        ---- BEGIN SSH2 PUBLIC KEY ----
        Comment: "rsa-key-20070416"
        ssh-rsa AAAAB3NzaC1yc2E....
        - Secondly please edit this file so that the key is placed in a single line (remove the Carriage Returns). Put the public key (content of my_rsakey.pub) to your ~/.ssh/authorized_keys file, for example with the following command:
        $ echo "your public key in one line..." >> ~/.ssh/authorized_keys
        
      5. Check access permissions to ~/.ssh and ~/public, they shouldn't be more "open" that drwxr-xr-x:
        $ ls -ld ~/.ssh ~/public
        
        If necessary, correct them with this command:
        $ chmod 755 ~/.ssh ~/public ~/.ssh/authorized_keys
        
      6. From Windows run the C:\Program Files\PuTTY\pageant.exe command. It will install an icon in your system tray (right-bottom corner of the screen). Right-click on it, choose Add Key menu item from the popup menu and select the file with your private key that you've saved before (my_rsakey.ppk). You may later verify if your key was taken in account by choosing the View Keys menu item.

        pageant.exe has to be executed after each login to Windows, and the key added each time pageant is started. This can be automated as follows:

        - In Control Panel->Scheduled tasks->Add Scheduled Task->Browse to
        C:\Program Files\PuTTY\pageant.exe
        - Select "When I logon" bullet, click next
        - Username CERN\yourNICEUsername and password, click next
        - Tick "open advanced properties", click Finish
        - in "Run" field, add the dfs path to your private key file, e.g.:
          "C:\Program Files\PuTTY\pageant.exe"
        \\cern.ch\dfs\users\n\niceuser\private\my_rsakey.ppk
        
      7. From Start->Run... menu run command:
        C:\Program Files\PuTTY\putty
        Create a Session called isscvs.cern.ch to <your_account>@isscvs.cern.ch. For that session, in Category->Connection->SSH->Auth select SSH-2 as Authentication method. In Category->Connection->SSH select Preferred SSH protocol version 2.In Category->Connection->SSH->X11 Disable X11 Forwarding Go back to
        Category->Session
        and save the isscvs.cern.ch you have just created and closed the PuTTY Configuration window.

        P.S.: The hostname given to plink must correspond exactly to the name of the saved PuTTy session where the ssh2 protocol is defined


      8. From Start->Run... menu run command:
        "C:\Program Files\PuTTY\putty" <your_account>@isscvs.cern.ch
        accept the server key (press Yes only, if the fingerprint is 05:1c:53:5c:2b:cc:70:5f:75:0b:b7:f6:19:fe:f8:8e!). You shouldn't be prompted for a password. You will just see a warning message and the session will automatically close since login is not allowed in CVS servers.

      See also: QA 3578 for more info.
      Troubleshooting:
      If SSH still asks you for your password, make sure that you followed all the instructions correctly, possibly try following them again. If it still fails, please report it to CVS.Support@cern.ch, sending also the output of this command:

        "C:\Program Files\PuTTY\plink" -v USERNAME@isscvs.cern.ch
      
      (use Start->Run..., open "command.com" and then type the command above. To copy the output, right-click on the window, select "mark", mark the desired text and copy it to clipboard by pressing Enter. Then paste it to your e-mail client).

    13. Configuring SSH access from Linux/Unix
    14. SSH2 protocol now is used for authentication, but SSH1 will still work for a while. If you want to access the Central CVS Service using SSH from your Linux/Unix machine without providing password each time, follow these instructions:

      1. Log on to your Linux/Unix machine
      2. If you already have your RSA2 key generated (most probably ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub files), go to point 3.
        Otherwise, generate the key, saving it in the default location. N.B. Please make sure that you use a passprashe to protect your private key. The passphrase can be changed later by using the -p option at the ssh-keygen command.
        If, nevertheless, you decide to generate your key without passphrase, please MAKE SURE THAT THE AFS ACL OF ~/.ssh/id_rsa (fs la ~/.ssh/id_rsa) ONLY ALLOWS YOU TO READ YOUR PRIVATE KEY (see also "AUTHORIZED_KEYS FILE FORMAT" of sshd man page):
        mkdir -p ~/.ssh
        ssh-keygen
        Generating public/private rsa key pair.
        Enter file in which to save the key (/afs/cern.ch/user/u/uimon/.ssh/id_rsa):
        Enter passphrase: YOURPASSPHRASE
        Enter same passphrase again: YOURPASSPHRASE
        Your identification has been saved in /afs/cern.ch/user/u/uimon/.ssh/id_rsa.
        Your public key has been saved in /afs/cern.ch/user/u/uimon/.ssh/id_rsa.pub.
        
      3. Copy the public key (~/.ssh/id_rsa.pub) to your AFS home directory at CERN
        scp ~/.ssh/id_rsa.pub USERNAME@lxplus.cern.ch:~
        
      4. Log on to LXPLUS and run
        /afs/cern.ch/project/cvs/dist/bin/set_ssh
        
      5. Add the PUBLIC key you copied in 3. in your ~/.ssh/authorized_keys file with the following command:
        $ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
        
      6. Check and modify if necessary the format of your authorized_keys file EXACTLY IN THE SAME FORMAT AS BELOW:
        ---- BEGIN SSH2 PUBLIC KEY ----
        Comment: "rsa-key-20070416"
        ssh-rsa AAAAB3NzaC1yc2E....
        - Secondly please edit this file so that the key is placed in a single line (remove the Carriage Returns).

      7. Check access permissions to ~/.ssh and ~/public, they shouldn't be more "open" that drwxr-xr-x:
        $ ls -ld ~/.ssh ~/public
        
        If necessary, correct them with this command:
        $ chmod 755 ~/.ssh ~/public ~/.ssh/authorized_keys
        
      8. When logged at your Linux/Unix machine, if you have set a key passphrase, use ssh-agent to avoid having to type your passphrase everytime you call cvs. For that just call the following commands in your Linux/Unix machine:
        % eval `ssh-agent`
        % ssh-add ~/.ssh/id_rsa
        % ssh-add -l
        
        If all goes well, the last command should list the key you've added to the key agent, and your SSH commands in this shell have access to your key without further intervention from you. Then try connecting to isscvs.cern.ch
        ssh USERNAME@isscvs.cern.ch
        
        and accept the server key (only, if the fingerprint is 05:1c:53:5c:2b:cc:70:5f:75:0b:b7:f6:19:fe:f8:8e!). You shouldn't be prompted for a password, and you should see the message:
        *******************************************************************************
        *                                                                             *
        * http://cern.ch/ComputingRules : Govern the use of CERN computing facilities *
        *                                                                             *
        *******************************************************************************
        CVS server - wrong number of arguments, interactive login disabled
        Connection to isscvs closed.
        
        which means that ssh access to CVS servers is properly configured.

      As you probably realized, when you login on LXPLUS without providing your password, you don't have AFS and Kerberos tokens. In order to be asked for the password while connecting to LXPLUS and not to be asked for it for CVS connections, create ~/.ssh/config file on your Linux/Unix machine, and put the following contents in it:

      Host lxplus.cern.ch lxplus
      Protocol 2
      PubkeyAuthentication no
      PasswordAuthentication yes
      
      Host isscvs.cern.ch isscvs
      Protocol 2
      ForwardX11 no
      IdentityFile ~/.ssh/id_rsa
      

      Now try the two commands:

      ssh USERNAME@lxplus.cern.ch
      ssh USERNAME@isscvs.cern.ch
      
      The first call to ssh will prompt for a password, while the second one won't (which was the purpose).

      (Thank you to Louis Poncet (IT/GD) for the idea of the config file.)

    15. Troubleshooting
    16. If SSH still asks you for your password, make sure that you followed all the instructions correctly, possibly try following them again. If it still fails, please report it to CVS.Support@cern.ch, sending also the output of this command:
      ssh -vvv USERNAME@isscvs.cern.ch
      
      Regardless of the problem you may have using your cvs client, please always send us the output of the failing command adding the "-t" option. For example if the failing command for you is:
      cvs update .
      
      ..then send us the output of:
      cvs -t update .
      

    17. Using WinMerge
    18. WinMerge is a visual text file differencing and merging tool for Windows platforms. It is useful for determining what has changed between project versions, and then merging changes between versions. Although this tools is not officially supported by CVS Service, it might be found useful for CVS users. You can download WinMerge from SourceForge. Make sure that the version you download is not older that 2.0, even if it is a Beta version or a Release Candidate (older versions have some problems with comparing files on network drives). Install it (run the exe file).

      Configuring with WinCVS

      Here is how to configure WinMerge to work with WinCVS (see first information on how to install and run WinCVS).

      1) Go to Programs->WinCVS and run WinCVS.

      2) In WinCVS go to Admin->Preferences menu and choose WinCVS tab. Mark the External diff program checkbox and put C:\Program Files\WinMerge20\WinMerge.exe (or another location of WinMerge .exe file on your PC, depending of the version of WinMerge) into a path field.

      3) In order to see and merge the differences between files, right-click on a file in WinCVS, choose Diff selection, mark the Use the external diff checkbox and click OK. Remember that the file on the left in WinMerge is just a temporary copy of the file in CVS. Modify the file on the right, save it and then commit the changes using WinCVS.

      Configuring with TortoiseCVS

      In order to use WinMerge from TortoiseCVS, you need to do the following:

      1) Go to Programs->TortoiseCVS and run Preferences.

      2) In the Main tab, put C:\Program Files\WinMerge20\WinMerge.exe (or another location of WinMerge .exe file on your PC, depending of the version of WinMerge) into External diff application field.

      3) In order to see and merge the differences between files, open Windows Explorer, go to a working copy, right-click on a modified file (marked in red) and choose CVS Diff.... TortoiseCVS will take a version from the server and send it along with the working version to WinMerge. Remember that the file on the left in WinMerge is just a temporary copy of the file in CVS. Modify the file on the right, save it and then commit the changes using WinCVS.

    19. Moving out of kserver access method
    20. CVS users using kserver method are encouraged to move to SSH or gserver supported access methods. These two access methods are documented in this web page.

      To convert your CVS sandox (i.e. the directory where you checkout and modify your CVS source code files) you can use one of the following options:

      The above-mentioned scripts will modify the sandbox located in your current working directory, so that the execution of any CVS transaction within your sandbox will use a supported CVS access method.

  4. Administrating the project
    1. Granting write access to CVS
    2. In principle, a person who should do an administrative work on a given project is its librarian, and not the CVS team providing the Service. A librarian account (i.e. ui for ui project) is created during the creation of a project (see a list of repositories and its librarians). Librarian is allowed to modify everything in his/her project, including the configuration files in CVSROOT directory.

      If you (the librarian or another person having write access to the CVSROOT directory) want to give write access to a given user, you will need to check-out, modify and commit the following files:

      First, put user's login name into CVSROOT/writers file (one name per line). Username must have NO WHITE SPACE before or after. Don't forget to put a new line after the last user. If this file exists and a user is not listed in it, he has read-only access. If you want to learn more about writers and readers files, have a look here.

      Next, you need to add user's name to CVSROOT/commitavail and CVSROOT/tagavail files (following the comments on those 2 files). You can list users who should have access rights for each module (or even directory) separately. To have a basic idea of the syntax used in this files, have a look at the following example of commitavail file:

      # By default nobody can commit anything
      
      unavail
      
      # Let's give access to everywhere to cvsadmin and librarian
      
      avail | cvsadmin yourlibrarian
      
      # For each module or directory we give write access to its developers:
      
      # dev1 and dev2 can write everywhere in ade and subdirectories,
      # dev3 only in ade/adeswitching and subdirectories
      
      avail | dev1 dev2 | ade
      avail | dev3 | ade/adeswitching
      
      # dev2 shouldn't write to ade/timingeditor, but he still can write
      # to ade and other subdirectories
      
      unavail | dev2 | ade/timingeditor
      
      # finally, dev4 can write to all modules except ade and
      # CVSROOT (where configuration files are kept)
      
      avail | dev4
      unavail | dev4 | ade CVSROOT
      

      This file is processes in top-bottom order, so the last line matters most! You can have your own tags by adding them to "avail" and "unavail" commands after a dot. Anything that is after "avail." or "unavail.", is omitted by the parser. An example:

      avail.admins | cvsadmin yourlibrarian
      unavail.yourtag | james | myprivatemodule
      

    3. Setting access to web interfaces
    4. A librarian can decide whether his repository should be accessible via CVS web interfaces (currently CVSWeb and ViewCVS) and to whom. There are three possibilities: a repository can be visible to everyone (Public access), it can be visible for users from CERN domains only (Restricted), or it can be not visible on the web at all (None). The default access is Restricted. The following IP masks are considered to cover all CERN subnets (thus define all CERN domains for Restricted access):

      In order to see or change a current setting, librarian should use special CVS web tools site.

    5. Automatic lock detection/removal
    6. Sometime CVS leaves locks in the repository (to learn about CVS locks, read point 2.2.6 and 10.5 in the Cederqvist). Central CVS Service offers the functionality to deal with them. When locks older than 10 minutes are detected, they are reported by e-mail to the librarian of a given project. Locks older than one hour can be automatically removed, if the librarian wishes so. By default, locks are NOT removed - if you (the librarian) want to change it, use the webtool.

    7. E-mails sent after each commit/tag
    8. If you want to have an e-mail sent to the librarian or to all developers after each commit or tag, follow these instructions:

    9. Granting (and removing) anonymous access
    10. By default anonymous access to a newly created repository is disabled. It is within librarian responsibility to decide if he wants to grant read-only anonymous access to his repository. Please note that anonymous access means that everyone can download all the files (source codes of a project, configuration files from CVSROOT). In order to turn it on, one should:

      1) Put a line containing anonymous into CVSROOT/readers file. Don't forget to put a new line after the last line,

      2) Put a line containing anonymous: into CVSROOT/passwd file. (Note that there is a colon after anonymous),

      3) Make sure that user anonymous is not listed in CVSROOT/writers file.

      Now commit your changes to CVS and then you can access CVS anonymously via pserver authentication, with the following CVSROOT:

              CVSROOT=:pserver:anonymous@isscvs.cern.ch:/local/reps/PROJECT

      To stop anonymous access, simply remove lines containing anonymous from both CVSROOT/readers and CVSROOT/passwd and commit those files in CVS.

      N.B.: You must wait one hour that cvspserver configuration will be take into account.

    11. Generating passwords for pserver authentication
    12. Use this form to generate passwords for CVSROOT/passwd file (pserver authentication):

      Password:

      Please note that using pserver authentication is strongly discouraged for security reasons (password are sent over the network in open text). Use Kerberos V or SSH authentication instead!

    13. Accessing a repository on a file-system level
    14. Sometimes you want access to your repository on a file-system level. You may want to completely remove some files or directories from a repository (without leaving any history or trace that they ever existed). You may also want to migrate your existing repository from different location. A repository hosted in the CERN Central CVS Service is available via AFS, at /afs/cern.ch/project/cvs/reps/PROJECT_NAME. Only a librarian of a project has a file access to it, so you will need to log in on your librarian's account (i.e. to an LXPLUS machine).

      Note that if you want to remove the whole project, you have to contact CVS Service (send an e-mail to CVS.Support@cern.ch)

    15. Changing the Librarian's account password
    16. The first time, the password of CVS Librarian's account of a repository is avaliable for 5 days and must be changed before.
      In case this password has been lost, the Librarian can ask to change it by sending a mail to User.Registration@cern.ch.

    17. Changing the librarian
    18. Sometimes the person responsible for a given CVS repository (aka. librarian) changes. The new librarian will be still using the same librarian account (usually cvsproject_name). To change the person responsible for a CVS project, former librarian should:

      Change of librarian implies also some modification in CVS Service configuration files. To request it, the former librarian should send a message to CVS.Support@cern.ch, naming the person who will become the new librarian.

    19. Keeping a mirrored copy of your repository
    20. It is possible to keep a mirrored copy of a given CVS repository. This may be interesting for big CVS projects with complex Software Building process which may take place outside of CERN site. By using a mirrored copy of a repository, the Software Building processes becomes less sensitive to, for example, network outages.
      This service is implemented using CVSup.

      CVS librarians should request this service directly to CVS.Support@cern.ch.

    21. Disk quota
    22. CVS repositories are hosted on AFS. The initial disk quota for a repository is 50MB. This quota will be automatically increased as the project grows. If you plan to migrate already existing modules of big size to this project, please send an e-mail to CVS.Support@cern.ch requesting additional disk quota.

    23. Statistics of usage
    24. Statistics of usage of a CVS repository are available for its librarian. The URL is:
      https://twiki.cern.ch/cvs-admin/stats/stats.php
      To go to a specific project, use this URL:
      https://twiki.cern.ch/cvs-admin/stats/stats.php?project=project

      Statistics are based on commits only. All commits ever done in a repository are counted. They are generated every night, so they don't include commits from the current day.

      Librarian should log in using his librarian's account (usually cvsproject), or his own AFS account, and authenticate with the AFS password. If a librarian of a given project want to give access to its statistics to another user, he should request so at CVS.Support@cern.ch (providing the user's login name).

    25. Remove history of a file
    26. For example for a file in elfms called: quattor/lsfweb/last-tests.log
      ...
      cvs co quattor/lsfweb/last-tests.log
      cd quattor/lsfweb/
      mv last-tests.log last-tests.log.temp
      cvs remove last-tests.log
      cvs ci -m"removing last-tests.log"
      mv last-tests.log.temp last-tests.log
      cvs add last-tests.log
      cvs ci -m"adding last-tests.log back"
      
      ...if this is an operation you do to remove some hard-coded password, then:
      
      cvs co quattor/lsfweb/last-tests.log
      mv quattor/lsfweb/last-tests.log /tmp
      
      (as librarian: cd /afs/cern.ch/project/cvs/reps/elfms/quattor/lsfweb; rm -rf last-tests.log,v)
      
      cd quattor/lsfweb
      cvs update .
      mv /tmp/last-tests.log .
      cvs add last-tests.log
      cvs ci -m"adding last-tests.log back"
      
      ...but then you'll loose all history anything making a reference to a privious version (or tag) of last-tests.log will break
      

  5. Known issues
    1. Deprecation warnings
    2. CVS server software on Friday, May 28th, 2004 to a newer, secure version 1.12.8. As one of the outcomes of the upgrade, CVS started to produce deprecation warnings on commits (and possibly other operations) like these ones:
      cvs commit: warning: commitinfo line contains no format strings:
      Appending defaults (" %r/%p %s"), but please be aware that
      this usage is deprecated.
      They didn't stop the operation itself to execute, but might have confused users, or scripts expecting a clean output of a cvs command. The warnings are caused by a modification of the way that CVS server parses commitinfo, editinfo, verifymsg, loginfo and taginfo files from the CVSROOT directory. To correct them, please follow the instructions described at http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_18.html#SEC188. Please note the following:

    3. Slow CVS gserver access: identd daemon
    4. Users accessing the CVS service from outside CERN via gserver method, may experience very slow access. This is linked with the identd (identification protocol) daemon. The central CVS server attempts to establish client identity before proceeding with the connection. If the client machine does not run identd, a TCP reset is normally returned and everything is fine. If the client runs identd and firewalls port 113 with REJECT or DENY, then the CVS user is likely to experience inconvenient delays.

      Our recommendation is therefore not to run identd (which is pointless and potentially dangerous). If there is a need for running identd, pick an up-to-date one with a good reputation and do not firewall port 113.

      If there is a need to know CVS server IP addresses, use the command
      CDBHosts -c cvs
      in lxadm. To know the Ip of the single CMSSW server, use
      host CMSSW.cvs.cern.ch
      An easier workaround to this performance problem is to use the CVS SSH access method instead (see details).

    5. Patch to Eclipse
    6. Eclipse (https://www.eclipse.org/) users are advised to integrate patch:

      https://bugs.eclipse.org/bugs/show_bug.cgi?id=82483

      into the Eclipse CVS plugin, so that it can parse the new date format coming from CERN CVS server. This patch is quite small and only affects the cvs plugin. It should only be applied to versions 3.0.1 or 3.0.2. It can be downloaded here (zip file). This zip file has to be unzipped into the Eclipse installation directory.

      This patch may be included in future Eclipse versions (greater or equal to 3.0.3).

      Andrew Branson should be thanked for providing this piece of information as well as this patch (problems with it should also be reported to him).

      Once more, it must be pointed out that, due to resource limitations, the CERN CVS service does not provide support for ANY CVS client (which includes also Eclipse). Eclipse users are encouraged to have a look to http://help.eclipse.org where they may find solutions to most of their Eclipse setup configuration problems. For Eclipse, CVS Ext Connection Method is the recommended access method in all platforms at CERN.

    7. CVS and secrets/passwords
    8. Because of the open-source idea behind CVS itself, CVS does not provide any mechanisms to control read access. Repositories in the CERN Central CVS Service are therefore readable to anyone with an LXPLUS account at CERN.

      Having that in mind, developers who keep their source code in CVS should make sure that no secret information like decryption keys, passwords etc. is put into CVS. Unfortunately, such secret data is quite often hardcoded in the source code that is later being put into CVS. This is usually considered as a bad software development practice. Please read How to keep secrets secret for more information and suggestions on alternatives to hardcoding passwords.

      If you detect that some files in your repository contain hard-coded passwords or other confidential information, you should follow at least these steps:

      1. change the password to a new one in each system (database, account etc.) that used the exposed password
      2. make sure that the new password doesn't get committed into CVS - for example: restructure your code by moving passwords/secrets to a separate file (that will NOT be kept in CVS)

      Librarians of the CVS repositories are also reminded that they should decide whether Web interfaces (ViewCVS/CVSWeb) to their project files are either accessible to everyone; or restricted to CERN only; or disabled completely (more details).

    9. Connection refused
    10. When getting "Connection refused" errors on CVS operations such as the following:
      % cvs update
       connect to address 137.138.251.224: Connection refused
       Trying 137.138.251.254...
       connect to address 137.138.251.224: Connection refused
       Trying 137.138.251.254...
       connect to address 137.138.251.224: Connection refused
       Trying 137.138.251.254...
       connect to address 137.138.251.224: Connection refused
       Trying 137.138.251.254...
       connect to address 137.138.251.224: Connection refused
       Trying 137.138.251.254...
       cvs [update aborted]: received interrupt signal
       %
      

      This means that the environment variable CVS_RSH must be set to "ssh". If CVS_RSH is not set, CVS clients try an "rsh" connection, which is refused for security reasons.

    11. CVS client problems
    12. Please note (as mentioned above) that we cannot support cvs clients in general, but we have tried to make sure that cvs works properly on the load-balanced cvs cluster from the standard CERN systems like lxbatch and lxplus. This is the case for Linux SLC4 and SLC5. For SLC6 a fix is expected from Redhat which should be available before it goes into production.

      Some of the problems with other cvs clients are mentioned below:

  6. Help and support
  7. The responsible librarian of each project should be taking care of:

    Report the problem providing the output of the comand "cvs -t co ...". The -t cvs option may help debugging the problem.

    All problems encountered in the central CVS service should be reported to CVS.Support@cern.ch

    Here is the list of repositories ordered by shortname. It shows the librarian responsible for each project and the access (W=world, open to any one, C=CERN, open to CERN users, R=restricted, restricted to specified set of CERN users) and the contact address list. Remove NOSPAM_ from e-mail addresses!):

    Long Name Shortname Librarian Email Contact

    Don't forget to remove NOSPAM_ from e-mail addresses!