Administrator's Guide: How to set up a gCube infrastructure

A gCube infrastructure is a set of working nodes (so-called DHNs, DILIGENT Hosting Nodes) glued by the gCube enabling services and able to host gCube services in a cooperative way. When creating a new infrastructure, there are two kinds of configuration: secure configuration and non-secure configuration The setup of the latter is easier than the former, since the secure infrastructures require some additional steps.

Non-secure configuration

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

Minimal configuration

Perform the following steps to create and configure a non-secure infrastructure:

1. decide a name for the new infrastructure
2. decide the VOs hierarchy configuration: at least one root VO and a subVO are required to be there
3. identify a set of machines to turn on as gHNs (their number may vary depending on the infrastructure needs)
4. prepare a VO Map file for each VO
5. setup the infrastructure
   1. identify two machines to dedicate to the VO management
   2. install gCore in the two machines and copy the VO Map files under the $GLOBUS_LOCATION/config folder
   3. configure one gHN (named IS infrastructure gHN) as root, join it to the infrastructure scope and install the IS core services (IS-IC, IS-Registry, IS-Notifier) there dedicated to the management of the infrastructure
   4. configure one gHN (named DLMan root gHN) to join it to the infrastructure and
      • install and populate a Package Repository there
      • install and configure a DL Management Service there
   5. start the container on the IS root gHN and then on the DLMan root gHN and verify that they work properly
6. setup the VO
   1. identify two machines to dedicate to the VO management
   2. install gCore in the two machines and copy the VO Map files under the $GLOBUS_LOCATION/config' folder
   3. configure one gHN as root, join it to the VO as startScope and install the IS core services (IS-IC, IS-Registry, IS-Notifier) there dedicated to the VO (named IS VO gHN)
   4. configure one gHN (named VREManager VO gHN) to join it to the VO as start scope and install and configure a DL Management Service there
   5. start the container on the IS VO gHN and then on the VREManager VO gHN and verify that they work properly
7. configure and start generic gHNs
   1. install gCore in each machine and copy the VO Map files under the $GLOBUS_LOCATION/config folder
   2. configure the gHNs to join the VO as start scope:
   3. start the container on each machine and verify that the gHN is correctly published both in the root VO and in the VO IS
8. setup the portal by following the ... instructions.
9. configure one or more VREs by exploiting the Administration user interface capability.

Other possible configurations

Alternative configurations can improve the infrastructure performances. In particular:

• the IS-Notifier can be hosted on a different (and standard, i.e. non-root) gHN with respect to the other two IS core services
• the Software Repository can be hosted on a different (and standard, i.e. non-root) gHN with respect to the VREManager service
• multiple VOs can be defined
• more than one IS can be setup for each VO in order to distribute the load over them

The 'optimal' configuration mainly depends on the number of available gHNs. More gHNs joining the infrastructure means a better distribution of resources and services across them.

Secure configuration

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

The setup of a secure configuration is slightly complex with respect to a non-secure one, but it introduces some advantages. In fact, having such a configuration allows sharing of service instances among multiple VREs.
The steps described for the non-secure configurations have to be integrated by the additional actions reported below.

• Steps 5.2, 6.2 e 7.1 requires the following:

a) configure the Java WS Core container running on each DHN to run with host credentials

b) configure the HNM Service hosted on each DHN to run with the security enabled

• The setup of the root VO includes this preliminary actions:

a) install a MyProxy repository and a MyProxy OnlineCA

b) install a VOMS service

c) install a VOMSServlet on a Tomcat hosting environment

d) identify a further DHN to dedicate to the VO management and configure it (named CR root DHN) as root, join it to the root VO as default VO

e) install an instance of the Credentials Renewal service on the CR root DHN

f) configure each service to use the security

The startup sequence in this case is: start the container on the DIS root DHN, then on the CR root DHN and then on the DLMan root DHN and verify that they work properly

Regarding the security used by each gCube service, the steps needed depends here on the way the service behaves with respect to the credentials used. It can act by using the service credentials or by using the caller credentials.
Service credentials

a) delegate proxy credentials on the MyProxy for the service stored on the Package Repository

b) create an Account on the Credential Renewal instance for each proxy credentials stored

c) create a Renewal Task (using the appropriate Account Resource) on the Credentials Renewal instance for each Running Instance of a gCube service

• this operation is performed automatically by the CL services in case of dynamically deployed instances
• this operation has to be done manually in case of statically deployed instances

d) each running instance retrieves its own credentials from the local Delegation Service for the current VRE (extracted from the caller credentials)

Caller credentials

a) each running instance retrieves the credentials from the context (delegated from the caller credentials)

b) each running instance is invoked by using the Full Delegation modality

Manuelesimi 13:45, 5 December 2007 (EET)