You are here: Home Experiment Information US ATLAS Grid Development How to Collaborate on Grid Development Projects

How to Collaborate on Grid Development Projects

by jhover — last modified Jun 07, 2013 04:08 PM
Contributors: John DeStefano
Information about downloading projects, building them, working on them, and checking in your edits.

The Grid Development group uses Subversion for its source code control system (SCCS). Subversion is essentially a rewritten and modernized CVS. More help on using Subversion can be found at http://subversion.tigris.org .

The server is svn.usatlas.bnl.gov. There are several repositories, with different purposes and projects.

 

Subversion URL Purpose Access Control
https://svn.usatlas.bnl.gov/svn/griddev/ General grid development RHIC Kerberos Credential
https://svn.usatlas.bnl.gov/svn/privilege/ Privilege Project development Grid Cert/SSL Only

We use a slightly non-standard layout for our repositories, with trunk directories directly off the root, and shared branch and tag directories. This means that tags from more than one project may be in tags.

 

Subversion Client Setup

To use subversion from a UNIX system, you will need a few prerequisites:

  • The Subversion client installed on your computer.
  • Your grid certificate in PKCS12 format.
  • Your Subversion client ('svn') configured to use your personal certificate. This is a template of the Subversion servers file:

 

 #
# ~/.subversion/servers
#
[groups]
racf = svn.usatlas.bnl.gov
[racf]
ssl-client-cert-file = /home/jhover/.globus/jhover-digicert-2013.p12
ssl-client-cert-password = tOpsEcrEt
ssl-trust-default-ca = yes
[global]

Note: Some Subversion have problems with certain user certificates. If you encounter "Decrypt error" messages, then this may be the cause. The problem is that the server cannot tolerate a client certificate that includes CA certificates within. To work around the problem, you need to remove those CA entries from you client certificate.

To do this, you must:

  • Convert your .p12 certificate to .pem format, e.g.
    openssl pkcs12 -nokeys -in jhover-digicert-2013.p12 -out usercert.pem -nodes
    openssl pkcs12 -nocerts -in jhover-digicert-2013.p12 -out userkey.pem -nodes
  • Edit usercert.pem.
    • Determine which block is your user cert and which one(s) is/are for the issuing CA(s).
    • Remove all text except the user certificate entry.
    • The final file should have a first line with ---BEGIN CERTIFICATE---, a block of characters (the certificate), and the last line should have ---END CERTIFICATE---.
  • Convert these .pem files back into a .p12 format cert usable by the subversion client, e.g.:
  • openssl pkcs12 -export -out jhover-digicert-mineonly-2013 -inkey userkey.pem -in usercert.pem

 

Once this is set up, you can check out code like so:

svn checkout https://svn.usatlas.bnl.gov/svn/privilege/branches/gums-1.3.x

 

CA RPM Setup via YUM

Grid software frequently relies on PKI (Public Key Infrastructure) which calls for Certificate Authority files to be installed locally. LCG/EGEE provides a full set of IGTF RPMs installable from an internet YUM repository. (YUM is the default package manager for Scientific Linux and Fedora Core ).

 

  • Copy glite-ca.repo into /etc/yum.repos.d/
  • Run yum install lcg-CA
  • Do rpm -ivh /afs/usatlas.bnl.gov/mgmt/src/rpm/generic-glite/fetch-crl-2.7.0-1.noarch.rpm
  • Create symlink from /usr/share/doc/fetch-crl-2.7.0/fetch-crl.cron in /etc/cron.daily/. Be sure to chmod it executable./li>

This will put a set of valid CA files in /etc/grid-security/certificates which can then be configured as trusted CAs.

 

 

Java Development Environment

While we would never attempt to tell developers how to set up their systems, we do have a standard Java development environment that we've found reduces the number of unknown variables in working through differing results between systems. We've also found this to be a configuration that is easily replicated on newly installed systems. Best of all, it allows components to be updated as newer versions are released. The following instructions have been confirmed to work on Fedora Core 6, and Scientific Linux 4.x (and thus presumably Redhat 4.x). Other distributions may very well work. Please let us know how you fare if you try something else.

 

 

  • Set up Jpackage as a YUM repository. We have tested Jpackage version 1.7.

 

  • Install java--sun-compat: yum install java-1.5.0-sun-compat or yum install java-1.4.2-sun-compat depending on which JDK you chose above. Note that it may be a little tricky--the revision number of the particular JDK must match the revision number of the compat library from JPackage. So you may have to search out the correct JDK version and revision to match the latest available from JPackage. You can determine the latest from JPackage by attempting to install the compat library (which will fail without a JDK) and note the revision number mentioned in the error message.

 

  • Set alternatives for Java, e.g. alternatives --set java /usr/lib/jvm/jre-1.5.0-sun/bin/java (or whatever path is appropriate to your JDK). See the output of alternatives --display java for the appropriate path.

 

  • Install maven2 and other requisites: yum install maven2 junit tomcat5 tomcat5-admin-webapps

 

Using an IDE for Development

If you are interested in using the Eclipse IDE (Integrated Development Environment) you may find the instructions here useful.

Document Actions
Filed under: