This chapter provides a very brief summary on use of the EDG Testbed. The rest of the guide and the referenced documentation contain important details which a prudent reader will browse before starting. Before using the EDG Testbed resources you must do the following:
Cryptographic certificates are used to attest to the identity of a user or machine to the extent specified in the issuing Certification Authority's (CA) policy documents. Users accessing EDG resources must have a valid certificate; similarly, machines providing grid services within the testbed must also have one.
For users, a certificate is the grid-equivalent of a passport. As such it is personal and should not be shared with anyone else. You should also ensure that the private key is kept private and that you choose a secure passphrase.
The EDG-approved CAs have service areas which cover most of Europe and the United States. (Consult the current listhttp://marianne.in2p3.fr/datagrid/ca/ca-table-ca.html on the web.) If a user or site is not covered by an existing CA's service area, then one must either start a new CA or negotiate with the French CA to extend its service area2.1.
Note that the certificate application and delivery procedures for each of the CAs varies. Refer to your CA's web site for a description of it's procedures.
The DataGrid relies on the Globus Security Infrastructure (GSI) to implement certificate management. To use the GSI you must have your certificate in PEM format. Follow the instructions in Appendix C if you need to change a P12-formatted certificate into a PEM-formatted certificate. You should then place the two files usercert.pem and userkey.pem into a .globus directory in your home area. The file permissions for the userkey.pem file must be 0600, for usercert.pem 0644 is appropriate.
You may place your certificate and key in a non-standard location, but in this case you must define the two environmental variables x509_user_cert and x509_user_key to point to your certificate and key, respectively before creating a proxy (see Section 2.4).
Signing the EDG Usage Guidelines must be done via a SSL-protected web form. To gain access to this page you must have your certificate loaded into a web-browser. The procedure for loading a certificate into a browser varies greatly between browsers. Instructions are given here for several popular browsers.
You should also select high security otherwise Internet Explorer remembers your pass phrase for you.
Virtual Organizations (VOs) are used to organize the testbed users into various subgroups and are the basis for grid authorization. When a user runs a task, the user's certificate information is compared with a file which is populated by information from the various VOs. ``John Doe'' may have been added to the Alice VO, in which case the file referred to will have an entry for ``John Doe'' along with a directive to map his requests onto a local Alice environment. On the other hand, John would not be allowed to run jobs under other environments.
The current list of virtual organizationshttp://marianne.in2p3.fr/datagrid/vo/vo-table.html can be found on the web. If you did not register with a virtual organization when you signed the EDG Usage Guidelines (or wish to change your VO membership), then you must contact the VO manager directly.
If none of the listed virtual organizations is appropriate for you, use the WP6 VO. It is intended as a catch-all for folks who are not members of any of the others.
With the Testbed 2 software, membership in more than one virtual organization is possible. However the burden of specifying which virtual organization falls to the user. The local account is still determined by the site's configuration and mismatches may cause problems when standard unix permissions are used by services.
To access the resources of the EDG Testbed, you must have a machine available to you which has the User Interface tools installed. Ask your local site administrator if there is such a machine at your site. If not, EDG users may obtain an account on a UI machine at the Computer Center in Lyonhttp://ccgrid.in2p3.fr/index.php?id=user_interface (ccedgui.in2p3.fr) or at RALhttp://atlas.rl.ac.uk/csf/csfuserguide/usrreg.shtml (gppui04.gridpp.rl.ac.uk). People with an AFS account at CERN may use testbed010.cern.ch.
Your access rights to the grid services are tied to the subject name of your certificate. In essence, this is your ``grid user name''. Access is controlled via a proxy which is a time-limited credential signed by your private key. Grid services may take actions on your behalf if they have a copy of this proxy.
Two different methods can be used to generate a user proxy. A standard Globus proxy contains only information to verify your identify. The VOMS (Virtual Organization Membership Service) proxy contains additional authorization information about your memberships in virtual organizations and any groups or roles within those organizations. The VOMS method can only be used if your VO is running a VOMS server; contact your VO manager to determine if this is the case.
The proxy is a plain file stored by default in the /tmp area of the machine. For sites with a large number of workstations, it may be more convenient to store the proxy on a shared file system. This will allow you to generate your proxy once and use it on all of the workstations. To do so, define x509_user_proxy in your shell startup file to point to a file in the shared file system. For example,
export X509_USER_PROXY=~/.globus/proxyfor sh-shell variants. You can then use your standard proxy initialization command and it will generate the proxy in this location.
Once created, the proxy is copied automatically, when necessary, by the various grid commands. Having a copy of your proxy, a service can act on your behalf. Correspondingly anyone with a copy of your proxy can act as you while the proxy is valid. The proxy is initially created so that only you can read it; be careful not to loosen the permissions on the proxy or give anyone else a copy of the proxy.
You can remove the proxy with one of the proxy destruction commands or simply by deleting the proxy file. Note that this will only affect the local proxy and will not affect jobs running with their own copy of your proxy.
The grid-proxy-* commands allow you to manage a Globus proxy. All of these commands accept the help option to give online usage information.
If you have installed your certificate correctly, the command grid-proxy-init will create a new proxy for you. A successful attempt will look similar to the following:
>> grid-proxy-init Your identity: /C=FR/O=CNRS/OU=LAL/CN=Charles Loomis/Email=loomis@lal.in2p3.fr Enter GRID pass phrase for this identity: ********** Creating proxy .................................................. Done Your proxy is valid until Tue Aug 13 03:15:11 2002By default, the proxy will have a lifetime of 12 hours. Proxies with different lifefimes can be generated using the hours option if desired. Note that you expose yourself to a greater chance of having your credentials hacked if you generate a proxy with a long lifetime.
If the certificate has not been installed correctly, then you will see a ``user certificate not found'' error. Check that you have followed the instructions correctly in Section 2.2.1. An incorrect passphrase will result in a ``wrong pass phrase'' error.
To obtain information about a generated proxy, you can use the command grid-proxy-info:
>> grid-proxy-info subject : /C=FR/O=CNRS/OU=LAL/CN=Charles Loomis/Email=loomis@lal.in2p3.fr/CN=proxy issuer : /C=FR/O=CNRS/OU=LAL/CN=Charles Loomis/Email=loomis@lal.in2p3.fr type : full strength : 512 bits timeleft : 11:36:17Individual parts of this information can be selected using command options.
To destroy explicitly the proxy before it has expired, use the command grid-proxy-destroy; the simpliest form takes no arguments. However this only destroys (erases) the local copy of the proxy. It does not affect copies of your proxy in use by your jobs or by grid services.
The edg-voms-proxy-* commands allow you to manage a VOMS proxy. All of these commands accept the help option to give online usage information.
To initialize a VOMS proxy, use the command:
>> edg-voms-proxy-init
To obtain information about your VOMS proxy, use the command:
>> edg-voms-proxy-init -print
To destroy your VOMS proxy, use the command:
>> edg-voms-proxy-destroy