Can't access D0CVS - updated

The old repository has been disabled
1 Apr 2006

If you get "permission denied" errors to a "cvs checkout" or "addpkg" command, the cause is most likely that you have an old checkout in your working area that contains a CVS/Root file pointing to the old repository. This will override your CVSROOT settings. To fix it follow the instructions below under the 17 Jan 2006 heading, or just:

    cd <your-working-area>
    setup d0cvs                  # v2_0 or greater
    fixcvsroot.sh

If the problem presists, go to the problems section below.

Anonymous ReadOnly access available
4 Apr 2006

Anonymous ReadOnly access is availabe to the D0 cvs repository. To use it set:

    CVSROOT=:pserver:anonymous@cdcvs.fnal.gov:/cvsroot/d0cvs
    CVS_RSH= whatever you prefer, ssh or an ssh wrapper is recommended, 
             see below.

NOTE: if you checkout a package readonly you will not be able to make changes and check them back in. But this can be useful if you know that you won't want to do that.

Switching to the new cvs repository machine
17 Jan 2006

We have moved the DØ cvs repository to a new, much faster machine.

If you do a new cvs checkout, you need do nothing, other than making sure that you have and use a version of d0cvs v2_0 or greater, or make the settings by hand that that makes:
- CVSROOT=d0cvs@cdcvs.fnal.gov:/cvsroot/d0cvs
- CVS_RSH=ssh
  or better:
- CVS_RSH=${D0CVS_DIR}/bin/sshwrap.sh
  sshwrap.sh wraps the ssh command so we can add the "-x" switch to suppress an annoying error message.
- to commit back into the repository, you must be running under an ssh agent.
  See: Using (unkerberized) ssh with cvs
- d0sshcvs is now obsolete. Everyone should use d0cvs and/or the setting above. But see below.
If you have previously checked out copies of anything, from anywhere above your checked out package(s) in the directory tree, run the script packaged with d0cvs v2.x
- fixcvsroot.sh
then proceed as normal.

For the vast majority of users, this is all they need to do.

If you have problems

FIRST

If you get "permission denied" errors to "cvs checkout" or "addpkg" commands go to the 1 Apr 2006 section above.

SECOND

Some people have not been able to establish a connection to the new machine at all.

If you are getting: "No Encryption" error messages, this has nothing to do with the repository. You probably don't have a valid kerberos ticket.
Make sure that you have a valid forwardable ticket:
klist -f
check the date/time and look for an "F" in the Flags: field.
To fix, make sure you are using an encrypted link then:
kinit -f
and recheck.
Most of the connection problems we've found have been due to incompatibilities between the kerberos you are using, usually on a new machine, often a laptop, and the rather old version running on the repository machine. The latter is needed because the kerberos gurus broke backward compatibility due to a security issue with kerberos. There are also possible compatibility problems with various ssh versions.
There are a number of things that you can try:
- Kerberos authentication
  - Change your CVSROOT (and any CVS/Root files) to cdcvs3.fnal.gov rather than cdcvs.fnal.gov. The latter is the same machine at the moment, but you'll come into a different port which uses newer versions of both ssh and kerberos.
    BEWARE if cdcvs3 has problems it fails over to cdcvs4. So if you lose connections to cdcvs3, you have to change to cdcvs4 by hand and then back again.
  - You can try using rsh to get rid of any ssh version incompatibilities. BUT it must be kerberized rsh and it must be compatible with Fermilab's versions. To do this, set
    - CVS_RSH=rsh
  - You can try installing Fermilab's version of ssh. The one from ClueD0 has worked for some people. Just copy /usr/bin/ssh to a directory on your machine and set CVS_RSH=/ssh. You could try the same thing with Fermilab's rsh.
    You could install it as your system's ssh, but then you'd use it for everything, which may not be a good idea. Using CVS_RSH to point to it means it'll *only* be used for cvs where it's needed.
- RSA (unkerberized ssh) authentication
  In particular if you are getting:
  - no kex alg or
  - No key exchange algorithm
  This may also help for some kerberized ssh problems.
  - you can try adding the following to ${HOME}/.ssh/config
```
      host cdcvs*.fnal.gov
        ForwardX11 = no
        ForwardAgent = yes
        protocol = 1
     
```
    You might have to try different combinations of things. I know of one person who had to comment out the "protocol = 1" line, and one person changed it to "protocol = 2,1".

Need to register for RSA (unkerberized) ssh access

If your machine is not kerberized (no Fermi kerberized ssh or rsh) you need to register your ssh public key (RSA 1). All you need do is generate a key

                ssh-keygen           # on an ssh 1 system
                ssh-keygen -t rsa1   # on most modern systems

and send it (identity.pub by default) to d0-release-mgr@fnal.gov

See Converting from cvs and cvsh with rsh to ssh for details on how to use ssh to access a repository.

Please indicate that you want your principal or public key registered with D0CVS and who you are. There are lot's of things I could do with these. Most of them won't get you registered. My crystal ball also has been broken for some time now. So please help out.

NOTE: Neither kerberos principals nor ssh keys are machine dependent. They authenticate you. There is a separate authentication that happens for your machine that you don't see.

Alan Jonckheere

Last modified: Thu Oct 5 10:31:15 CDT 2006