Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Fedcloud-tf:CLI Environment

From EGIWiki
Jump to navigation Jump to search
Main Roadmap and Innovation Technology For Users For Resource Providers Media



This guide provides the information on how to setup a FedCloud command-line environment (using the Ruby OCCI Framework)

Setting up a command line structure basically consists of the following phases:

  1. Security setup
  2. Set up (r)OCCI tools
  3. Test environmet

Read further below on more details for each step.

Security setup

This section is the most fragile bit of the setup. It consists of setting up the following components:

  1. Obtain a Grid user certificate
  2. Configure the certificate based trust anchors
  3. Join the FedCloud Virtual Organisation
  4. Install VO client tools
  5. Configure VO membership information

Obtain a Grid user certificate

This step is fairly straight-forward in terms of processes. The goal is to obtain a digital certificate that is signed by a given certification authority, vouching for the validity of your real life identity encoded into the digital certificate issued to you.

Although each Certification Authority (including their affiliated Registration Authorities) follow individual procedures, you will eventually end up with a personal digital Grid certificate. More information on how to obtain a Grid certificate is available on the EGI website.

In any way, you now have (a) a digital certificate, and (b) a private key. Certificates use a cryptography technology called public key cryptography. Without going too much into details, the public key is contained in your certificate, and can be used and obtained by everyone on the Internet (including Grids and Clouds). It is safe to publish the public key (that's why it is called "public key"). There is exactly one pendant complementing the public key, and that is the private key. You must keep this private key safe at all circumstances, as it is the only token with which you can ensure that the identity stored in your certificate is you. Anyone who possesses the private key can claim your identity!

However, once you have obtained your certificate (during the Grid certificate enrolment process, your computer has generated the public and the private key), you will have those two digital files. To conclude the first step of setting up your security environment, you need to ensure that both are safely stored in your home directory as follows:

$ ls -al ~/.globus
total 48
drwxr-xr-x    14 michel  staff    476 Mar  7 13:57 .
drwxr-xr-x+   73 michel  staff   2482 Apr  3 11:41 ..
drwxr-xr-x     6 michel  staff    204 Oct 22  2011 user-cert-20111020-00
drwxr-xr-x     5 michel  staff    170 Oct 22  2011 user-cert-20111022-00
drwxr-xr-x     6 michel  staff    204 Oct 15 16:32 user-cert-20120924-00
-rw-r--r--     1 michel  staff   1765 Feb  5 20:07 usercert.pem
-r--------     1 michel  staff   1751 Feb  5 20:07 userkey.pem
-rw-r--r--     1 michel  staff   3254 Oct 20  2011 userrequest.pem

Notes:

  1. File userkey.pem is your encoded and encrypted private key - you can access it only with a password that you have used during enrolling for a certificate.
  2. File userkey.pem must have the shown permissions, i.e. that only the current user can read its contents, and nothing else. Other tools will depend on this setting.
  3. File usercert.pem contains your user certificate (with the public key). Note the different permissions on this file compared to userkey.pem.
  4. The directories shown in the listing contain archived previous versions of my own certificate (I maintain a Grid certificate for a number of years in the meantime).

If your system is set up this way, then the Grid certificate enrollment step is concluded.

Configure the certificate based trust anchors

The tools you are going to use will need to know which Certification Authorities you trust. For sure you will want to trust the CA that issued your own Grid certificate, but that is not enough. A number of services run in the EGI infrastructure use certificates issued by different CAs, and in order to access these services, you will have to trust those CAs as well. This act of establishing trust in s CA is represented in your system by making the CA's certificate available to your tools. In a nutshell, if your tool can through some algorithms establish the fact that a given CA certificate was used to issue another certificate that is about to be verified, then the verified certificate is said to be trusted.

EGI adopts the list of endorsed Certificate Authorities that is maintained by the EUGridPMA initiative. This list is made available in the EGI Software Repository and is updated regularly. So, what is left to you is to

  • Obtain these certificates, and
  • install them into a default location

This is, again, different for different platforms that you may use. EGI directly supports Scientific Linux5 SL6 and Debian6 with a repository service available in the EGI Software Repository.

The paragraphs below will give a quick demo on how to install the Grid CA certificates on the most widely used operating systems

Debian 6 and Ubuntu 12.04

Add the following repository to your apt source.list file:

deb http://dist.eugridpma.info/distribution/igtf/current igtf accredited

and install the following package:

$ apt-get install ca-certificates
RedHat Linux 6 and Scientific Linux 6

Follow the EGI UMD repository installation guide

Install the Grid certificates via

yum install lcg-CA
Linux Generic and Mac OS X

Browse to the CA trust anchor's TGZ directory at http://repository.egi.eu/sw/production/cas/1/current/tgz/ and download all the certificate archives.( TODO - Add a simple script to automate that.)

Unpack all individual certificate archive into the same temporary directory. (TODO - provide a simple script for that.) Each certificate archive should expand into five individual files, plus a number of symbolic links to these, for example:

  44 Jan 21 11:00 ca_KEK-1.52.tar.gz 
   7 Feb  1 13:55 2f2f573f.0 -> KEK.pem
  14 Feb  1 13:55 2f2f573f.namespaces -> KEK.namespaces
  18 Feb  1 13:55 2f2f573f.signing_policy -> KEK.signing_policy
   7 Feb  1 13:55 617ff41b.0 -> KEK.pem
  14 Feb  1 13:55 617ff41b.namespaces -> KEK.namespaces
  18 Feb  1 13:55 617ff41b.signing_policy -> KEK.signing_policy
  44 Jan 21 11:00 KEK.crl_url
 239 Jan 21 11:00 KEK.info
 464 Jan 21 11:00 KEK.namespaces
1273 Jan 21 11:00 KEK.pem
1299 Jan 21 11:00 KEK.signing_policy

Once completed, you need to make this directory available to your tools.

The agreed default location for these CA certificates is /etc/grid-security/certificates. It is possible to store the certificates in a different location, but that would require much of configuration hassle. So:

# sudo cp your_temporary_ca_dir /etc/grid-security/certificates

with your_temporary_ca_dir being the directory into which you have extracted the individual CA certificate archives in the previous step.

Join the FedCloud Virtual Organisation

In EGI, one need to be a member of a Virtual Organisation (VO) to be able to access EGI resources. Often, but not always, VOs are organised in Virtual Research Communities (VRCs). The EGI.eu website provides some information and guidance on Virtual Research Communities and Vortial Organisations including how to join or found VOs.

To tell resources (mainly for access and accounting purposes) which with which VO membership one would like to use the resources, the user needs to provide a proxy certificate, that is signed using one's one certificate, and which carries the proper VO attributes with it. The user then uses this proxy certificate instead of her own real Grid Certificate to access the resources. This is the reason why users need to be member of a VO, and must create proxy certificates for EGI resource access.

For Cloud purposes, EGI currently maintains one VO, called fedcloud.egi.eu. EGI.eu provides a description of this VO on its own page.

To apply for membership for the EGI Cloud federation, you need to apply for membership in that VO. THe VO is administered and maintained by CESNET, so apply here for membership in that VO. Note: This requires your Grid Certificate and private key be also stored in your Web Browser!

Your membership should be granted fairly soon, so what's left is to set up VO information and VO trust for your command line environment.


Install VO client tools

To access the federated cloud you will need to install tools to create proxy certificates, and configure these so that they can create proper proxy certificates for you. The tools to be installed are the VOMS client tools that are developed as part of the EMI project.

These tools are available in the EGI UMD Repository for Scientific Linux 5, SL6 and Debian 6.

Debian 6 and Ubuntu 12.04

Add the following repository to your apt source.list file:

deb http://dist.eugridpma.info/distribution/igtf/current igtf accredited

and install the following package:

$ apt-get install voms-clients
RedHat Linux 6 and Scientific Linux 6

Follow the EGI UMD repository installation guide

Install the Grid certificates via

yum install voms-clients
Linux generic and Mac OS X
  • Obtain the latest snapshot (they are stable, though) from the IGI repository.
  • Unpack the archive into a directory of your choice (can be in your home directory):
$ tar xvzf voms-clients-3.0.0.tar.gz
  • Update your shell's $PATH variable to include the bin subdirectory of the voms clients, e.g.
$ export PATH=$PATH:~/voms-clients/bin

Adapt the path to your local needs.

You should now have a working VOMS Clients environment. Try it out using:

$ voms-proxy-info
Proxy not found: /tmp/x509up_u501 (No such file or directory)

This error message is normal, certainly for the first time, when no proxy certificate could be found. The path to the certificate file is composed of a default prefix, and the user id in the system (in my case, I have the user id of 501).

Configure VO membership information

The VOMS client tools require some configuration information to be able to create proxy certificates for you. For this, it needs access to your Grid Certificate (by default it looks in ~/.globus/usercert.pem) and your certificate's private key (by default in ~/.globus/userkey.pem) and configuration information for each VO membership service (VOMS) you need to create proxy certificates for.

Provided that you kept your Grid Certificate and private key in ~/.globus, the only thing you need to do is to set up the VOMS information for the EGI Cloud Federation VO. Again, the accepted default location makes it easy to use to use the tools. You have two choices for providing the configuration information:

  1. local to you, within your home directory, or
  2. global on your system, for all users

This guide will set up global VOMS VO information for the fedcloud.egi.eu VO.

VO information is kept in two pivotal locations :

  • /etc/grid-security/vomsdir directlry, and
  • /etc/vomses file.

Each file serves a specific purpose that can be read up on elsewhere. The guide will explain how to create or amend these two locations for the fedcloud VO as follows:

Creating the vomsdir information

Usually, this information is provided by the VO manager. In this case, we will create it by hand as follows:

# mkdir -p /etc/grid-security/vomsdir/fedcloud.egi.eu
# cd /etc/grid-security/vomsdir/fedcloud.egi.eu
# cat >voms1.egee.cesnet.cz.lsc <<EOF 
/DC=org/DC=terena/DC=tcs/C=CZ/O=CESNET/CN=voms1.egee.cesnet.cz
/C=NL/O=TERENA/CN=TERENA eScience SSL CA
/DC=org/DC=terena/DC=tcs/C=CZ/O=CESNET/CN=voms2.egee.cesnet.cz
/C=NL/O=TERENA/CN=TERENA eScience SSL CA
EOF
Extending/creating vomses file

This file is a list of VO contact informations to obtain any VO specific attributes and roles for your proxy certificate:

# cd /etc
# cat >>vomses <<EOF 
"fedcloud.egi.eu" "voms1.egee.cesnet.cz" "15002" "/DC=org/DC=terena/DC=tcs/C=CZ/O=CESNET/CN=voms1.egee.cesnet.cz" "fedcloud.egi.eu" "24"
"fedcloud.egi.eu" "voms2.grid.cesnet.cz" "15002" "/DC=org/DC=terena/DC=tcs/C=CZ/O=CESNET/CN=voms2.grid.cesnet.cz" "fedcloud.egi.eu" "24"
EOF
Testing the VO membership setup
$ voms-proxy-init -voms fedcloud.egi.eu --rfc
Enter GRID pass phrase for this identity:

Created proxy in /tmp/x509up_u501.

Your proxy is valid until Thu Apr 04 04:02:38 CEST 2013

And finally list the info about your proxy certificate:

$ voms-proxy-info
subject   : /O=dutchgrid/O=users/O=egi/CN=Michel Drescher/CN=1746347155
issuer    : /O=dutchgrid/O=users/O=egi/CN=Michel Drescher
identity  : /O=dutchgrid/O=users/O=egi/CN=Michel Drescher
type      : RFC3820 compliant impersonation proxy
strength  : 1024
path      : /tmp/x509up_u501
timeleft  : 11:59:46
key usage : Digital Signature, Key Encipherment, Data Encipherment

Set up (r)OCCI tools

This tutorial uses the rOCCI client provided mainly by GWDG and CESNET. It is maintained as a GitHub project.

As rOCCI is implemented in Ruby, you'll have to ensure that Ruby 1.9.3 including Ruby Gem is available on your system. This is mostly the case for pretty much any Linux distribution; consult the documentation for your respective Linux distribution.

A guide on how to install rOCCI client is provided in the rOCCI project [README]

Test environment

To test your command-line environment, you can run try to list the resources in one of the FedCloud sites. To do so:

Create a proxy certificate

$ voms-proxy-init -voms fedcloud.egi.eu --rfc
Enter GRID pass phrase for this identity:

Created proxy in /tmp/x509up_u501.

Your proxy is valid until Thu Apr 04 04:02:38 CEST 2013

Check that your proxy certificate is valid

$ voms-proxy-info
subject   : /O=dutchgrid/O=users/O=egi/CN=Michel Drescher/CN=1746347155
issuer    : /O=dutchgrid/O=users/O=egi/CN=Michel Drescher
identity  : /O=dutchgrid/O=users/O=egi/CN=Michel Drescher
type      : RFC3820 compliant impersonation proxy
strength  : 1024
path      : /tmp/x509up_u501
timeleft  : 11:59:46
key usage : Digital Signature, Key Encipherment, Data Encipherment

Select a FedCloud site

Get the URL of the OCCI interface of one of the FedCloud sites, for example https://carach5.ics.muni.cz:11443/

List the image and resource templates

$ occi --endpoint https://carach5.ics.muni.cz:11443/ --action list --resource os_tpl --auth x509 -X -x /tmp/x509up_u500


Os_tpl locations:
       os_tpl#monitoring
       os_tpl#debianvm
       os_tpl#egicf2012_demo
       os_tpl#oxfordcorpusserver
       os_tpl#omserver
       os_tpl#wenmr_demo_cesnet
       os_tpl#openbiodebianbase
       os_tpl#egi_sl6goldenimage_cesnet
       os_tpl#hadoop
       os_tpl#debianvm_2ips