Glogin
From BG Users Forum
Contents |
Overview
glogin and i2glogin are tools developed in Johannes Kepler University Linz to enable interactive communication between a grid job and the user interface (i2glogin is a spinoff of the original glogin tool).
In the grid-environment, it may not be possible to directly log into grid-nodes. The usual practise is to firewall login-sessions to grid-nodes, but give the user an account on a different machine to bounce off. This method is a bit long winded, because it requires the user to connect to two machines, eventually entering the password each time. On the other hand, a direct connection to the grid-node is neccessary: it is required to contact the gatekeeper in order to submit jobs. Consequently the gatekeeper is used to start up a login-shell.
See the short descriptions below for examples how to:
- access grid job execution directory on Worker Node
- establish bi-directional communication channel between grid job and User Interface
All details concerning glogin and its usage could be found on:
Product homepage: http://www.gup.uni-linz.ac.at/research/projects/glogin
Installation
glogin is a small binary program. To install this follow the instructions: http://www.gup.jku.at/research/projects/glogin/downloads
Accessing grid job execution directory on Worker Node
1. Connecting to Computing Element
- Create VOMS proxy using voms-proxy-init command
[user@gliteUI ~]$ voms-proxy-init -voms <VO-name>
- Launch glogin specifying CE on which grid job was submitted
[user@gliteUI ~]$ ./glogin -g <CE-host>
- After a while a connection with CE-host will be established (it could take few minutes!). Shell on remote machine will be launched.
[mappedUserName@CEHost ~]$ eg.: [balticgrid002@kriit ~]$
2. Accessing Worker Node
At first it should be checked on which Worker Node your grid job is running.
- Check the grid user name you were mapped to.
In most cases the user name is displayed within a prompt. If not, check this using whoami command.
[mappedUserName@CEHost ~]$ whoami <mapped-User-Name> eg.: [balticgrid002@kriit ~]$ whoami balticgrid002
- Check the grid job ID.
[mappedUserName@CEHost ~]$ qstat | grep <mapped-User-Name> <job-number>.kriit STDIN <mapped-User-Name> 0 R <VO-name> eg.: [balticgrid002@kriit ~]$ qstat | grep balticgrid002 102458.kriit STDIN balticgrid002 0 R balticgrid
- Look for a Worker Node that runs your job.
[mappedUserName@CEHost ~] qstat -f <jobNumber> | grep exec_host exec_host = <WN-name>/0 eg.: [balticgrid002@kriit balticgrid002]$ qstat -f 102461 | grep exec_host exec_host = n191/0
- Connect to a Worker Node
ssh <WN-name>
The Computing Element should be configured to allow the user to log in without password. If it is not a case, you can try to use qsub command.
qsub -I -l host=<WN-name>
3. Getting into job execution directory
- Find a scratch directory of your job
[mappedUserName@<WNHost> ~] $ qstat -f <job-number> | grep SCRATCH_DIRECTORY
SCRATCH_DIRECTORY=<scratch-dir>
eg.:
[balticgrid002@n191 ~] $ qstat -f 102456 | grep SCRATCH_DIRECTORY
SCRATCH_DIRECTORY=/gridhome/balticgrid002//gram_scratch_quMyamA5pg,
- Change directory to an execution directory
Your scratch dir should contain only one subdir. It is your job execution directory. Now, you can check content of all files produced by your job and investigate any problems.
Establishing communication between grid job and User Interface
TBD
