- Table of contents
- Fermilab Computing Access
Fermilab Computing Access¶
Getting Fermilab Computing Access¶
In order to work on novasoft development you will need to have access to the FNAL computing resources.
On-site access and computing accounts are described here:
FNAL will provide you with a kerberos principal, a 'services' account, and set up email forwarding.
Getting NOvA Computing Access¶
- Submit a service desk ticket for a NOvA project account
- ServiceNow -> Service Catalog -> Affiliation\Experiment Computing Account Request
- Enter your name, then select E-929 (NOVA)
Verify that the correct Fermilab principal is displayed when you enter your name
- Enter your home institution, then click Submit
- Login into the NOvA Redmine project to be made a developer here
The Offline Software SVN Repository¶
The NOvASoft code base is kept in an svn repository. You can get access to the repository by requesting NOvA computing access through the Service Desk.
For instructions on accessing the devs svn repository, check here Devs SVN Repository.
Subscribing to the NOvA-Offline mailing list¶You really do need to do this; these emails are really important!! Instructions for signing yourself up for the offline mailing list are here. You need to sign up for three different email lists:
It's also a good idea to sign up to novasvncommit, though you probably want a rule in your email client to direct the resulting messages into a seperate folder. Some days there are a lot of commits, but it's good to keep up-to-date with what's going on on the ground.
Certificates (DocDB, Grid etc...)¶
When working with the computing resources provided by Fermilab or the Open Science Grid, you will often find that you need to "authenticate" yourself to a service (DocDB, Grid Submission, etc...) so that the service knows you are who you say you are and have appropriate permissions to do what you say you want to do (view a document, submit an analysis job). Certificates are a modern method of doing this.
What is a certificate?¶
A certificate is a collection of information about you, packaged in such a way that someone else can "verify" that the information is correct. When you access a service at Fermilab or OSG, you present your certificate similar to the way you present you driver's licenses as a form of ID at the airport or a bar.
In the case of your driver's license, the person checking your ID first looks at your name and photo to see if it matches what you look like. If it does, then the person checking the id "trusts" the DMV to have done the real background check of your information and so they accept that as long as the issuing credentials are intact (the hologram and general looks of the license) then you are who it says you are.
In the case of digital credentials, the same thing is done. The service first checks that you are who you say you are by performing a "Public Key" challenge according to the Public Key Infrastructure (PKI) standards. Essentially what happens is that your certificate has embedded in it a very large prime number (the public key) which is linked to another large prime number that only your computer knows (the private key). The "challenge" that is passed between the computers is a message that is encrypted by the public key that you present and then decrypted by your private key. If you can decrypt the challenge then you are who you say you are.
At this point the service checking you out can "trust" that the information in the certificate is valid if it can verify that authority that issued your certificate is valid. A similar system of public/private keys is used here too and a "chain of trust" is developed that goes from certificate to certificate up the ladder.
There are many different types of digital authorities that can issue certificates, similar to the the different real world organizations that can issue ID cards.
In 2013, Fermilab and OSG transitioned from using the DoE Grid certificate authority, to using the commercial company DigiCert. This allows for more services to use your certificates to authenticate you with less hassle.
Currently there are two different methods of obtaining valid certificates for use with Fermilab and OSG resources. The first method uses your official Kerberos credentials to generate a certificate. The other uses Digicert to obtain a longer lived certificate.
To determine which type of certificates you need go to:
Kerberos Based KCA Certs¶
To obtain a KCA certificate, first use your kerberos password and the "kinit" program to generate a "kerberos" ticket"
kinit user@FNAL.GOV Please enter the password for user@FNAL.GOV: klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: anorman@FNAL.GOV Valid Starting Expires Service Principal 03/18/13 13:36:49 03/19/13 15:36:25 krbtgt/FNAL.GOV@FNAL.GOV renew until 03/25/13 13:36:25 Addresses: (none)
Then you use the program "kx509" to generate a proper certificate from your kerberos ticket.
[anorman@novagpvm10 ~]$ kx509 Service kx509/certificate issuer= /DC=gov/DC=fnal/O=Fermilab/OU=Certificate Authorities/CN=Kerberized CA HSM subject= /DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Andrew J. Norman/CN=UID:anorman serial=02996F0F hash=6024580a
Some times you want to assume a specific role when running jobs or doing work. To assign the role that is associated with your certificate you use the voms-proxy-init commands. For example to assume the "Production" role you would use:
voms-proxy-init --rfc --voms=fermilab:/fermilab/nova/Role=Production --noregen
For the "Calibration" role you would use:
voms-proxy-init --rfc --voms=fermilab:/fermilab/nova/Role=Calibration --noregen
By default users have the Analysis role and their certs will reflect this.
To check what roles you have go to:
Or to browse the entire Fermilab/Nova list go to: