Difference between revisions of "Core Services Installation"

Revision as of 17:01, 1 July 2009

THIS SECTION OF GCUBE DOCUMENTATION IS OBSOLETE. THE NEW VERSION IS UNDER CONSTRUCTION.

Platform Wide Dependencies

Environment Setup

VREManagement

The VREManagement class of services groups a set of software components that take care of the creation and maintenance of dynamic DLs by instantiating the appropriate resources and authorizing users to get access to those resources. In order to perform these activities, the Keeper service focuses on the entire lifecycle of software packages management ranging from the specifications and conventions they must follow to their physical deployment and relocation. The VREManagement service is a logical service composed by:

• Software Repository Service (WSRFService) – The Software Repository validates, stores, and manages gCube packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. This repository accepts registration requests coming from the Service Archive Registration Portlet that is part of the VDL service, whilst accepts access requests from the VREManaGER service and the Deployer service.
• VREManager Service (WSRFService) – This component coordinates the packages deployment process when a new VRE is instantiated and during its lifetime. The operational context that transforms a set of distributed and deployed GCUBEResources into a single application is managed by this component.
• gcube Hosting Node Manager Service (WSRFService) – The gCube Hosting Node Manager (GHNManager) manages the scope of the gCube Hosting Node (gHN) and the hosted service instances Moreover, it publishes into the IS the profile of the gHN.
• Deployer Service: .....

Pre-installation setup

The GHNManager and Deployer services and their stubs are deployed together with the gHN installation. The Software Repository's gHN requires a node with Tomcat installed and therefore the port Tomcat listens for connections has not to be behind a firewall.

Main installation procedure

VREManager

The VREManager Service is a VO specific service that has to be deployed manually for each VO and dynamically for each VRE .

The VREManager can be downloaded from the Eng repository . These are the installation steps to follow:

• Unpack the ServiceArchive tar.gz file;
• type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;
• copy ServiceProfile_Keeper_DLManagement.xml under the $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/ folder in order to publish the DL Management Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.

Security Settings

The DLManagement Service, in case of Secure infrastructure, work using Service Credentials for they operations. The Manually deployment of the services implies also the manual setting of Credential Renewal Task that will let the services work with fresh credentials. This can be done using the Credential Renewal Service, interacting with it using the CredentialRenewal API and Stubs, contained inside the Credentials Renewal ServiceArchive 0_3_0 that can be downloaded from the Eng repository.

The DLManagement Service, in case of Secure infrastructure, work using Service Credentials for they operations. The Manually deployment of the services implies also the manual setting of Credential Renewal Task that will let the services work with fresh credentials. This can be done using the Credential Renewal Service, interacting with it using the CredentialRenewal API and Stubs, contained inside the Credentials Renewal ServiceArchive 0_3_0 that can be downloaded from the Eng repository.

First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.

java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> 
-port <CredentialPort> -proxy <proxyFile> -username <username>

The output of this operation will be an ID that identifies the Account created and that can be used to add Context then create Credential renewal Task. In order to create a context related to DLManagement Service using the CredentialRenewal API just type:

java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> 
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> 
-serviceClass Keeper -serviceName DLManagement

Setting the DLManagement Credential Renewal Task:

java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> 
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper 
-serviceName DLManagement -proxy <proxyFile>
 -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService     
  -period 24 -roles Credentials-Manager

Make sure to add the Credentials-Manager Role to the DLManagement Task!Otherwise the service will be not able to create Credential Rewal Tasks during its lifetime.

Post-installation configuration

The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:

• "Root" VO;
• Sub-VO;

In case of root VO the DLManagement Service needs static information about the root VO name and VOMap file. These parameters have to be configured through the Service JNDI file:

• voName : the root VO Name
• voMapPath : the VOMap path relative to the DLManagement container folder.

The JNDI file contains further parameter to be configured (both for VO - subVO deployment):

• useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment
• startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.
• sweeperDelay : the sweeper delay in ms.

DLManagement UI

In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented. The DLManagement UI allows to perform teh following administration operation:

• create a VO ( create a DLManagement VOScope Resource to manage a new VO);
• Deploy a Service inside a DL/VO;
• Undeploy a Service from a DL/VO;
• Apply a patch to an already deployed package;
• Update an already deployed package;
• Get the logs related to a deploy/undeploy/patch operation;
• Get an XML report containing all the operation applied to a DHN;
• Print the deployment status of a service ( and the related packages);

The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween brackets are optional. The proxyFile parameter is mandatory for all the operation and has to be created in this way:

If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the 
role Credential Manager for the VOMS group /diligent/ImpECt:

voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager 

The DLMamanegement UI syntax is the following:

• Create VO operation:

java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> 
-create [-secure] -groupName:<groupName>

• Deploy a service (inside a VO /DL):

java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI  -proxyFile:<ProxyFilePath> [-vo|-dl | ] 
-deploy  [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID>

• UnDeploy a service (from a VO /DL):

java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] 
-undeploy  [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID>

• Apply Patch to a deployed package:

java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] 
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> 

-packageName:<PackageName> -packageType:<PackageType>

• Update a deployed package:

java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] 
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> 
-packageType:<PackageType>

• Get Logs related to a deploy/undeploy/patch operation:

java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] 
-getLog [-secure] -groupName:<groupName> -id:<ID>

• Get an XML report related to a DHN

java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]
 -getReport [-secure] -groupName:<groupName> -dhnId:<DHNID>

• Print the deployment status related to a ServiceID and a DHN

java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] 
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID>

DLManagementUI options/parameters:

• vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;
• secure : enable security on DLManagement operation
• restart : force DHN reboot after the apply patch operation
• groupName : the VOMS group the DL/VO is managing
• serviceId : service UniqueID
• dhnId : a DHN UniqueID
• id : a Unique Identifier associated to a deploy/undeploy/update/patch operation
• packageName : the package Name as specified inside a Service Profile
• packageType : the packageType, it can be:
  • Library
  • WSRFService
  • ExternalSoftware
• patchUrl : an HTTP URL where the patch is located

Installation troubleshooting

No known problem to be reported.

GHNManager

The GHNManager installation is always performed manually (it comes together with the gCore installation), since it is the service devoted to the scope management of the local node.

Deployer

The Deployer installation is always performed manually (it comes together with the gCore installation), since it is the service devoted to the deployment operations on the local node.

Software Repository

The Software Repository should not be directly used by other services besides Service Archive registration Portlet for storing issues, DLManagement Service to query for dependencies and HNM to get stored packages. The VDL, DL Mng., and HNM act as PR clients, so PR stubs should be on that clients installations.

Access to this component has to be done, as for any other WSRF service, by creating the appropriate portType connected to the EPR of an active instance of the service using the stubs classes distributed with the component.

Package Repository service is distributed with a PR client that can be used to check all PR functionalities as well as a system to initialize a DILIGENT infrastructure from scratch.

Pre-installation setup

The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure).

The service installation requires:

• a DHN installed and configured
• a set of environment variables to be defined.

Depending on the configuration, it may require:

• a node from where it is possible to access to the Grid storage;

Setting up the Access to the Grid Storage

The Package Repository can be configure to synchronize its local storage on a gLire SE. In this case, the access to a gLIte SE (e.g. DPM) and a gLite LFC are mandatory to run the Package Repository.

From the machine where PR will be deployed execute as root following operations:

OS and gLite Installation

1:. Install SLC3

2:. Install APT:

wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm 
rpm -ivh apt-XXX.i386.rpm

3:. Check/add APT repositories to the configuration files:

/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg

4:. Install the following APT packages:

apt-get install lcg_util
apt-get install LFC-client LFC-interfaces
apt-get install glite-security-voms-clients

Security Configuration

1:. Install CA certificate:

apt-get install lcg-CA
rpm -ivh ca_ENG-xxx.rpm
rpm -ivh ca_UMIT-xxx.rpm

2:. Install VOMS server certificate:

/etc/grid-security/vomsdir/grids03.eng.it.pem

3:. Install host certificates:

/etc/grid-security/hostcert.pem
/etc/grid-security/hostkey.pem

check files permissions (chmod 644 and 400)

Main installation procedure

The PR ServiceArchive 0_3_0 can be downloaded from the Eng repository . These are the installation steps to follow:

1:. From the PR (user) account unpack the ServiceArchive tar.gz file;

2:. Type

globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar 

to deploy the PR Service on the local container;

3:. Copy

ServiceProfile_PackageRepository_Keeper.xml 

under the

$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/

folder in order to publish the PR Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.

4:. Configure environment

* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties

* update start-PR.sh script variables 

* change $HTTP_APACHE_DIR directory rights to allow write

Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh

5:. Create vomses file

~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"

copy user certificates to under the

~/.globus

folder

6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed

activation.jar (*)
commons-compress-20061201.jar 
jaxb1-impl.jar (*)
jaxb-api.jar (*)
jaxb-impl.jar (*)
jaxb-xjc.jar  (*)
jsr173_api.jar (*)
org_diligentproject_common_profile.jar (*)
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)
org_diligentproject_keeperservice_hnm_stubs.jar (*)
yu_1.2_forDiligent.jar

(*) already installed with DHN.

Post-installation configuration

1:. Manual proxy generation

voms-proxy-init -voms diligent

2:. Start Apache

 
/etc/init.d/httpd start

3:. Start container

globus-start-container -nosec -debug >container.log 2>error.log &

Installation troubleshooting

Common administration tasks

1:. Manual proxy generation when proxy certificate reach its valid time.

voms-proxy-init -voms diligent 

2:. Control that Apache is up and running

3:. Control that PR user has write right access to $HTTP_APACHE_DIR

4:. To test if the PR service is up and running use the PR client

Audit Logs

Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.

In case of system malfunction, security incidents etc. look for ERROR messages on container outputs. All messages indicates where the error occur, a short error message, as well as the java exception chain (if applicable).

Broker & Matchmaker (BMM)

The BMM Service is made up of the following components:

• The BMM Service (WSRF Service) provides the core functionalities of the BMM component. It queries the IS in order to gather information about packages to enrich initial VREManager request. This service computes, by running a customized version of first-fit algorithm, the associations among packages and GHNs. When the response is ready, it publishes as a topic the result.

Pre-installation setup

The BMM Service is VO specific service (there is the need of an instance of it for each VO) and so the service installation requires a node (GHN) for each VO.

Main installation procedure

The BMM ServiceArchive source code is available from SVN: http://svn.research-infrastructures.eu/public/d4science/gcube/trunk/broker-matchmaker/Matchmaker_Service/ and binaries can be downloaded from: http://software.d4science.research-infrastructures.eu/

These are the installation steps to follow:

• Unpack the ServiceArchive tar.gz file;
• type $GLOBUS_lOCATION/bin/gcore-deploy-service bmm.matchMaker-service.gar to deploy the BMM Service on the local container;

Post-installation configuration

None.

Testing and verifying the installation

Provide instructions that will assist the administrator in verifying that the service has been installed and is running appropriately. Troubleshooting of the installation together with error messages and common compensation actions should be provided in detail in chapter 4.

Installation troubleshooting

Things that can go wrong. Error messages that may appear. Workarounds to common problems

DILIGENT Information Service (DIS)

The following components compose the DILIGENT Information Service:

• DIS-IP (Library) – The DIS-IP is responsible for registering/unregistering a group of resource properties as Aggregator Source to one or more DIS-ICs. It also allows to register/unregister groups of Topics in the DIS-Broker.
• DIS-HLSClient (Library) – The DIS-HLSClient is a library used by DILIGENT services to access the information maintained by the DILIGENT Information Service. Using a DIS-HLSClient it is possible to query a DIS-IC to discover Profiles or WS-Resource properties.
• DIS-IC (WSRFService) – This service is the Information Collector (IC) of all the data published in the DIS. It is implemented as Aggregator Sink that collects RPs from the registered (via DIS-IP) Aggregator Sources.
• DIS-BDIIClient (WSRFService) – This service is in charge of harvesting resource information from the BDII Server1 it has been configured to interact with. The gathered information is manipulated in order to make it compliant with the schema adopted in DILIGENT. Then such information is published as WS-Resources via the DIS-IP and as a DILIGENT Resource of type gLiteResource using the mechanism offered by the DIS-Registry Service.
• DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.
• DILIGENTProvider (Library) – This operation provider adds resource properties to the group of properties registered by a service in the DIS-IC. This additional information allows enlarging the spectrum of functionalities offered to identify the source that publishes the data and to perform fine-grained queries.
• DIS-Broker (WSRFService) – This service provides registration/unregistration of Topics (events to be notified on) for DILIGENT Services. This allows clients to subscribe to/unsubscribe from topics without having to know the physical locations of the services that expose them.

Pre-installation setup

The DIS core Services (DIS-Registry, DIS-Broker and DIS-IC), are VO specific services ( there is the need of an instance of those services for each VO). Starting from the root VO ( the "diligent" root VO), but at the time being also all the sub-VO (i.e. ARTE) need a manual installation. The root DIS is the first DILIGENT services that has to be installed in the infrastructure: it will contain all DHN Profiles and RI Profiles of Services running on the root VO and DHN profiles of Sub-VO node ( that can be assigned to sub-VOs by VO Managers).

The Installation of the root DIS requires at least 3 nodes:

• the DIS-Registry DHN

• the DIS-Broker DHN

• the DIS-IC DHN

The DIS-BDIIClient is a VO specific Services and is no needed at root VO level. In order to speed up the performance and exploits the distributed nature of the GT4 Aggregator Framework, the best DIS Services deployment strategy would be:

• Deploy the DIS-Broker and the DIS-Registry on the same DHN

• Deploy the DIS-IC on a separate DHN.

The following installation documentation assumes that this is the target deployment schema.

Main installation procedure

The DIS Installation needs a manual change on the DHN behaviour. The HNM in general is configured to publish the RI profiles of the codeployed services and the related DHN profile on the root VO. In case the HNM is codeployed toghether with DIS Services (so it has to register Profiles using the codeployed instance of the DIS-Registry) the DHN has to be configured to act as a "root" DHN. The related HNMService inthis context will create all the DIS Running Instance Profiles (togheter with the DHN profile), but it will be DIS-Registry itself that will register these profiles.

DHN root Installation

The "root" DHN has to be installed following the Admin guide. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:

• The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)

DIS-IC Installation

The DISIC ServiceArchive 0_3_0 can be downloaded from the Eng repository Eng repository . These are the installation steps to follow:

• Unpack the ServiceArchive tar.gz file;
• type globus-deploy-gar org_diligentproject_informationservice_disic.gar located inside the DIS-IC folder to deploy the DIS-IC Service on the local container;
• download the exist 1.1 installation binary (wget --no-check-certificate http://grids17.eng.it/engrepository/exist/1.1.1/noarch/eXist-1.1.1-newcore-build4311.tar.gz)
• source the install1.1.sh script located in the eXist/scripts folder

DONE!

DIS-Broker Installation

The DISBroker ServiceArchive 0_3_0 can be downloaded from the Eng repository . These are the installation steps to follow:

• Unpack the ServiceArchive tar.gz file;
• type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;

DONE!

DIS-Registry Installation

The DISRegistry ServiceArchive 0_3_0 can be downloaded from the Eng repository . These are the installation steps to follow:

• Unpack the ServiceArchive tar.gz file;
• type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;

DONE!

Security Setting

All DIS services can be configured to run in a secure/unsecure context. In case the VO to deploy has to run in a secure way the stardard installation will provide server-config.wsdd files that already contain security-descriptor for DIS services. In case the VO has to be deployed without security just:

• enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )
• copy the content of deploy-server.wsdd_NOSEC file inside server-config.wsdd file
• this will remove the link to the service security-descriptor and has to be done for all DIS services.

The DIS-Registy Service, in case of Secure infrastructure, works using Service Credentials for its operations. The Manually deployment of the service implies also the manual setting of Credential Renewal Task that will let the service works with fresh credentials. This can be done using the Credential Renewal Service, interacting with it using the CredentialRenewal API and Stubs, contained inside the Credentials Renewal ServiceArchive 0_3_0 that can be downloaded from the Eng repository .

First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:

 
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> 
-port <CredentialPort> -proxy <proxyFile> 
-username <username>

The output of this operation will be an ID that identifies the Account created and that can be used to add Context to the Account and then Credential renewal Task. In order to create a context related to DIS-Registry Service using the CredentialRenewal API:

 java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost>
 -port <CredentialPort> -proxy <proxyFile>
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry

Setting DIS-Registry Credential Renewal Task:

java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \
 -host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem 
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> 
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \
-period 24 -roles Basic

Post-installation configuration

After the deployment the VOMap for the VO the DIS installed refers to has to be properly configured. So in case of /diligent root VO just change the file VOMap_diligent.xml located into the $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps modifyng service endpoint according to your DIS installation. In case of sub-VO DIS installation just creates a VOMap_<yourSubVo>.xml file containing as above the endpoint to your DIS installation.

Testing and verifying the installation

Provide instructions that will assist the administrator in verifying that the service has been installed and is running appropriately. Troubleshooting of the installation together with error messages and common compensation actions should be provided in detail in chapter 4.

Installation troubleshooting

Things that can go wrong. Error messages that my appear. Workarounds to common problems

VDL Generator

Pre-installation setup

Actions to be performed before initiating the installation of this service.

Main installation procedure

Describe in full detail all required steps for installing/deploying all components of the service. Group the steps in subparagraphs providing a meaningful header. This section should contain instructions for at least the following sub-services:

• Package Repository
• DL Management and
• Hosting Node Management

Post-installation configuration

Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.

Testing and verifying the installation

Provide instructions that will assist the administrator in verifying that the service has been installed and is running appropriately. Troubleshooting of the installation together with error messages and common compensation actions should be provided in detail in chapter 4.

Installation troubleshooting

Things that can go wrong. Error messages that my appear. Workarounds to common problems

Virtual Organisation Management (VO-Management)

The main aim of the Virtual Organisation Management (VO-Management) subsystem is to supply gCube infrastructure with a robust and flexible security framework, able to manage authentication and authorization processes for users, both human and services.

VO-Management components included in gCube are:

• Delegation - this service receives credentials that enable authentication of gCube running instances (RIs) hosted in the gHN. Credentials received are dispatched to co-hosted RIs, that can used them to perform authenticated invocations within the gCube infrastructure.
• Credentials Renewal - this service is designed to work together with Delegation RIs. In particular it is in charge of periodically send credentials to Delegation RIs running in the infrastructure.
• VOMS-API - this library provides utility methods to (a) retrieve credentials of gCube users and (b) manage user attributes of gCube users in a VOMS service.

The previous set of components relies on the following existing components. These external components must be installed and configured as described in the Pre-installation setup section below.

• SimpleCA - this library, part of the GT4 distribution, act as the gCube Certification Authority (CA), issuing signed credentials for gCube identities.
• MyProxy - this service, provided by the National Center for Supercomputing Applications (NCSA), allows to (a) hosts temporary credentials of gCube users and (b) act as an onlne CA, issuing signed credentials for gCube identities. For the second functionality, the credentials issuing, MyProxy relies on the SimpleCA components, that must be installed locally to the MyProxy node.
• VOMS - this service, developed and maintained by the INFN-CNAF, act as the gCube Attribute Authority, issuing signed assertions about gCube users. VOMS assertions states group memberships and roles held by the gCube user, thus allowing the portal and gCube services to enforce authorisation on requests.

Pre-installation setup

This section provides information about installation procedures of external components required by VO-Management subsystem. The aim of this section is not to fully describe installation steps of these components, but to provide useful links and hints to official documentation of external components.

• MyProxy + SimpleCA - MyProxy and the SimpleCA must be installed and configured on the same host to act together as required by the gCube architecture. The installation is logically divided into three steps.
  • First of all, the SimpleCA must be installed and a new CA must be created following these steps.
  • Secondly, a MyProxy service must be installed and configured as described here.
  • Thirdly, and lastly, MyProxy must be configured to expose the CA created in the first step. Instructions to do this are available here.
• VOMS - Installation instructions for the VOMS service are available here.

Once SimpleCA, MyPRoxy and VOMS components are in place you can proceed with the installation and configuration of VO-Management components as described below.

Main installation procedure

This procedure describes the installation of the Credentials Renewal service.

Delegation Service Installation

The Delegation service requires the gCore distribution on the local node. gCore can be installed as described in the gCore Administrator guide. Providing the gCore distribution has been installed, the Delegation service can be installed running the following command.

gcore-deploy-service org.gcube.common.delegation.gar

The Delegation service is planned to be included in future releases of the gCore distribution, once the Delegation will be part of gCore enabling services, the manual installation described here will not be needed any more.

Credentials Renewal Installation

The Credentials Renewal service requires the gCore distribution on the local node. gCore can be installed as described in the gCore Administrator guide. Providing the gCore distribution has been installed, the Credentials Renewal service can be installed running the following command:

gcore-deploy-service org.gcube.vomanagement.credentialsrenewal.gar

Once installed, the Credentials Renewal service can be configured editing the $GLOBUS_LOCATION/etc/org.gcube.vomanagement.credentialsrenewal/jndi-service.xml file. Following parameters must be specified to point the Credentials Renewal to the correct MyProxy and VOMS services:

At the RI startup, the service will try to load its own credentials from the MyProxy service. The value of the serviceDN parameter will be used as the username for this purpose.

Testing and verifying the installation

The installation can be verified starting the container hosting the Delegation or the Credentials Renewal service. This can be done running the command:

gcore-start-container

Installation troubleshooting

Portals

Pre-installation setup

Actions to be performed before initiating the installation of this service.

Main installation procedure

Describe in full detail all required steps for installing/deploying all components of the service. Group the steps in subparagraphs providing a meaningful header. This section should contain instructions for at least the following sub-services:

• Package Repository
• DL Management and
• Hosting Node Management

Post-installation configuration

Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.

Testing and verifying the installation

Provide instructions that will assist the administrator in verifying that the service has been installed and is running appropriately. Troubleshooting of the installation together with error messages and common compensation actions should be provided in detail in chapter 4.

Installation troubleshooting

Things that can go wrong. Error messages that my appear. Workarounds to common problems