SLAC provides a backed-up, reliable home for the GLAST cvs repository. It is stored in nfs and is accessible from most nodes at SLAC. It is, however, inside the SLAC firewall and so access to the repository takes a little more setup work than would otherwise be required.
These instructions are specific to the ground software repository. The only changes for flight software are the location of the repository, and the particular nfs group that gives write permission. The changes are noted in the text below.
Basically, one must set up Secure Shell (ssh) access to SLAC from your machine. There are free tools available for Windows to do this; where to get these tools from is explained below. ssh and cvs are more natural components of unix systems, so we will assume here that, if you are running unix, you have ssh and cvs installed already.
There are a number of initial steps which need to be done, whether you are using a Unix or a Windows machine. There are then steps that are specific to a given system.
Initial Steps: Acquiring a SLAC account and generating your public/private keys on a SLAC noric machine.
Getting a SLAC account
You will need a SLAC unix account. If you don't have one, see here for help.
Your account will need to be added to the glground nfs group to give you write access to the repository [glflight for flight software]. To check whether or not you belong to this group type "ypcat group | grep glground" ("ypcat group | grep glflight") when logged on to a SLAC unix machine. If your user name is not in the resulting list, you are not part of that group. Contact Richard to remedy the situation.
Generate the ssh encrypted key set
Once you have your SLAC account, you need to generate an encrypted key set on a SLAC noric machine and set some permissions:
SSH PROTOCOL 1
From your home directory, use ssh-keygen to create the private-public key pair. Two files are created: identity (private key) and identity.pub (public key).
It will ask you for a pass-phrase: give it a blank one (ie just hit <CR>). Here is an explanation from Tony Waite on what is happening with the use of RSA encryption and blank pass-phrases.
Append identity.pub to ~/.ssh/.public/authorized_keys
cd ~/.ssh/.public
cat identity.pub >> authorized_keys
Note that ~/.ssh/authorized_keys is a symbolic link to ~/.ssh/.public/authorized_keys, required by the afs permissions.
Also note that the resulting files in .ssh/.public must not have group or world write permissons. The unix permission should look like:
noric02:burnett> ls -l total 3 -rw-r--r-- 1 burnett ek 331 Jul 16 2000 authorized_keys -rw-r--r-- 1 burnett ek 1 Aug 29 1999 identity.pub -rw-r----- 1 burnett ek 1017 Oct 26 2000 known_hosts |
If instead you see -rw-rw-rw, ssh will not allow authentication, and you must run "chmod 644 *" in this folder.
The above should allow your SSH1 protocol client to connect without password. If you are still prompted for a password, it is likely your client is attempting an SSH2 connection. Follow these instructions for SSH2:
1. Log on to any public SLAC unix machine intended for interactive use, such as a noric
2. from your home directory, use ssh-keygen -t rsa to create the private-public key pair. Two files are created, id_rsa (private key) and id_rsa.pub (public key)
3. It will ask you for a pass-phrase: give it a blank one (ie just hit <CR>). append id_rsa.pub to ~/.ssh/.public/authorized_keys
cd ~/.ssh/.public ; cat id_rsa.pub >> authorized_hosts2
4. make sure the permissions are correct.
chmod 0644 ~/.ssh/.public/*
If you get strange delays, and and error message about "unable to lock Xauthority file" you need to disable X11 forwarding for protocol 2. This can be done on the command line with the -x flag, or in the /etc/ssh/ssh_config file. Change the line "ForwardX11 yes" to "ForwardX11 no". This is the result of the SSH server trying to touch a file in your home directory without possessing an AFS token. If you require a local copy of the ssh_config file - copy /etc/ssh/ssh_config to your $HOME/.ssh directory and name the file "config" .
Windows Instructions: Set up ssh and cvs for Windows.
Setting up ssh on Windows
Get the ssh exectuable. You can get the distribution (ssh-1-2.14-win32bin.zip) from us: ftp://ftp.slac.stanford.edu/groups/glast/ground/WindowsThings. Or download and install ssh from ftp://ftp.ssh.com. See the Win CVS faq entry for confirmation of this. Read their instructions for setting it up, but basically just install ssh and then follow the instructions here. Note: an ssh terminal emulation package will not suffice! Get the distribution listed above!
Add the location where you installed ssh to your path. See below for a summary of the environment variables you will need to edit in the course of the Windows setup.
Set a environment variable called HOME (eg c:\users\<your_name>).
Create a subdirectory called .ssh (yes there is a dot in the name! You probably have to do it from DOS) in your $HOME directory and copy your private key (the file identity created in Initial Steps #2) from your SLAC account to this .ssh directory on your own computer. You can use either scp or ftp to do this. Note that if you use ftp, that the SLAC firewall prevents you from ftp to a SLAC machine. You will have do logon to a SLAC machine, then ftp back to your home machine to do the transfer. Also note that identity is a binary file, so make sure you do a binary transfer if you ftp it over. You should protect this file by permissions.
Testing ssh
To test if ssh is set up correctly issue the following command in a DOS prompt
ssh noric02.slac.stanford.edu date
This should logon to a SLAC noric box and execute the 'date' command without querying you for a password and then exit. If your user name on your home computer is different from your user name on the SLAC machines, you need to use the -l flag for the above command. So say your SLAC user name is 'tlindner' which isn't the same as your home computer user name. The above command then becomes
ssh -l tlindner noric02.slac.stanford.edu date
Setting up cvs on Windows
Download and install WinCVS from www.wincvs.org. Choose the latest version which looks stable. If there are problems contact Richard. Two points:
The WinCvs program is needed only for command-line cvs executable. You are free to use the gui if you desire, but it not necessary for accessing the repositroy (nor will we explain how it should be used).
The WinCVS website will soon be migrating to http://www.cvsgui.org. If the above link is dead, check there.
Add the location where you installed WinCVS (which contains the cvs executable) to your PATH environment variable.
Identifying the SLAC cvs repository and access method
CVSROOT is used to specify to cvs which computer and where on that computer the repository is located. CVS_RSH specifies the protocol with which to logon.
Set an environment variable CVSROOT to be
:ext:centaurusa.slac.stanford.edu:/nfs/slac/g/glast/ground/cvs
[:ext:centaurusa.slac.stanford.edu:/nfs/slac/g/glast/flight/archive]
-
If your account name on your local machine differs from
your SLAC account name, you need to prepend your account name to the
noric node name, as in :ext:richard@centaurusa.slac.stanford.edu:/nfs/slac/g/glast/ground/cvs
Make sure that you don't have a space at the end of you CVSROOT environment variable.
Set an environment variable CVS_RSH to be ssh
Environment Variables to Edit
| Enviroment Variable Name | New or Append? | Value |
| PATH | Append | Location where you ssh executable resides |
| PATH | Append | Location where your cvs executable resides |
| HOME | New | Location where your .ssh directory resides |
| CVSROOT | New | :ext:centaursa.slac.stanford.edu:/nfs/slac/g/glast/ground/cvs * |
| CVS_RSH | New | ssh |
* Change as specified above, if your user names differ.
Unix Instructions: Set up ssh and cvs for Unix.
Setting up ssh on your unix box *
copy your private key (the file identity created in Initial Steps #2 to your ~/.ssh directory. This file should be protected by permissions. You can use either scp or ftp to do this. Note that if you use ftp, that the SLAC firewall prevents you from ftp to a SLAC machine. You will have do logon to a SLAC machine, then ftp back to your home machine to do the transfer. Also note that identity is a binary file, so make sure you do a binary transfer if you ftp it over. You should protect this file by permissions.
- Note that people working in France will have to use ssf. This doesn't seem to cause any problems. Just replace 'ssh' with 'ssf' throughout the instructions.
Testing ssh
To test if ssh is set up correctly issue the following command in a DOS prompt
ssh noric02.slac.stanford.edu date
This should logon to a SLAC noric box and execute the 'date' command without querying you for a password and then exit. If your user name on your home computer is different from your user name on the SLAC machines, you need to use the -l flag for the above command. So say your SLAC user name is 'tlindner' which isn't the same as your home computer user name. The above command then becomes
ssh -l tlindner noric02.slac.stanford.edu date
Identifying the SLAC cvs repository and access method
CVSROOT is used to specify to cvs which computer and where on that computer the repository is located. CVS_RSH specifies the protocol with which to logon.
Set an environment variable CVSROOT to be
:ext:centaurusa.slac.stanford.edu:/nfs/slac/g/glast/ground/cvs
[:ext:centaurusa.slac.stanford.edu:/nfs/slac/g/glast/flight/archive]
-
If your account name on your local machine differs from
your SLAC account name, you need to prepend your account name to the
noric node name, as in
:ext:richard@centaurusa.slac.stanford.edu:/nfs/slac/g/glast/ground/cvs
- Make sure that you don't have a space at the end of your CVSROOT environment variable.
-if you are a Linux machine inside SLAC set your CVS root to be:
/nfs/slac/g/glast/ground/cvs
Set an environment variable CVS_RSH to be
ssh
Notes to Linux Users External To SLAC
Currently there are some difficulties with Kerberos authentication at SLAC. This will cause some garbage in the output stream when doing CMT checkouts. SLAC Computing Services is aware of the problem. The error message will look something like this:
Warning: Kerberos authentication disabled in SUID client. /usr/X11R6/bin/xauth: creating new authority file /tmp/Xauth6801_14059
Though these pages have undergone many iterations, there are still plenty of things that might go wrong. Visit the TroubleShooting page for a list of common problems and gotcha's.
Acknowledgements
Thanks to Tony Waite for pointing out most of the steps in these instructions!
T. Lindner Last Modified: 04/11/2002 08:22