OGSITestbed Project

1
OGSITestbed Project
General meeting 04-Feb-2004 London University
of Westminster
2
Structure of this presentation
An OGSI design architecture for enabling parallel
legacy code to the grid (Thierry/Ariel)
Experiences with Condor with GT3 (Thierry)
Security Mad City approach (Raj)
Achievements / Live Demo (Ariel/Thierry)
3
Objectives of the work at UoW

• To make available parallel legacy code to the
  grid without having to re-engineer existing code.
  We are focussing on an existing parallel traffic
  simulator called MadCity.
• To ensure that the parallel execution of the
  legacy code maps to the respective grid
  credential of the users requesting the code to be
  executed (using grid-mapfile).
• Single sign-on using grid credential for
  submitting jobs, uploading and downloading data.
• Grid client can be off-line or on-line when user
  is waiting for compute jobs to complete.

4
Design architecture for enablingparallel legacy
code to the grid using OGSI
Done (event notification)
GT3 master node Tomcat server
Client machine
Condor cluster
Grid mapfile
node
node
node
Job process
Job process
ogsa container
proc
user container

• OGSI Grid client
• (using proxy delegation)
• upload program/inputs
• submit job
• check status of job
• download results

OGSI Grid service
OGSI Grid service
SOAP/XML
MMJFS
Grid execution manager for parallel legacy code
Central manager node
Use Batch Mode
Pending
Condor daemon
Condor job manager
RFT (reliable file transfer GS)
Local file system
Local file system
User proxy
Local file system
5
Progress so far

• Concept of the design architecture has been
  demonstrated by implementing a secure grid client
  and secure grid service
• The grid client uses full proxy delegation
• The grid service submits a job in batch mode to
  MMJFS using GramJob client API
• The RSL specifies the Fork JM and the execution
  of /usr/bin/id a to verify that the user id of
  the executed process maps to the callers grid
  certificate subject.
• CondorIntelLinux job manager working as well as
  able to submit condor jobs using PVM Universe.

6
Future development

• Implement full life-cycle of the client
  functionalities (e.g. upload data, submit, check,
  download data, etc)
• Implement data transfer capability for managing
  input and output data.

7
Experiences with Condor with GT3

• (1) Problem
• CondorIntelLinux Job manager broken with GT3.0.2
• (condor.pm corruped - bugid 1425)
• Solution
• Install fix for bugid 1425 (fix available before
  Xmas)
• gpt-build -force -update globus_gram_job_manager_s
  etup_condor-1.4.tar.gz
• (2) Problem
• Unability to set Condor PVM Universe in RSL file
  using native RSL features (same for problem for
  RSL v2 but needs an equivalent for RSL v3).
• (jobtypecondor)
• (condorsubmit(universe PVM)(machine_count
  4..4))
• (2) Solution
• Use condor hash table in RSL xml file to set
  particular condor features such as PVM Universe

8
GT3 RSL input file for Condor JM

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltrslrsl ... "gt
• ltgramjobgt
• ltgramexecutablegt
• ltrslpathgtltrslstringElement value"/usr/bin/id"/
  gt
• lt/gramexecutablegt
• ...
• ltcondorcondorSubmitgt
• ltrslhashtablegt
• ltrslentry name"Executable"gt
• ltrslstringElement value"/home/delaitt/.grade-pro
  jects/madgrade/LINUX/madgrade"/gt
• ltrslentry name"Universe"gt ltrslstringElement
  value"PVM"/gt lt/rslentrygt
• ltrslentry name"machine_count"gt
  ltrslstringElement value"5..5"/gt lt/rslentrygt
• ltrslentry name"notify_user"gt ltrslstringElement
  value"email_at_cpc.wmin.ac.uk"/gt lt/rslentrygt
• ltrslentry name"Arguments"gt
• ltrslstringElement value"-e 850dca50-829d-4b1f-84
  23-2cafe3d12e15 -n -b condor -p -m"/gt
• lt/rslentrygt
• ltrslentry name"Initialdir"gt

9
Submitting GT3 job to Condor JM
delaitt_at_node40 delaitt managed-globus-jobrun
type CondorIntelLinux file myfile.xml WAITING
FOR JOB TO FINISH Status Notification
Job Status Pending
Status
Notification Job Status
Done DES
TROYING SERVICE SERVICE DESTROYED delaitt_at_node40
delaitt condor_q condor_status
run Submitter node40.cluster.cpc.wmin.ac.uk
lt161.74.87.5643369gt node40ID OWNER
SUBMITTED RUN_TIME ST PRI
SIZE CMD 99.0 delaitt 1/19 1446
0000026 R 0 1.0 madgrade -e 850dca 1
jobs 0 idle, 1 running, 0 held Name
OpSys Arch LoadAv RemoteUser
ClientMachine node01.cluste LINUX INTEL
0.000 delaitt_at_cluster.cpc. node40.cluster. node04
.cluste LINUX INTEL 0.080
delaitt_at_cluster.cpc. node40.cluster. node05.cluste
LINUX INTEL 0.080 delaitt_at_cluster.cpc.
node40.cluster. node10.cluste LINUX INTEL
0.150 delaitt_at_cluster.cpc. node40.cluster. node14
.cluste LINUX INTEL 0.150
delaitt_at_cluster.cpc. node40.cluster.

10
Security Mad City approach Part 4/5 (Thierry
Delaitre)
11
GT3 Security Definitions

• GT3 uses the different components of its Grid
  Security infrastructure (GSI) to provide certain
  levels of security.
• Authentication
• A process used to determine a user's
  identity, as well as determining what the user is
  authorized to access.Digital signature and
  Digital Certificates are often used to more
  accurately identify the user.
• Authorization
• Process of determining whether a subject
  is allowed to have the specified types of access
  to a particular resource. Once a subject is
  authenticated, it may be authorized to perform
  different types of access.
• Delegation
• Ability for client/proxy to delegate its
  credentials to a service which, in turn, uses
  those credentials to invoke a different service.
  The service will set the delegated credentials
  as its identity

12
Our Security Objectives

• To enable only authorised people to access our
  services.
• Authentication and Authorization
• To enable jobs to be executed on the cluster on
  behalf of the caller.
• Delegation

13
OGSI MadCity Approach
Master Node (GT3)
MMJFS (GT3)
OGSI Client
Client Side Security 1. Authentication Mode
stub._setProperty(Constants.GSI_SEC_CONV,
Constants.SIGNATURE) 2. Credential Delegation
Modestub._setProperty(GSIConstants.GSI_MODE,GSICo
nstants.GSI_MODE_FULL_DELEG)
Server Side Security 1. Security
Deployment Descriptor ltparameter
name"securityConfig" valuemy-security-config.xm
l"/gt 2. Service Authorization Settings
ltparameter name"authorization" value"gridmap"/gt
3. Service Credentials ltparameter name
serviceProxy value ltproxy filegt/gt 4.
Delegation SecurityManager.getManager().setSer
viceOwnerFromContext()
14
Achievements/problems/future Part 5/5 (Ariel
Goyeneche)
15
Achievements

• Deliverables
• Experiences with GT3 and Tomcat
• Experiences with GT3 and Condor
• Experiences with GT3 firewall issues
• Installation of GT3
• GT3 Security document
• Survey of GT3 tools for data management
• GT3 Installation
• Experiences with multiple Tomcat webapps
• Installed GT3.2 Alpha (more stable)
• Experiences with CondorIntelLinux JM
• GT3 Programming
• Experiences with MMJFS GramJob
• Experiences with message level security (proxy
  delegation)