Try the Grid
Step by step instruction for Grid beginners and BalticGrid newcomers
This sub-section provides a short guide for BalticGrid new or potential users willing to submit their first simple job. The procedure comprises several steps:
Security and registration
In order to prove a user identity on the BalticGrid testbed, a user needs an X509 certificate issued by one of the BalticGrid Certification Authorities. Generally a user requests a certificate to a Certification Authority (CA) by filling and submitting an on-line form. The manager of the CA checks the user's identity and eventually issues the certificate. The certificate is generally made available via web. If so, the user has to download the certificate with the same browser he used to submit the form. This is because the browser generates a key pair (a public encryption key and a private one) at request submission time and keeps it in its local data base. The certificate can be downloaded only by a browser which keeps the correct private key.
1. get a valid certificate
In the BalticGrid you will get the certificate from Certification Authority in your country. The certificate is indispensable to be able to access resources that are located in different institutes running different administrative policies.
| nstitution |
Getting User Certificate |
|---|---|
| IFJ PAN |
Follow the on-line form. Your institution is "IFJ" in pop-down menu. |
| Remaining institutes |
Visit: BalticGrid CA web page |
2. load personal certificate into a browser
The certificate should be imported into your web browser while accessing BalticGrid VO registration pages as you must authenticate with your certificate to a web site, and thus you would have your certificate available inside your web browser.
The certificate file you have on disk is suitable for Grid use, but needs to be converted to a different format for web browsers. This format is called PKCS#12, and files have the extension .p12. This format is special in the sense that the file contains both your public and your private key, and the combination is again protected with a pass phrase (here called export password).
The openssl programme is used to convert between the different formats:$ cd $HOME/.globus
$ openssl pkcs12 -export -in usercert.pem -inkey userkey.pem -out identity-package.p12
After making use of identity-package.p12 file, you should immediately delete it from disk for security concerns!
The file identity-package.p12 now contains both your certificate and your private key, and can be imported into the most popular browsers - Mozilla, Internet Explorer or Opera.
Certificate stores for these browsers can be accessed following the paths below:
- Internet Explorer: Tools -> Internet Options -> Content -> Certificates
- Mozilla Firefox: Tools -> Options -> Advanced -> Certificates
- Opera: Tools -> Preferences -> Security -> Manage Certificates
If you experience problems with accessing the certificate-secured pages despite having a valid certificate installed – please read the info below:
If you have problems with accessing the certificate-secured pages despite having a valid certificate installed, you should try clearing your browser's cache and then restarting it (it's important that you close ALL browser windows for this to take effect). The locations of the controls to clear the browser cache for popular browsers can be found below.
- Internet Explorer: Tools -> Internet Options -> General -> Delete Files... (you should also check the 'Delete all offline content' box)
- Mozilla Firefox: Tools -> Options -> Privacy -> Cache -> Clear
- Opera: Tools -> Options -> History & Cache -> (Disk cache) Empty now (and apply afterwards)
- Netscape Navigator: Edit -> Preferences -> Advanced -> Cache -> Clear cache
This occurs when you have Client Certificate Selection set to 'Ask every time'. You should change it to 'Select automatically'.
Next the user should contact the corresponding VO administrator for authorization.
3. join a Virtual Organization (VO)
Users and resources on the BalticGrid must belong to one or more Virtual Organizations (VOs). Each VO is made up of users, resources (machines, sensors, etc.) and rules to access and share resources. Each VO has an LDAP
server which keeps information about users and resources (in particular it keeps the subjects of their certificates). A user who wants to join a VO must contact the VO administrator who will create an entry in the LDAP server. The BalticGrid user profile will be mapped to local Unix accounts on the machines belonging to that VO.
How to register to a BalticGrid VO
Having your certificate loaded in the browser you may proceed to registering to one of the BalticGrid VOs:
- balticgrid VO - the generic BalticGrid VO, common to all BG participants and developers (User Registration Page)
or
- gamess VO - for users of the GAMESS chemical system.
On the left-hand menu click on "My requests" and then "Requesting a membership" and follow the guides.
Registration procedure.
During the process of your registration you should receive an e-mail confirming reception of your request by the VO manager and after successful evaluation of your request you shall receive e-mail confirming acceptance of your application.
From that moment on you are the BalticGrid VO member. You still shall wait around 6 hours for new membership information to propagate onto all Grid sites.
4. install your certificate on the User Interface (UI) machine
Once joined a Virtual Organization, you need a Unix account on a User Interface machine belonging to that VO where you will upload your certificate and private key in the ".globus" sub-directory of your home directory.
How to get access to Grid?
Each BalticGrid VO member accesses the BalticGrid infrastructure via so called "User Interface" (UI) machine. The UI is a Linux machine with client-side software for working with Grid installed. You can either use standalone UI machine (see the table below) or install it on your PC using the on-line instruction
.
As UIs are installed in different administrative domains running specific access policies, you should apply for the access (ACCOUNT) at your affiliated institute.
| Institute |
UI |
Getting access |
| IFJ PAN |
ares02.cyf-kr.edu.pl (IA-64, Scientific Linux) |
Contact: Marcin Radecki, radecki AT agh.edu.pl |
| KTU |
pupa.elen.ktu.lt (IA-32, Scientific Linux 3.x) |
Contact: Kestutis Paulikas, kestas AT elen.ktu.lt +370 608 13574 |
Another possibility accessing to the Grid is using your own machine where you can install Grid Access User Interface Plug and Play (short called UIPnP). UIPnP contains all files in a unique directory without any RPM. This is the easiest way to access the Grid and will allow you to use the shared resources of nodes that already belong to the Grid. UIPnP is intended to be installed by any user (no root privileges are needed!). You can download UIPnP tarball from this location.
This tarball includes all necessary adjustments for Balticgrid VO support.
NB! To install UIPnP on your machine you should have ~1GB of free space plus ~250MB for the tarball.
All you have to do is download this tarball, unpack and run the shell script which validates some necessary environment variables. Let's see it step-by-step:
cd
wget http://voms.balticgrid.org/UIPnP-BG/UIPnP.gLite.tar.gz
tar jxf UIPnP.gLite.tar.gz
cd UIPnP
source UIPnP.sh
…and that`s all.
Start a new session
5. creating proxy
Having the account on the User Interface machine, you can submit a job to BalticGrid. To do that, you must have a valid proxy certificate in the UI machine. So you link to the selected UI:
$ ssh username@pupa.elen.ktu.lt
(login to one of the UI mentioned in the previous section)
and then create a proxy process, which will act on your behalf with temporary credentials, issuing the command:
$ voms-proxy-init (creates "proxy" credentials).
Job submission to the Grid
6. describing the job in the Job Description Language (JDL)
To submit the job to the BalticGrid, you have to create a file which will contain input information – a specification of the resources required to run your job. The job will be described in the Job Description Language (JDL) and saved as file.jdl.
JDL allows to specify things like executables, input files, output files, Operating Systems, etc.
Example of a job
The following jdl file can be used to run the command "/bin/echo" on a Worker Node, passing the string "Hello World" as a parameter. The output is saved inside the "message.txt" and the standard error is redirected in the stderror file.
Executable = "/bin/echo";
Arguments = "Hello World";
StdOutput = "message.txt";
StdError = "stderror";
OutputSandbox = {"message.txt","stderror"};
The last argument specifies the content of the output sandbox. Once the job has been completed, the user will be able to retrieve those files from the Resource Broker (RB).
In the following we shall assume that the above specifications are saved in the file HelloWorld.jdl.
7. submitting the job to the Resource Broker (RB)
Once you have your jdl file you can submit it to the Resource Broker. Now you have two options:
- choose the Computing Element matching your requirements or
- let the Resource Broker make the choice.
In the first case you have to "ask" the Resource Broker for a list
of CEs matching your requirements. Then you can submit your job to the
RB specifying the CE. In the latter case you just submit the jdl file
to the RB and let it do everything.
HowTo
To get the list of the Computing Elements matching your requirements you can issue the following command:
$ glite-job-list-match HelloWorld.jdl
The Resource Broker will return a list of Computing Elements matching your requirements.
Let's assume that you want to submit your job to ares02.cyf-kr.edu.pl so you will issue the command
$ glite-job-submit -r ares02.cyf-kr.edu.pl HelloWorld.jdl
The system replies with something like:
Connecting to host ares02.cyf-kr.edu.pl, port 7771
Logging to host ares02.cyf-kr.edu.pl, port 15830
=========================dg-job-submit Success==========================
The job has been successfully submitted to the Resource Broker.
Use dg-job-status command to check job current status. Your job identifier (dg_jobId) is:
https:// ares02.cyf-kr.edu.pl:7846/150.146.150.11/165722196826579? ares02.cyf-kr.edu.pl:7771
The dg_jobId has been saved in the following file:
/home/lauri/.tmp_submittedjob_lauri
===================================================================
If you prefer to let the RB choose the most appropriate CE you will issue the command:
$ glite-job-submit HelloWorld.jdl
8. checking the status of the job
Once the job has been submitted you can query its status sending the appropriate command to the RB.
Once the status is "Output Ready" you can retrieve the output.
To query the status of a job the user have to issue the following command:
$ glite-job-status <JobID>
where JobID is the long string beginning with "https" the user got when he submitted the job.
9. retrieving the output
If the status is "Output Ready" the user can retrieve the output issuing the following command:
$ glite-job-output <JobID>
The content of the output sandbox is moved from the Resource Broker to
the User Interface machine and the job status changes to "Cleared".
---------------------------------------------------------------------------
NOTE:
Steps from 1 to 4 ("get a valid certificate", “load personal certificate into a browser”, "join a Virtual Organization", "install your certificate on the User Interface machine") need to be performed just onceand enable the user to access grid resources.
Step 5 ("create proxy credentials") needs to be performed just if the user does not have proxy credentials or if his/her proxy credentials have expired.
Steps from 6 and 9 ("write your first jdl file", "submit your jdl file to the Resource Broker", "check the status of your job” and “retrieve the output") need to be performed each time the user wants to submit a job to the BalticGrid.


