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. The procedure for getting a FNAL account is described at

Introduction to Computing at Fermilab

If you will be in residence at the lab, follow the instructions for an on-site visitor. If you will be based at your home institution, follow the instructions for an off-site visitor. FNAL will provide you with a kerberos principal, a 'services' account, and set up email forwarding.

Getting NOvA Computing Access

  1. 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
  2. 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:
  • nova_offline
  • nova_collaboration
  • young_nova

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.

Getting Certificates

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:
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


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: