Difference: CsGsiSupport (1 vs. 24)

Revision 242014-01-25 - frank

Line: 1 to 1
 
META TOPICPARENT name="Restricted.ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 102 to 102
  This will enable both authentication (GSI) and encryption for clients connecting to this condor server. Do not forget to create the grid mapfile specified in the above configuration.
Changed:
<
<
For some unknown reason, my grid mapfile must contain an entry for the host cert of cloud scheduler (vm129 in my case), such as:
>
>
The cloud scheduler must contain itself in the grid mapfile to allow the condor daemons to update the queue when the job status changes (ie the jobs finish). Add lines such as:
 
"/C=CA/O=Grid/CN=host/vm129.cloud.nrc.ca" condor@vm129.cloud.nrc.ca
Changed:
<
<
(Replace vm129.cloud.nrc.ca with the hostname of your cloud scheduler host.)
>
>
to you /etc/grid-security/grid-mapfile and replace vm129.cloud.nrc.ca with the hostname of your cloud scheduler host.
  Note that if uses are not listed in the grid mapfile, these users will sill be authenticated and authorized to look at the condor info (READ operations), but will not be allowed to submit any jobs.

Revision 232014-01-06 - rptaylor

Line: 1 to 1
 
META TOPICPARENT name="Restricted.ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 33 to 33
 bffbd7d0
Changed:
<
<

Install GridCanada root CA package

>
>

Install CAs and fetch-crl

 If you haven't done so yet, you will need to install the GridCanada CA root package on your Cloud Scheduler system.
Changed:
<
<
For example:
>
>
Follow these instructions to install the standard EGI trust anchors, which include the GridCanada root CA.
 
Changed:
<
<
as user globus:
wget http://gridcanada.ca/ca/globus_simple_ca_bffbd7d0_setup-0.18.tar.gz
. $GLOBUS_LOCATION/etc/globus-user-env.sh
gpt-build globus_simple_ca_bffbd7d0_setup-0.18.tar.gz gcc64dbg
gpt-postinstall

as root:

$GLOBUS_LOCATION/setup/globus_simple_ca_bffbd7d0_setup/setup-gsi

It is also a good idea to install the GridCanada CA revocation list:

as root:

cd /etc/grid-security/certificates
wget http://gridcanada.ca/ca/bffbd7d0.r0

In order to avoid errors caused by x509 CA root cert hash inconsistencies, it is recommended that you create some simlinks for the new hash of the GridCanada CA root cert, as shown below:

as root:

cd /etc/grid-security/certificates
ln -s bffbd7d0.0 5d674a88.0
ln -s bffbd7d0.signing_policy 5d674a88.signing_policy
ln -s globus-host-ssl.conf.bffbd7d0 globus-host-ssl.conf.5d674a88
ln -s globus-user-ssl.conf.bffbd7d0 globus-user-ssl.conf.5d674a88
ln -s grid-security.conf.bffbd7d0 grid-security.conf.5d674a88
ln -s bffbd7d0.r0 5d674a88.r0
>
>
Now install fetch-crl:
 
Added:
>
>
  • /sbin/chkconfig fetch-crl-boot on
  • /sbin/chkconfig fetch-crl-cron on
  • /etc/init.d/fetch-crl-cron start
 

Install NEP-52 root CA package

Tip, idea If you already have your own CA that you can use to sign your own X509 certificates, you can install your CA package instead.

Revision 222011-05-12 - andrec

Line: 1 to 1
 
META TOPICPARENT name="Restricted.ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 343 to 343
  I suspect this has something to do with the CS cleaning up the job's spooled files (including the user's delegated creds!) when the job is not in the Running state anymore. Probably the CS will have to be updated to recognize the 'C' state and not touch the job's files until it is actually removed from the queue.
Added:
>
>

Renewal of expired proxy

NOTE: This feature is still experimental and available in the following git branch: proxy-replace-feature

The idea is that in order to replace an expired proxy, we do this via another condor job. Let's call this condor job a 'Proxy Replace' job. This Proxy Replace job contains the id of the job which has an expired proxy. The CloudScheduler will detect this 'proxy replace' job, extract the id of the job which has an expired proxy and then copy the current job's proxy over the expired one. The proxy replace job is then immediatly removed from the condor queue.

Scenario:

  • User submits a job and its proxy on the CS expires
  • User does condor_q -l and extracts the GlobalJobId of the job with the expired proxy
  • User constructs a new condor job, that looks like the following:
    Universe   = vanilla
    Executable = /bin/true
    x509userproxy = /tmp/x509up_u20121
    +Owner = UNDEFINED
    Requirements = VMType =?= "xxxx"
    
    +userProxyOverwriteTargetJob = "vm129.cloud.nrc.ca#91.0#1305226680"
    
    Queue
       
  • User submits this new Proxy Replace job to condor
  • Cloud Scheduler replaces the expired job proxy
  • No more expired proxy; User and Cloud Scheduler are happy.

Currently, this only works for running jobs. Jobs that are done (completed) will not be affected. Also, suppot to renew expired proxies for VMs is not yet implemented.

Note that the creation and submission of the Proxy Replace condor job described above can easily be done in a user-friendly command-line tool or via the web portal.

 -- AndreCharbonneau - 2010-08-30

META FILEATTACHMENT attachment="globus_simple_ca_08b380b1_setup-0.20.tar.gz" attr="" comment="NEP-52 CA package (root cert, signing policy, etc...)" date="1300456544" name="globus_simple_ca_08b380b1_setup-0.20.tar.gz" path="globus_simple_ca_08b380b1_setup-0.20.tar.gz" size="216213" user="andrec" version="1"

Revision 212011-03-22 - andrec

Line: 1 to 1
 
META TOPICPARENT name="Restricted.ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 8 to 8
 Enabling GSI support in the cloud scheduler will also put some restrictions on the VM which will only allow jobs from the owner of that VM to be started on it. In other words, jobs owned by user B will not be started on a VM owned by user A. The rationale behind this is to prevent access to a delegated proxy on a VM to other users.
Changed:
<
<

Requirements:

>
>

Requirements

 
  • A cloud scheduler codebase with GSI support
    • Warning, important if you want to renew your certificate via CDS, use the cloud scheduler codebase from the CDS branch
    • merged into dev branch on Sep 13, 2010
Line: 18 to 18
 
  • The user requires a valid grid certificate (x509)
  • The VM images must have a recent version of the condor startup scripts (with generic local condor config support)
Added:
>
>

A note about CA root cert hash values

Note that newest openssl libraries (1.0+) use a different algorithm to compute x509 cert hash values. This can cause some weird authentication failures if you have systems that use different versions of openssl, or some applications which are linked to different versions of openssl (i.e., condor statically linked to openssl 0.9 on a system with openssl 1.0 installed).

You can manually extract the old and new hash values from a CA root cert by using the openssl command as shown below. (You need to have openssl 1.0+ for this to work.)

$ openssl version
OpenSSL 1.0.0c 2 Dec 2010

$ openssl x509 -hash -noout < /etc/grid-security/certificates/5d674a88.0
5d674a88

$ openssl x509 -subject_hash_old -noout < /etc/grid-security/certificates/5d674a88.0
bffbd7d0

Install GridCanada root CA package

If you haven't done so yet, you will need to install the GridCanada CA root package on your Cloud Scheduler system. For example:

as user globus:

wget http://gridcanada.ca/ca/globus_simple_ca_bffbd7d0_setup-0.18.tar.gz
. $GLOBUS_LOCATION/etc/globus-user-env.sh
gpt-build globus_simple_ca_bffbd7d0_setup-0.18.tar.gz gcc64dbg
gpt-postinstall

as root:

$GLOBUS_LOCATION/setup/globus_simple_ca_bffbd7d0_setup/setup-gsi

It is also a good idea to install the GridCanada CA revocation list:

as root:

cd /etc/grid-security/certificates
wget http://gridcanada.ca/ca/bffbd7d0.r0

In order to avoid errors caused by x509 CA root cert hash inconsistencies, it is recommended that you create some simlinks for the new hash of the GridCanada CA root cert, as shown below:

as root:

cd /etc/grid-security/certificates
ln -s bffbd7d0.0 5d674a88.0
ln -s bffbd7d0.signing_policy 5d674a88.signing_policy
ln -s globus-host-ssl.conf.bffbd7d0 globus-host-ssl.conf.5d674a88
ln -s globus-user-ssl.conf.bffbd7d0 globus-user-ssl.conf.5d674a88
ln -s grid-security.conf.bffbd7d0 grid-security.conf.5d674a88
ln -s bffbd7d0.r0 5d674a88.r0
 

Install NEP-52 root CA package

Tip, idea If you already have your own CA that you can use to sign your own X509 certificates, you can install your CA package instead.
Line: 29 to 82
 # $GLOBUS_LOCATION/setup/globus_simple_ca_08b380b1_setup/setup-gsi
Changed:
<
<
old hash value for above CA cert: 63bbbd3b
>
>
IMPORTANT: Note that newest openssl libraries (1.0+) use a different algorithm to compute x509 cert hash values. This can cause some weird authentication failures if you have systems that use different versions of openssl, or some applications which are linked to different versions of openssl (i.e., condor statically linked to openssl 0.9 on a system with openssl 1.0 installed). In order to minimize the chance of running into these kind of errors, I suggest you create a set of symlinks as shown below.

In order to avoid errors caused by x509 CA root cert hash inconsistencies, it is recommended that you create some simlinks for the new hash of our CA root cert, as shown below:

cd /etc/grid-security/certificates
ln -s 08b380b1.0 63bbbd3b.0
ln -s 08b380b1.signing_policy 63bbbd3b.signing_policy
ln -s globus-host-ssl.conf.08b380b1 globus-host-ssl.conf.63bbbd3b
ln -s globus-user-ssl.conf.08b380b1 globus-user-ssl.conf.63bbbd3b
ln -s grid-security.conf.08b380b1 grid-security.conf.63bbbd3b
 

Request dummy host certificate for VM instances

For credential delegation to the worker nodes to work, they need to have a host certificate. Here we simply reuse a dummy host certificate on every VM that will be booted by the cloud scheduler.
Line: 86 to 151
 Then create a proxy and try the command again. The condor_q command should work now.

Configure CA roots in cloud scheduler

Changed:
<
<
We need to specify which CA root certificates and signing policy we need on our VMs. This is done by adding the following to the cloud scheduler config file:
>
>
We need to specify which CA root certificates and signing policy we need on our VMs. In our situation, we have 2: the GridCanada CA root, and our simple CA which is used to sign dummy VM host certs. Note that to avoid conflicts, we put both hash values for each CA root cert.

This is done by adding the following to the cloud scheduler config file:

 
Changed:
<
<
ca_root_certs: /etc/grid-security/certificates/bffbd7d0.0,/etc/grid-security/certificates/08b380b1.0 ca_signing_policies: /etc/grid-security/certificates/bffbd7d0.signing_policy,/etc/grid-security/certificates/08b380b1.signing_policy
>
>
ca_root_certs: /etc/grid-security/certificates/bffbd7d0.0,/etc/grid-security/certificates/5d674a88.0,/etc/grid-security/certificates/08b380b1.0,/etc/grid-security/certificates/63bbbd3b.0

ca_signing_policies: /etc/grid-security/certificates/bffbd7d0.signing_policy,/etc/grid-security/certificates/5d674a88.signing_policy,/etc/grid-security/certificates/08b380b1.signing_policy,/etc/grid-security/certificates/63bbbd3b.signing_policy

 

Configure VM dummy host certificate in cloud scheduler

Line: 277 to 345
  -- AndreCharbonneau - 2010-08-30
Deleted:
<
<
META FILEATTACHMENT attachment="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" attr="" comment="(old CA root package... )" date="1283200693" name="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" path="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" size="214734" user="andrec" version="1"
 
META FILEATTACHMENT attachment="globus_simple_ca_08b380b1_setup-0.20.tar.gz" attr="" comment="NEP-52 CA package (root cert, signing policy, etc...)" date="1300456544" name="globus_simple_ca_08b380b1_setup-0.20.tar.gz" path="globus_simple_ca_08b380b1_setup-0.20.tar.gz" size="216213" user="andrec" version="1"
META TOPICMOVED by="andrec" date="1294867077" from="Restricted.CsGsiSupport" to="Main.CsGsiSupport"

Revision 192011-03-18 - andrec

Line: 1 to 1
 
META TOPICPARENT name="Restricted.ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 86 to 86
 

Configure CA roots in cloud scheduler

We need to specify which CA root certificates and signing policy we need on our VMs. This is done by adding the following to the cloud scheduler config file:
Changed:
<
<
ca_root_certs: /etc/grid-security/bffbd7d0.0,/etc/grid-security/certificates/08b380b1.0 ca_signing_policies: /etc/grid-security/bffbd7d0.signing_policy,/etc/grid-security/certificates/08b380b1.signing_policy
>
>
ca_root_certs: /etc/grid-security/certificates/bffbd7d0.0,/etc/grid-security/certificates/08b380b1.0 ca_signing_policies: /etc/grid-security/certificates/bffbd7d0.signing_policy,/etc/grid-security/certificates/08b380b1.signing_policy
 

Configure VM dummy host certificate in cloud scheduler

Revision 182011-03-18 - andrec

Line: 1 to 1
 
META TOPICPARENT name="Restricted.ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 23 to 23
  On the cloud scheduler host:
Changed:
<
<
$ wget --no-check-certificate https://wiki.heprc.uvic.ca/twiki/pub/Restricted/CsGsiSupport/globus_simple_ca_ebd3459c_setup-0.20.tar.gz $ gpt-build ./globus_simple_ca_ebd3459c_setup-0.20.tar.gz # gpt-postinstall # $GLOBUS_LOCATION/setup/globus_simple_ca_ebd3459c_setup/setup-gsi
>
>
$ wget --no-check-certificate https://wiki.heprc.uvic.ca/twiki/pub/HEPrc/CsGsiSupport/globus_simple_ca_08b380b1_setup-0.20.tar.gz $ gpt-build ./globus_simple_ca_08b380b1_setup-0.20.tar.gz $ gpt-postinstall # $GLOBUS_LOCATION/setup/globus_simple_ca_08b380b1_setup/setup-gsi
 

Request dummy host certificate for VM instances

Line: 34 to 34
  On the cloud scheduler host:
Changed:
<
<
$ mkdir VM-host-cert $ cd VM-host-cert $ grid-cert-request -dir . -host NEP-52_VM_instance -ca
>
>
# mkdir /etc/grid-security/VM-host-cert # cd /etc/grid-security/VM-host-cert # grid-cert-request -dir . -host NEP-52_VM_instance -ca
 
Changed:
<
<
For the time being, the NEP-52 CA is hosted on alto.cloud.nrc.ca. Send the above certificate request to Andre.Charbonneau@nrc-cnrc.gc.ca
>
>
For the time being, the NEP-52 CA is hosted on myproxy.cloud.nrc.ca. Send the above certificate request to Andre.Charbonneau@nrc-cnrc.gc.ca
 If you have your own CA that you can use, simply send this request to your CA to get signed.

Install the signed certificate in the VM-host-cert directory created above.

Line: 48 to 48
  In the condor config on the cloud scheduler host:
Changed:
<
<
SEC_CLIENT_AUTHENTICATION = REQUIRED SEC_CLIENT_AUTHENTICATION_METHODS = GSI SEC_CLIENT_ENCRYPTION = REQUIRED SEC_CLIENT_ENCRYPTION_METHODS = 3DES
>
>
SEC_DEFAULT_AUTHENTICATION = REQUIRED SEC_DEFAULT_AUTHENTICATION_METHODS = GSI SEC_DEFAULT_ENCRYPTION = REQUIRED SEC_DEFAULT_ENCRYPTION_METHODS = 3DES
 GRIDMAP = /etc/grid-security/grid-mapfile.condor This will enable both authentication (GSI) and encryption for clients connecting to this condor server. Do not forget to create the grid mapfile specified in the above configuration.
Line: 86 to 86
 

Configure CA roots in cloud scheduler

We need to specify which CA root certificates and signing policy we need on our VMs. This is done by adding the following to the cloud scheduler config file:
Changed:
<
<
ca_root_certs: /etc/grid-security/bffbd7d0.0,/etc/grid-security/certificates/ebd3459c.0 ca_signing_policies: /etc/grid-security/bffbd7d0.signing_policy,/etc/grid-security/certificates/ebd3459c.signing_policy
>
>
ca_root_certs: /etc/grid-security/bffbd7d0.0,/etc/grid-security/certificates/08b380b1.0 ca_signing_policies: /etc/grid-security/bffbd7d0.signing_policy,/etc/grid-security/certificates/08b380b1.signing_policy
 

Configure VM dummy host certificate in cloud scheduler

Line: 275 to 275
  -- AndreCharbonneau - 2010-08-30
Changed:
<
<
META FILEATTACHMENT attachment="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" attr="" comment="NEP-52 CA package (root cert, signing policy, etc...)" date="1283200693" name="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" path="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" size="214734" stream="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" tmpFilename="/usr/tmp/CGItemp32270" user="andrec" version="1"
>
>
META FILEATTACHMENT attachment="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" attr="" comment="(old CA root package... )" date="1283200693" name="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" path="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" size="214734" user="andrec" version="1"
META FILEATTACHMENT attachment="globus_simple_ca_08b380b1_setup-0.20.tar.gz" attr="" comment="NEP-52 CA package (root cert, signing policy, etc...)" date="1300456544" name="globus_simple_ca_08b380b1_setup-0.20.tar.gz" path="globus_simple_ca_08b380b1_setup-0.20.tar.gz" size="216213" user="andrec" version="1"
 
META TOPICMOVED by="andrec" date="1294867077" from="Restricted.CsGsiSupport" to="Main.CsGsiSupport"

Revision 172011-01-12 - andrec

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="ClosedCanarieProjectNEP52"
>
>
META TOPICPARENT name="Restricted.ClosedCanarieProjectNEP52"
 This page contains information on GSI support in the cloud scheduler.
Line: 10 to 10
 

Requirements:

  • A cloud scheduler codebase with GSI support
Added:
>
>
    • Warning, important if you want to renew your certificate via CDS, use the cloud scheduler codebase from the CDS branch
 
    • merged into dev branch on Sep 13, 2010
  • A working CA is required to sign the dummy VM host certificate.
    • Done. Running on alto.cloud.nrc.ca
Line: 18 to 19
 
  • The VM images must have a recent version of the condor startup scripts (with generic local condor config support)

Install NEP-52 root CA package

Added:
>
>
Tip, idea If you already have your own CA that you can use to sign your own X509 certificates, you can install your CA package instead.
 On the cloud scheduler host:
$ wget --no-check-certificate https://wiki.heprc.uvic.ca/twiki/pub/Restricted/CsGsiSupport/globus_simple_ca_ebd3459c_setup-0.20.tar.gz
Line: 27 to 30
 

Request dummy host certificate for VM instances

Added:
>
>
For credential delegation to the worker nodes to work, they need to have a host certificate. Here we simply reuse a dummy host certificate on every VM that will be booted by the cloud scheduler.
 On the cloud scheduler host:
$ mkdir VM-host-cert
Line: 34 to 39
 $ grid-cert-request -dir . -host NEP-52_VM_instance -ca For the time being, the NEP-52 CA is hosted on alto.cloud.nrc.ca. Send the above certificate request to Andre.Charbonneau@nrc-cnrc.gc.ca
Added:
>
>
If you have your own CA that you can use, simply send this request to your CA to get signed.
 Install the signed certificate in the VM-host-cert directory created above.

Configure GSI Authentication in Condor

Added:
>
>
GSI needs to be enabled at the Condor level. This is required in order to be able to authenticate users via their X509 certificate (proxies).
 In the condor config on the cloud scheduler host:
SEC_CLIENT_AUTHENTICATION = REQUIRED
Line: 267 to 276
 -- AndreCharbonneau - 2010-08-30

META FILEATTACHMENT attachment="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" attr="" comment="NEP-52 CA package (root cert, signing policy, etc...)" date="1283200693" name="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" path="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" size="214734" stream="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" tmpFilename="/usr/tmp/CGItemp32270" user="andrec" version="1"
Added:
>
>
META TOPICMOVED by="andrec" date="1294867077" from="Restricted.CsGsiSupport" to="Main.CsGsiSupport"

Revision 162010-12-07 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 7 to 7
  Enabling GSI support in the cloud scheduler will also put some restrictions on the VM which will only allow jobs from the owner of that VM to be started on it. In other words, jobs owned by user B will not be started on a VM owned by user A. The rationale behind this is to prevent access to a delegated proxy on a VM to other users.
Deleted:
<
<
The GSI support is still in prototype mode and is available under the myproxy-integration-dev branch.
 

Requirements:

  • A cloud scheduler codebase with GSI support
Line: 153 to 152
 In the above job description attributes, replace with the unique name for your credentials in the MyProxy server. Also, if needed, change alto.cloud.nrc.ca in the above command to the name of the MyProxy server for your cloud scheduler.

Refreshing user proxy on worker node

Changed:
<
<
(Note: This section is still experimental and needs to be thoroughly tested. (Andre))
>
>
Condor already will automatically sync the files between the submit machine and the worker, so no additional step is required to have the proxy on the worker refreshed. (see (http://www.cs.wisc.edu/condor/manual/v6.8.0/8_4Development_Release.html) If the user's job has proxy renewal via MyProxy properly configured as per instructions above, then the renewals should propagate automatically to the worker.
 
Changed:
<
<
For long running jobs, it can be required for a job to renew its proxy prior to performing an operation that requires GSI authentication, such as sending results via gridftp. This can be done by using the condor_chirp mechanism, in addition to the credential renewal setup described above. More information about condor_chirp can be found at http://www.cs.wisc.edu/condor/chirp/ . The idea is that we let the cloud scheduler periodically renew the user's proxy spooled on the cloud scheduler system and then on the execute side we will simply make a copy of this user proxy to the user's job environment on demand (the user's job pulls a fresh proxy when needed).
>
>
If for some reasons this does not work for you, then there is a way to do this using the condor_chirp mechanism, as shown below:
 
Changed:
<
<
Refreshing a user proxy must be done in the job's script. An example of a job script that pulls a fresh proxy is shown below:
>
>
Refreshing a user proxy can be done in the job's script. An example of a job script that pulls a fresh proxy is shown below:
 
# Let's pull a fresh proxy from the submit machine.
Line: 193 to 192
  Warning, important It is unclear if the data transfers done by chirp is encrypted or not. Removing the user proxy before doing the chirp call does not affect chirp's behavior; so we can conclude that with the default condor configuration, the user's proxy is not used for authenticating chirp's data transfers. So far, no information about data encryption could be found. It is important to determine this because the user proxy is unencrypted. Still investigating... (Andre)
Deleted:
<
<
Update:

Just found this in the condor release logs:

X509 user proxies are now updated for vanilla universe jobs. If a job specifically sets x509userproxy and is using file transfer, when the proxy file is updated, it will be transfered to the running job. 

Investigating...

 

Interactive VM Configuration

IMPORTANT: This section is not complete and is work in progress...

Revision 152010-12-07 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 193 to 193
  Warning, important It is unclear if the data transfers done by chirp is encrypted or not. Removing the user proxy before doing the chirp call does not affect chirp's behavior; so we can conclude that with the default condor configuration, the user's proxy is not used for authenticating chirp's data transfers. So far, no information about data encryption could be found. It is important to determine this because the user proxy is unencrypted. Still investigating... (Andre)
Added:
>
>
Update:

Just found this in the condor release logs:

X509 user proxies are now updated for vanilla universe jobs. If a job specifically sets x509userproxy and is using file transfer, when the proxy file is updated, it will be transfered to the running job. 

Investigating...

 

Interactive VM Configuration

IMPORTANT: This section is not complete and is work in progress...

Revision 142010-12-07 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 162 to 162
 
# Let's pull a fresh proxy from the submit machine.
PROXY_ON_SUBMIT_MACHINE=$(basename $X509_USER_PROXY)
Changed:
<
<
condor_chirp fetch $PROXY_ON_SUBMIT_MACHINE $X509_USER_PROXY
>
>
/usr/libexec/condor/condor_chirp fetch $PROXY_ON_SUBMIT_MACHINE $X509_USER_PROXY
  # Calls that need fresh grid proxy, such as gridftp, goes here...
Line: 172 to 172
 +WantIOProxy = true
Added:
>
>
else you will get an error like:
Can't open /var/lib/condor/execute/dir_1441/chirp.config file
cannot chirp_connect to shadow
 Tip, idea Note: Note that the refreshed proxy on the execute side will be slightly different than the original one put there by condor when the job started. This can be seen by looking at the output of the openssl x509 command, as shown below:

  • before calling condor_chirp:
Line: 185 to 191
  The reason is that when condor put it there when the job starts, condor actually 'delegates' it there. When we run condor_chirp to fetch the proxy directly from the submit machine, we get the proxy as-is on the submit machine, without doing any delegation. This is a technicality and should be transparent to the end user.
Added:
>
>
Warning, important It is unclear if the data transfers done by chirp is encrypted or not. Removing the user proxy before doing the chirp call does not affect chirp's behavior; so we can conclude that with the default condor configuration, the user's proxy is not used for authenticating chirp's data transfers. So far, no information about data encryption could be found. It is important to determine this because the user proxy is unencrypted. Still investigating... (Andre)
 

Interactive VM Configuration

IMPORTANT: This section is not complete and is work in progress...

Revision 132010-12-06 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 153 to 153
 In the above job description attributes, replace with the unique name for your credentials in the MyProxy server. Also, if needed, change alto.cloud.nrc.ca in the above command to the name of the MyProxy server for your cloud scheduler.

Refreshing user proxy on worker node

Changed:
<
<
(Note: This section is still experimental and not yet working.... ) For long running jobs, it can be required for a job to renew its proxy prior to performing an operation that requires GSI authentication, such as sending results via gridftp. This can be done by using the condor_chirp mechanism. More information about condor_chirp can be found at http://www.cs.wisc.edu/condor/chirp/ . The idea is that the cloud scheduler will periodically renew the user's proxy spooled on the cloud scheduler system and that we will simply make a copy of this user proxy to the user's job environment on demand (the user's job pulls a fresh proxy when needed).
>
>
(Note: This section is still experimental and needs to be thoroughly tested. (Andre))

For long running jobs, it can be required for a job to renew its proxy prior to performing an operation that requires GSI authentication, such as sending results via gridftp. This can be done by using the condor_chirp mechanism, in addition to the credential renewal setup described above. More information about condor_chirp can be found at http://www.cs.wisc.edu/condor/chirp/ . The idea is that we let the cloud scheduler periodically renew the user's proxy spooled on the cloud scheduler system and then on the execute side we will simply make a copy of this user proxy to the user's job environment on demand (the user's job pulls a fresh proxy when needed).

  Refreshing a user proxy must be done in the job's script. An example of a job script that pulls a fresh proxy is shown below:
Added:
>
>
 
Added:
>
>
# Let's pull a fresh proxy from the submit machine. PROXY_ON_SUBMIT_MACHINE=$(basename $X509_USER_PROXY) condor_chirp fetch $PROXY_ON_SUBMIT_MACHINE $X509_USER_PROXY

# Calls that need fresh grid proxy, such as gridftp, goes here...

 
Added:
>
>
In order to be able to use condor_chirp from your job script, you need to put the following in your job classad:
+WantIOProxy = true

Tip, idea Note: Note that the refreshed proxy on the execute side will be slightly different than the original one put there by condor when the job started. This can be seen by looking at the output of the openssl x509 command, as shown below:

  • before calling condor_chirp:
            Subject: C=CA, O=Grid, OU=sao.nrc.ca, CN=Andre Charbonneau, CN=proxy, CN=limited proxy, CN=limited proxy
       
  • after calling condor_chirp:
            Subject: C=CA, O=Grid, OU=sao.nrc.ca, CN=Andre Charbonneau, CN=proxy, CN=limited proxy
       

The reason is that when condor put it there when the job starts, condor actually 'delegates' it there. When we run condor_chirp to fetch the proxy directly from the submit machine, we get the proxy as-is on the submit machine, without doing any delegation. This is a technicality and should be transparent to the end user.

 

Interactive VM Configuration

IMPORTANT: This section is not complete and is work in progress...

Revision 122010-12-02 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 153 to 153
 In the above job description attributes, replace with the unique name for your credentials in the MyProxy server. Also, if needed, change alto.cloud.nrc.ca in the above command to the name of the MyProxy server for your cloud scheduler.

Refreshing user proxy on worker node

Added:
>
>
(Note: This section is still experimental and not yet working.... )
 For long running jobs, it can be required for a job to renew its proxy prior to performing an operation that requires GSI authentication, such as sending results via gridftp. This can be done by using the condor_chirp mechanism. More information about condor_chirp can be found at http://www.cs.wisc.edu/condor/chirp/ . The idea is that the cloud scheduler will periodically renew the user's proxy spooled on the cloud scheduler system and that we will simply make a copy of this user proxy to the user's job environment on demand (the user's job pulls a fresh proxy when needed).

Refreshing a user proxy must be done in the job's script. An example of a job script that pulls a fresh proxy is shown below:

Revision 112010-12-02 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 116 to 116
 

Credential renewal

The cloud scheduler implements job credential renewal via a MyProxy server. The idea is simple: the user first puts a long lived proxy a MyProxy server prior to submitting a job and then puts the proxy information in the job description. Periodically, the cloud scheduler will scan all the jobs proxy certificates and attempt to renew those which are about to expire.
Changed:
<
<
Note that this proxy renewal feature will only renew proxies that reside on the cloud scheduler.
>
>
Note that this proxy renewal feature will only renew proxies that reside on the cloud scheduler. User proxies delegated to the worker nodes by Condor will not be automatically renewed.
  To use automatic credential renewal, follow the instructions below:

Configure cloud scheduler to enable credential renewal

Line: 152 to 152
  In the above job description attributes, replace with the unique name for your credentials in the MyProxy server. Also, if needed, change alto.cloud.nrc.ca in the above command to the name of the MyProxy server for your cloud scheduler.
Added:
>
>

Refreshing user proxy on worker node

For long running jobs, it can be required for a job to renew its proxy prior to performing an operation that requires GSI authentication, such as sending results via gridftp. This can be done by using the condor_chirp mechanism. More information about condor_chirp can be found at http://www.cs.wisc.edu/condor/chirp/ . The idea is that the cloud scheduler will periodically renew the user's proxy spooled on the cloud scheduler system and that we will simply make a copy of this user proxy to the user's job environment on demand (the user's job pulls a fresh proxy when needed).

Refreshing a user proxy must be done in the job's script. An example of a job script that pulls a fresh proxy is shown below:

 

Interactive VM Configuration

IMPORTANT: This section is not complete and is work in progress...

Revision 102010-11-18 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 171 to 171
 vm129:/usr/local/condor # cat /etc/grid-security/grid-mapfile.condor "/C=CA/O=Grid/OU=sao.nrc.ca/CN=Andre Charbonneau" andre@cloud.nrc.ca
Changed:
<
<
    • For some reason, the user account on the interactive VM must match the user in the mapfile. For example:
>
>

Job submission on VM

  • Since the submit machine is not the same as the CS, then we need to spool the files (including the user's creds). This is done by giving the -spool command line argument to the condor_submit command.
  • Since we cannot assume that the user account on the VM will match the user in the condor grid-mapfile on the CS, we need to add the following to the job classads on the interactive VM:
    +Owner = UNDEFINED
          
    else you will get an error similar to:
 
[babar@vm135 test]$ condor_submit -spool ./job.andre.txt 
Submitting job(s)
Line: 179 to 186
  ERROR: Failed to queue job.
Changed:
<
<
Update
Since the username on the submit machine is different than on the condor server, we need to put the following in the job's classad:
>
>
  • Once the job is complete, it should reach the 'C' state, as shown below:
 
Changed:
<
<
+Owner = UNDEFINED
>
>
[babar@vm135 test]$ condor_q

-- Submitter: vm129.cloud.nrc.ca : <132.246.148.29:8080> : vm129.cloud.nrc.ca ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 6924.0 andre 11/18 09:58 0+00:01:02 C 0 4.2 script.sh

0 jobs; 0 idle, 0 running, 0 held

  • Then you can use the condor tools to fetch the job output files, as shown below:
    [babar@vm135 test]$ condor_transfer_data -all
    Fetching data files...
    
    [babar@vm135 test]$ cat test.out
    vm140.cloud.nrc.ca
 
Changed:
<
<
Then it works.
>
>
This was tested without a proxy, and the call fails (which is what we want).
  • Then you can remove the finished job:
    [babar@vm135 test]$ condor_rm 6924.0
    Job 6924.0 marked for removal
       

Note:

For some reason, I get an error if I run cloud-status to see if my image is indeed shutdown:
andre@vm129:~> cloud_status -m
ID          HOSTNAME                VMTYPE     STATUS   CLUSTER                
17007                               ur.vm.type Error    alto.cloud.nrc.ca      

Total VMs: 1. Total Clouds: 1

I suspect this has something to do with the CS cleaning up the job's spooled files (including the user's delegated creds!) when the job is not in the Running state anymore. Probably the CS will have to be updated to recognize the 'C' state and not touch the job's files until it is actually removed from the queue.

  -- AndreCharbonneau - 2010-08-30

Revision 82010-11-17 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 152 to 152
  In the above job description attributes, replace with the unique name for your credentials in the MyProxy server. Also, if needed, change alto.cloud.nrc.ca in the above command to the name of the MyProxy server for your cloud scheduler.
Added:
>
>

Interactive VM Configuration

IMPORTANT: This section is not complete and is work in progress...

Condor configuration on VM

  • SCHEDD_HOST = mycloudscheduler.cloud.nrc.ca
  • COLLECTOR_HOST = mycloudscheduler.cloud.nrc.ca
  • DAEMON_LIST = MASTER

GSI configuration on VM

  • valid user's proxy in /tmp/x509_uXXXX (tested without and GSI auth fails...)
  • valid host cert in /etc/grid-security not required (tested without and it makes no difference)
  • GridCanada root CA files in /etc/grid-security/certificates

GSI configuration on CS

  • Condor's grid mapfile must contain an entry for the user's DN. For example:
    vm129:/usr/local/condor # cat /etc/grid-security/grid-mapfile.condor 
    "/C=CA/O=Grid/OU=sao.nrc.ca/CN=Andre Charbonneau" andre@cloud.nrc.ca
       
    • For some reason, the user account on the interactive VM must match the user in the mapfile. For example:
      [babar@vm135 test]$ condor_submit -spool ./job.andre.txt 
      Submitting job(s)
      ERROR: Failed to set Owner="babar" for job 6916.0 (13)
      
      ERROR: Failed to queue job.
            
  -- AndreCharbonneau - 2010-08-30

Revision 72010-10-05 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 116 to 116
 

Credential renewal

The cloud scheduler implements job credential renewal via a MyProxy server. The idea is simple: the user first puts a long lived proxy a MyProxy server prior to submitting a job and then puts the proxy information in the job description. Periodically, the cloud scheduler will scan all the jobs proxy certificates and attempt to renew those which are about to expire.
Added:
>
>
Note that this proxy renewal feature will only renew proxies that reside on the cloud scheduler.
 To use automatic credential renewal, follow the instructions below:

Configure cloud scheduler to enable credential renewal

Edit the following cloud scheduler configuration parameters in your cloud_scheduler.conf file:

Revision 62010-10-04 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Added:
>
>
  GSI support in the cloud scheduler allows a user to authenticate using his/her grid certificate when submitting a job to the cloud scheduler. The cloud scheduler will then use these credentials for authenticating the Nimbus workspace creation and workspace deletion.
Line: 113 to 114
 $ condor_submit <job-description-file>

Credential renewal

Changed:
<
<
NOT IMPLEMENTED YET Since proxy renewal has not been implemented yet, the users will have to create proxy that have a long enough lifetime to cover the execution of their jobs.
>
>
The cloud scheduler implements job credential renewal via a MyProxy server. The idea is simple: the user first puts a long lived proxy a MyProxy server prior to submitting a job and then puts the proxy information in the job description. Periodically, the cloud scheduler will scan all the jobs proxy certificates and attempt to renew those which are about to expire.

To use automatic credential renewal, follow the instructions below:

Configure cloud scheduler to enable credential renewal

Edit the following cloud scheduler configuration parameters in your cloud_scheduler.conf file:
# job_proxy_refresher_interval specifies the amount of time, in seconds, between each job proxy
# credential expiry checks.  To disable proxy refreshing altogether, simply set this
# value to -1
#
# The default value is -1
#job_proxy_refresher_interval: -1

# job_proxy_renewal_threshold determines the amount of time, in seconds, 
# prior to proxy expiry date at which a proxy will be refreshed
#
# The default value is 900 (15 minutes)
#job_proxy_renewal_threshold: 900

Put a long-lived proxy to a MyProxy server

Prior to submitted one or more long lived job, the user should run a command like the following:
myproxy-init -R 'host/<cloud_scheduler_host>' -k <creds_name> -s alto.cloud.nrc.ca -d
In the above command, replace with the FQHN of your cloud scheduler and with unique name for your credentials in the MyProxy server. Also, if needed, change alto.cloud.nrc.ca in the above command to the name of the MyProxy server for your cloud scheduler (contact your system administrator if you are not sure what value to use for the MyProxy server).

The default lifetime of the delegated credentials on the MyProxy server is one week. If you want a different lifetime, specify it using the -c command line argument to the myproxy-init command shown above.

Add MyProxy info to job description

The user must put the following information in his/her job description:
+CSMyProxyServer     = alto.cloud.nrc.ca
+CSMyProxyCredsName  = <creds_name>
In the above job description attributes, replace with the unique name for your credentials in the MyProxy server. Also, if needed, change alto.cloud.nrc.ca in the above command to the name of the MyProxy server for your cloud scheduler.
 

-- AndreCharbonneau - 2010-08-30

Revision 52010-09-13 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 10 to 10
 

Requirements:

  • A cloud scheduler codebase with GSI support
Changed:
<
<
    • checkout from myproxy-integration-dev branch
>
>
    • merged into dev branch on Sep 13, 2010
 
  • A working CA is required to sign the dummy VM host certificate.
    • Done. Running on alto.cloud.nrc.ca
  • A working Globus Toolkit is required on the host running the cloud scheduler.

Revision 42010-09-08 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 99 to 99
 

Testing

Restart the cloud scheduler

Changed:
<
<

Create a user proxy (full legacy)

>
>

Create a user proxy (full legacy). Make sure it's lifetime will cover the duration of the job.

 
Changed:
<
<
$ grid-proxy-init -old
>
>
$ grid-proxy-init -old [-valid HH:MM]
 

Add x509 proxy info in your job description

In order to use GSI authentication, you need to specify your user proxy in your job description. This is done using the x509userproxy classad attribute. For example:
Line: 114 to 114
 

Credential renewal

NOT IMPLEMENTED YET
Added:
>
>
Since proxy renewal has not been implemented yet, the users will have to create proxy that have a long enough lifetime to cover the execution of their jobs.
 

-- AndreCharbonneau - 2010-08-30

Revision 32010-08-31 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.
Line: 6 to 6
  Enabling GSI support in the cloud scheduler will also put some restrictions on the VM which will only allow jobs from the owner of that VM to be started on it. In other words, jobs owned by user B will not be started on a VM owned by user A. The rationale behind this is to prevent access to a delegated proxy on a VM to other users.
Added:
>
>
The GSI support is still in prototype mode and is available under the myproxy-integration-dev branch.
 

Requirements:

Added:
>
>
  • A cloud scheduler codebase with GSI support
    • checkout from myproxy-integration-dev branch
 
  • A working CA is required to sign the dummy VM host certificate.
Added:
>
>
    • Done. Running on alto.cloud.nrc.ca
 
  • A working Globus Toolkit is required on the host running the cloud scheduler.
  • The user requires a valid grid certificate (x509)
Added:
>
>
  • The VM images must have a recent version of the condor startup scripts (with generic local condor config support)
 

Install NEP-52 root CA package

Added:
>
>
On the cloud scheduler host:
 
Changed:
<
<
$ wget https://wiki.heprc.uvic.ca/twiki/pub/Restricted/CsGsiSupport/globus_simple_ca_ebd3459c_setup-0.20.tar.gz
>
>
$ wget --no-check-certificate https://wiki.heprc.uvic.ca/twiki/pub/Restricted/CsGsiSupport/globus_simple_ca_ebd3459c_setup-0.20.tar.gz
 $ gpt-build ./globus_simple_ca_ebd3459c_setup-0.20.tar.gz # gpt-postinstall # $GLOBUS_LOCATION/setup/globus_simple_ca_ebd3459c_setup/setup-gsi
Line: 26 to 33
 $ cd VM-host-cert $ grid-cert-request -dir . -host NEP-52_VM_instance -ca
Changed:
<
<
For the time being, the NEP-52 CA is hosted on alto.cloud.nrc.ca. Send the above certificate request to Andre.Charbonneau@nrc-cnrc.gc.ca
>
>
For the time being, the NEP-52 CA is hosted on alto.cloud.nrc.ca. Send the above certificate request to Andre.Charbonneau@nrc-cnrc.gc.ca
 Install the signed certificate in the VM-host-cert directory created above.

Configure GSI Authentication in Condor

Line: 38 to 45
 SEC_CLIENT_ENCRYPTION_METHODS = 3DES GRIDMAP = /etc/grid-security/grid-mapfile.condor
Changed:
<
<
This will enable both authentication (GSI) and encryption for clients connecting to this condor server. Do not forget to create the grid mapfile specified in the above configuration. If you do not create the grid mapfile, users will sill be authenticated and authorized to ues the services, but will be mapped to gsi@unmappeduser.
>
>
This will enable both authentication (GSI) and encryption for clients connecting to this condor server. Do not forget to create the grid mapfile specified in the above configuration.

For some unknown reason, my grid mapfile must contain an entry for the host cert of cloud scheduler (vm129 in my case), such as:

"/C=CA/O=Grid/CN=host/vm129.cloud.nrc.ca" condor@vm129.cloud.nrc.ca
(Replace vm129.cloud.nrc.ca with the hostname of your cloud scheduler host.)

Note that if uses are not listed in the grid mapfile, these users will sill be authenticated and authorized to look at the condor info (READ operations), but will not be allowed to submit any jobs.

  In order to the changes to take effect, you need to restart condor:
Line: 82 to 97
 /usr/local/nimbus/services/etc/nimbus/nimbus-grid-mapfile
Changed:
<
<

Add x509 proxy info in your job description

>
>

Testing

Restart the cloud scheduler

Create a user proxy (full legacy)

$ grid-proxy-init -old

Add x509 proxy info in your job description

 In order to use GSI authentication, you need to specify your user proxy in your job description. This is done using the x509userproxy classad attribute. For example:
x509userproxy = /tmp/x509up_u20200
Changed:
<
<
>
>

Submit the job

$ condor_submit <job-description-file>
 

Credential renewal

NOT IMPLEMENTED YET

Revision 22010-08-31 - andrec

Line: 1 to 1
 
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.

GSI support in the cloud scheduler allows a user to authenticate using his/her grid certificate when submitting a job to the cloud scheduler. The cloud scheduler will then use these credentials for authenticating the Nimbus workspace creation and workspace deletion.

Added:
>
>
Enabling GSI support in the cloud scheduler will also put some restrictions on the VM which will only allow jobs from the owner of that VM to be started on it. In other words, jobs owned by user B will not be started on a VM owned by user A. The rationale behind this is to prevent access to a delegated proxy on a VM to other users.
 

Requirements:

  • A working CA is required to sign the dummy VM host certificate.
  • A working Globus Toolkit is required on the host running the cloud scheduler.
Line: 23 to 26
 $ cd VM-host-cert $ grid-cert-request -dir . -host NEP-52_VM_instance -ca
Added:
>
>
For the time being, the NEP-52 CA is hosted on alto.cloud.nrc.ca. Send the above certificate request to Andre.Charbonneau@nrc-cnrc.gc.ca Install the signed certificate in the VM-host-cert directory created above.

Configure GSI Authentication in Condor

In the condor config on the cloud scheduler host:
SEC_CLIENT_AUTHENTICATION = REQUIRED
SEC_CLIENT_AUTHENTICATION_METHODS = GSI
SEC_CLIENT_ENCRYPTION = REQUIRED
SEC_CLIENT_ENCRYPTION_METHODS = 3DES
GRIDMAP = /etc/grid-security/grid-mapfile.condor
This will enable both authentication (GSI) and encryption for clients connecting to this condor server. Do not forget to create the grid mapfile specified in the above configuration. If you do not create the grid mapfile, users will sill be authenticated and authorized to ues the services, but will be mapped to gsi@unmappeduser.

In order to the changes to take effect, you need to restart condor:

# /etc/init.d/condor stop
# /etc/init.d/condor start

To test that GSI authentication is actually enabled, try to run the condor_q command without a user proxy. You should get an error message, such as shown below:

$ grid-proxy-destroy
$ condor_q

-- Failed to fetch ads from: <132.246.148.29:8080> : vm129.cloud.nrc.ca
AUTHENTICATE:1003:Failed to authenticate with any method
AUTHENTICATE:1004:Failed to authenticate using GSI
GSI:5003:Failed to authenticate.  Globus is reporting error (851968:28).  There is probably a problem with your credentials.  (Did you run grid-proxy-init?)

Then create a proxy and try the command again. The condor_q command should work now.

Configure CA roots in cloud scheduler

We need to specify which CA root certificates and signing policy we need on our VMs. This is done by adding the following to the cloud scheduler config file:
ca_root_certs: /etc/grid-security/bffbd7d0.0,/etc/grid-security/certificates/ebd3459c.0
ca_signing_policies: /etc/grid-security/bffbd7d0.signing_policy,/etc/grid-security/certificates/ebd3459c.signing_policy

Configure VM dummy host certificate in cloud scheduler

cert_file: /home/andre/work/cloud-scheduler/VM_host_cert/hostcert.pem
cert_file_on_vm: /etc/grid-security/hostcert.pem

key_file: /home/andre/work/cloud-scheduler/VM_host_cert/hostkey.pem
key_file_on_vm: /etc/grid-security/hostkey.pem

Configure the nimbus grid-mapfile on the cloud servers

Make sure that the authorized users DN are added to the Nimbus grid mapfiles on the cloud server that this user is allowed to use. For example, on alto.cloud.nrc.ca, this is in the following file:
/usr/local/nimbus/services/etc/nimbus/nimbus-grid-mapfile

Add x509 proxy info in your job description

In order to use GSI authentication, you need to specify your user proxy in your job description. This is done using the x509userproxy classad attribute. For example:
x509userproxy = /tmp/x509up_u20200

Credential renewal

NOT IMPLEMENTED YET
 
Deleted:
<
<
TODO: Finish this documentation... (Andre)
 -- AndreCharbonneau - 2010-08-30

META FILEATTACHMENT attachment="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" attr="" comment="NEP-52 CA package (root cert, signing policy, etc...)" date="1283200693" name="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" path="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" size="214734" stream="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" tmpFilename="/usr/tmp/CGItemp32270" user="andrec" version="1"

Revision 12010-08-30 - andrec

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="ClosedCanarieProjectNEP52"
This page contains information on GSI support in the cloud scheduler.

GSI support in the cloud scheduler allows a user to authenticate using his/her grid certificate when submitting a job to the cloud scheduler. The cloud scheduler will then use these credentials for authenticating the Nimbus workspace creation and workspace deletion.

Requirements:

  • A working CA is required to sign the dummy VM host certificate.
  • A working Globus Toolkit is required on the host running the cloud scheduler.
  • The user requires a valid grid certificate (x509)

Install NEP-52 root CA package

$ wget https://wiki.heprc.uvic.ca/twiki/pub/Restricted/CsGsiSupport/globus_simple_ca_ebd3459c_setup-0.20.tar.gz
$ gpt-build ./globus_simple_ca_ebd3459c_setup-0.20.tar.gz <flavor>
# gpt-postinstall
# $GLOBUS_LOCATION/setup/globus_simple_ca_ebd3459c_setup/setup-gsi

Request dummy host certificate for VM instances

On the cloud scheduler host:
$ mkdir VM-host-cert
$ cd VM-host-cert
$ grid-cert-request -dir . -host NEP-52_VM_instance -ca

TODO: Finish this documentation... (Andre) -- AndreCharbonneau - 2010-08-30

META FILEATTACHMENT attachment="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" attr="" comment="NEP-52 CA package (root cert, signing policy, etc...)" date="1283200693" name="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" path="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" size="214734" stream="globus_simple_ca_ebd3459c_setup-0.20.tar.gz" tmpFilename="/usr/tmp/CGItemp32270" user="andrec" version="1"
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback