LoginTutorial
Authentication and First Login
To login to the central machines at Fermilab, you will need first need your accounts created. This process may take a day or two, and will result in three authentications:
- kerberos used for loggins into central machines, among others
- a services account for email, servicedesk and other uses
- CILogin certificate, for submitting jobs, transferring and uploading data
You can read more about this at Authentication, which you should at least scan before continuing.
If you are sitting at a Fermilab linux computer, you can use your kerberos login at the login screen. If you are at a university computer with kerberos installed, you may or may not be able to obtain your kerberos authentication. If you are already on a Fermilab desktop or a Mu2e central computer, you can get this authentication with:
kinit <your user name>@FNAL.GOV
If that is successful, you can login to the central systems:
ssh <username>@mu2egpvm01.fnal.gov
If you have problems, please look through Authentication and the links it points to, in particular, if you are on a University machine, you might need to configure kerberos with a new krb5.conf file.
If you are on a windows laptop, you will want to install Putty and xming. PuTTy allows you to login in a terminal window on the central machines, and xming allows you to display xwindows back on your laptop. If you are on a Mac, see Mac's.
You probably want to try out your email, by going to email.fnal.gov and putting in your services password. Some official communications are sent only to this address so check it regularly or forward it to a preferred account.
OK, from here on we will assume you are on a central machine.
You can see your ticket with the klist command:
> klist
Ticket cache: FILE:/tmp/krb5cc_1311_xShHU10541
Default principal: rlc@FNAL.GOV
Valid starting Expires Service principal
06/18/19 12:58:54 06/19/19 14:58:50 krbtgt/FNAL.GOV@FNAL.GOV
renew until 06/25/19 12:58:50
If you stay logged on overnight, it will expire and you will need to renew it with kinit.
You can use your kerberos identity to invoke your certificate identity with kx509.
> kx509 Authorizing ...... authorized Fetching certificate ..... fetched Storing certificate in /tmp/x509up_u1311 Your certificate is valid until: Tue Jun 25 13:18:18 2019
You can see your cert with voms-proxy-info --all:
> voms-proxy-info --all subject : /DC=org/DC=cilogon/C=US/O=Fermi National Accelerator Laboratory/OU=People/CN=Raymond Culbertson/CN=UID:rlc issuer : /DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Basic CA 1 identity : /DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Basic CA 1 type : unknown strength : 2048 bits path : /tmp/x509up_u1311 timeleft : 167:51:31 key usage : Digital Signature, Key Encipherment, Data Encipherment
Your certificate can be extended with information about your experiment and the roles you have access to. This can be done with a script
/cvmfs/mu2e.opensciencegrid.org/bin/vomsCert
If you then run voms-proxy-info --all you will see your cert has gotten longer.
You will want to bring your certificate into your browsers since a few web pages, notably the Mu2e doc-db, are authenticated with the certificate. Download your cert into your browsers.
You will want to create an account on hypernews and subscribe to topics that are relevant for you.
Mu2e Machines
There are several Mu2e dedicated machines (actually virtual machines).
- mu2egpvm01,2,3,4,5 general purpose machines with SL6 operating system
- mu2egpvm06 general purpose machines with SL7 operating system
- mu2ebuild01 machine to compile code
By "general purpose" we mean running executables for a short time, or making and viewing histograms, or writing notes. These machines have 4 cores. The build machine, mu2ebuild01 has 16 cores so it can compile the entire Mu2e code in a reasonable time, about 11 min.
Mu2e Disks
You can read more about the Disks, but in the tutorial, we give a quick tour.
home disk
When you log in, your default directory will be your home area, which is the same for all the Mu2e centrl machines. It may or may not be the same as a linux desktop you are sitting at, depending on how it was set up.
> pwd /nashome/r/rlc
We recommend you use the bash shell, which you should get by default:
> echo $SHELL /bin/bash
to do only minor configuration of your preferences, such and alias for convenience. We have some recommendations
This disk is backed up daily.
app disk
/mu2e/app is where you will put code that you checkout compile and develop. You can create you own area:
mkdir -p /mu2e/app/users/$USER
and you should be able to write there
touch /mu2e/app/users/$USER/test
Note that you will have a finite quota on this disk, so do not put data files here (see next).
This disk is not backed up.
data disk
/mu2e/data is where you can put data files and ntuples that you are using now. You can create you own area:
mkdir -p /mu2e/data/users/$USER
and you should be able to write there
touch /mu2e/data/users/$USER/test
This space is limited, so if you are using more than 500 GB or the files are sitting there for more than a few months, you should consider putting the files on tape or dCache (see next).
This disk is not backed up.
dCache
dCache is a system of software, databases, and disk servers that are design to present a huge amount of disk, spread over many machines, as a single simple disk system. We will cover these area in more depth in future tutorials, but as an overview, dCache has three main parts:
- tape-backed If files are written here, they are copied to tape. These file might disappear off disk if they are not used, and can be restored to disk from tape, as needed. You will only write here using specific tools.
> ls -l /pnfs/mu2e/tape/phy-sim/sim/mu2e/DS-beam/MDC2018a/art/ff/f7/sim.mu2e.DS-beam.MDC2018a.001002_00373598.art -rw-r--r-- 1 mu2epro mu2e 34186158 May 24 2018 /pnfs/mu2e/tape/phy-sim/sim/mu2e/DS-beam/MDC2018a/art/ff/f7/sim.mu2e.DS-beam.MDC2018a.001002_00373598.art
- persistant Files written here are not automatically purged and are not copied to tape, so the space must be managed. Currenlty we only allow writing here in specific cases.
> ls -l /pnfs/mu2e/persistent/datasets/phy-etc/cnf/mu2e/CeEndpoint/MDC2018b/fcl/00/04/cnf.mu2e.CeEndpoint.MDC2018b.001002_00000025.fcl -rw-r--r-- 1 mu2epro mu2e 690 Aug 27 2018 /pnfs/mu2e/persistent/datasets/phy-etc/cnf/mu2e/CeEndpoint/MDC2018b/fcl/00/04/cnf.mu2e.CeEndpoint.MDC2018b.001002_00000025.fcl
- scratch You can write as much data here as you would like. As space is needed, file that have not be recently accessed will be deleted to make room. You can expect untouched files to last a month, but we have seen shorter times, under special circumstances.
Create your scratch directory:
mkdir -p /pnfs/mu2e/scratch/users/$USER
and you should be able to write there
touch /pnfs/mu2e/scratch/users/$USER/test
and copy a file there:
cp /pnfs/mu2e/persistent/datasets/phy-etc/cnf/mu2e/CeEndpoint/MDC2018b/fcl/00/04/cnf.mu2e.CeEndpoint.MDC2018b.001002_00000025.fcl \ /pnfs/mu2e/scratch/users/$USER
There a are few important notes about dCache you should know right from the beginning.
- dCache is not a file system - it is an nfs server backed by a database. This means simple disk commands such as "find" can cause millions of database queries and try up resources for hours. Only explore one directory at a time. Even using "ls" and not "ls -l" can be much faster.
- You cannot modify files on dCache, only write and read them. If you open a dCache file with an editor, it will come up read-only. The system is designed to be a large data cache, not an interactive disk. All your code should be in your home area or /mu2e/app.
Setup Code
There are two steps to accessing Mu2e code. The first step is to define all the supporting software packages that are available:
source /cvmfs/mu2e.opensciencegrid.org/setupmu2e-art.sh
The main effect is to define PRODUCTS environmental variable:
> printenv PRODUCTS | tr ":" "\n" /cvmfs/mu2e.opensciencegrid.org/artexternals /cvmfs/fermilab.opensciencegrid.org/products/common/db
all the support code packages are under these directories.
The second step is to setup access to a specific version of the Mu2e code. This code does all our detector simulation and reconstruction and calls code in the supporting packages. As the code is developed, we occasionally freeze the code into a fixed version. The particular version could be from cvmfs:
ls /cvmfs/mu2e.opensciencegrid.org/Offline | tail -3 v7_3_5 v7_4_0 v7_4_1
These are versions that you can setup. To do that you source a setup file like:
source /cvmfs/mu2e.opensciencegrid.org/Offline/v7_4_1/SLF6/prof/Offline/setup.sh
You can see the additional directories include a choice of operating system (SL6 or 7, see above) and prof or debug. prof refers to the compiled with optimization and debug refers to the same code compiled with optimization turned off which makes it easier to debug some kinds of errors.
If you are developing Mu2e code, you can setup and build the Mu2e code in your local area - more on that later. You can only setup a version of the code once in a process. If you try to setup the code again, it will give you a warning and exit.
> source /cvmfs/mu2e.opensciencegrid.org/Offline/v7_4_1/SLF6/prof/Offline/setup.sh mu2egpvm01 ~ > source /cvmfs/mu2e.opensciencegrid.org/Offline/v7_4_1/SLF6/prof/Offline/setup.sh A base release has already been setup. Hope that's OK. The base release is: /cvmfs/mu2e.opensciencegrid.org/Offline/v7_4_1/SLF6/prof/Offline
The original setup is still good. If you need to run a different setup, you need to do that in a new window.