Personal tools

Try the Grid

by admin last modified 2008-11-07 13:05

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
Browser asks for certificate multiple times (Firefox / Netscape)
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:

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.

HowTo

 

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 once

and 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.

 

 

 

Document Actions
EU

Baltic Grid Second Phase (BalticGrid-II) project is funded by the EU within the framework of the Seventh Framework Programme, in the 'Research infrastructures' activity area, FP7-INFRA-2007-1.2.3: e-Science Grid infrastructures, contract No 223807.

Powered by Plone