https://wiki.gcube-system.org/api.php?action=feedcontributions&user=Andrea&feedformat=atomGcube Wiki - User contributions [en]2024-03-29T10:35:38ZUser contributionsMediaWiki 1.25.1https://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3445Core Services Installation2008-02-26T10:12:45Z<p>Andrea: /* DIS-IC Installation */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTTP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
The DISIC ServiceArchive 0_3_0 can be downloaded from the Eng repository [http://grids17.eng.it/engrepository/ Eng repository ].<br />
These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* 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; <br />
* 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)<br />
* source the install1.1.sh script located in the eXist/scripts folder<br />
<br />
DONE!<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3444Core Services Installation2008-02-26T10:12:21Z<p>Andrea: /* DIS-IC Installation */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTTP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
The DISIC ServiceArchive 0_3_0 can be downloaded from the Eng repository [http://grids17.eng.it/engrepository/ Eng repository ].<br />
These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* 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; <br />
* 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)<br />
* source the install1.1.sh script located in the eXist/scripts folder<br />
<br />
DONE!<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3443Core Services Installation2008-02-26T10:12:03Z<p>Andrea: /* DIS-IC Installation */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTTP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
The DISIC ServiceArchive 0_3_0 can be downloaded from the Eng repository [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* 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; <br />
* 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)<br />
* source the install1.1.sh script located in the eXist/scripts folder<br />
<br />
DONE!<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3442Core Services Installation2008-02-26T10:11:28Z<p>Andrea: /* DIS-IC Installation */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTTP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
The DISIC ServiceArchive 0_3_0 can be downloaded from the Eng repository . These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* 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; <br />
* 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)<br />
* source the install1.1.sh script located in the eXist/scripts folder<br />
<br />
DONE!<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3441Core Services Installation2008-02-26T10:11:15Z<p>Andrea: #</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTTP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
The DISIC ServiceArchive 0_3_0 can be downloaded from the Eng repository . These are the installation steps to follow:<br />
<br />
* Unpack the ServiceArchive tar.gz file;<br />
* 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; <br />
* 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)<br />
* source the install1.1.sh script located in the eXist/scripts folder<br />
<br />
DONE!<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3440Core Services Installation2008-02-26T10:05:31Z<p>Andrea: /* DIS-IC Installation */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTTP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
The DISIC ServiceArchive 0_3_0 can be downloaded from the Eng repository . These are the installation steps to follow:<br />
<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disic.gar to deploy the DIS-IC Service on the local container; <br />
<br />
<br />
DONE!<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Package_Repository&diff=3434Package Repository2008-01-23T09:19:55Z<p>Andrea: /* DILIGENT infrastructure initialization */</p>
<hr />
<div>== Package Repository ==<br />
<br />
=== Introduction ===<br />
<br />
The Package Repository validates, stores, and manages DILIGENT packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. <br />
<br />
This repository accepts registration requests coming from the Service Archive Registration Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
<br />
=== Implentation Overview ===<br />
<br />
This component is responsible for the validation, storage, and maintenance of the [[ Service_Archive_Specification | DILIGENT service archives]], each service archive contains all files declared on the [[ Profile_Specification | Service Profile]] . It checks packages dependencies and by ensuring access to them, it supports the dynamic packages deployment. <br />
<br />
The Package Repository is a WSRF service, implemented as specified by the Singleton Pattern . Accordingly, it splits the implementation into three sub-components: (i) the resource itself that contains Package Repository state, (ii) the resource home that manages the resource, and (iii) the web service that gives access to components functionality. <br />
<br />
The resource state contains information about the stored service archives. The resource home is used by the web service to create and find the resource. <br />
<br />
The web service provides to the clients, e.g. HNM, access to the Package Repository functionality ([[ Package_Repository#Functionality | see below ]]).<br />
<br />
This service is internally composed by a (i) Parser component and by a (ii) Grid access interface.<br />
<br />
Parser component includes a Validation phase that checks service archives based on service profiles declarations. It assumes that service profiles are valid against the service profile schema. Controls performed includes checking that all declared files are in the right place into the service archive structure, that all service profiles includes at least a WSRF service, that the declared stubs library point to the corresponding package, etc. After this phase was completed PR create a tar gz file for each declared pakage that is provided on request to the HNM.<br />
<br />
Grid Access inteface is in charge of store all PR data structures and packages into the Grid, as well as get from the Grid packages when requested.<br />
Package Repository stores all its data structures and packages into a local cache and into the Grid.<br />
<br />
<br />
==== Functionality ====<br />
<br />
The signatures of the actual implemented methods are presented below. These operations allow uploading, deleting, list, and getting a DILIGENT package. As well as other advanced operations that operate over packages dependencies. <br />
<br />
<br />
:1. '''store'''<br />
<pre><br />
store (ServiceIDURLDescription) -> String<br />
</pre><br />
<br />
This operation stores a service archive into the Package Repository and assigns status pending to it. Pending status means that service archive is valid, and unique ID was not previously used but cannot be deployed.<br />
<br />
''ServiceIDURLDescription'' type contains the unique ID assigned to the service, the URL from where the service archive can be downloaded, and the service description.<br />
<br />
''Return'' String contains unique ID if service archive is valid, null otherwise.<br />
<br />
:2. '''approve'''<br />
<pre><br />
approve (String) -> String<br />
</pre><br />
<br />
Approve an already stored service achive, if unique ID passed exists with pending status.<br />
<br />
''Return'' It returns approved if operation success, an error message otherwise.<br />
<br />
:3. '''delete'''<br />
<pre><br />
delete (String) -> String<br />
</pre><br />
<br />
This operation deletes a stored DILIGENT service archive from the Package Repository if unique ID passed exists. This implies the removal of all software packages from the Grid and from the local cache. <br />
<br />
''Return'' A message reporting success of failure is returned.<br />
<br />
:4. '''get'''<br />
<pre><br />
get (ServiceIDPackage) -> String<br />
</pre><br />
<br />
To identify an unique package on the repository two values must be provided: (i) DILIGENT unique ID and (ii) package name.<br />
<br />
''Return'' The method returns the URI from where the requested package can be downloaded.<br />
<br />
:5. '''getServiceProfile'''<br />
<pre><br />
getServiceProfile (String) -> String<br />
</pre><br />
<br />
''Return'' From a given unique ID this method return the corresponding Service Profile if exists, null otherwise.<br />
<br />
:6. '''getServiceProfileID'''<br />
<pre><br />
getServiceProfileID (ClsssName) -> String<br />
</pre><br />
<br />
''Return'' From a given class and name parameter this method return the corresponding DILIGENT unique ID if exists, null otherwise.<br />
<br />
:7. '''listPending'''<br />
<pre><br />
listPending ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status pending. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:8. '''listApproved'''<br />
<pre><br />
listApproved ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status approved. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:9. '''listNonDeployableServices'''<br />
<pre><br />
listNonDeployableServices ( ) -> String<br />
</pre><br />
<br />
With this functionality it is possible to know which stored packages are not deployable due missing dependencies.<br />
<br />
''Return'' a XML with the following structure:<br />
<pre><br />
<Resultset><br />
<Result><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:10. '''listAllDependenciesChain'''<br />
<pre><br />
listAllDependenciesChain (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:11. '''listSameDHNPackages'''<br />
<pre><br />
listSameDHNPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DHN dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:12. '''listSameDLPackages'''<br />
<pre><br />
listSameDLPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DL dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:13. '''listSameVOPackages'''<br />
<pre><br />
listSameVOPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same VO dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type.<br />
<br />
<br />
=== Dependencies ===<br />
<br />
The dependencies of the Package Repository Service are:<br />
*DHN: to host service.<br />
*NAL: to access to HNM.<br />
*Keeper common: for type definition.<br />
*Grid Storage: to store DILIGENT packages on the Grid.<br />
*Profile Manager: to parse Service Profile<br />
*Commons-io from Jakarta: to File system functionality.<br />
*Commons-compress from Jakarta: to File compress functionality.<br />
<br />
=== Usage Example ===<br />
<br />
==== Package Repository client ====<br />
<br />
A Package Repository client is provided. The client uses all PR functionality in different ways, i.e. by calling directly the PR operations and by pre-processing the client input to generate the appropriate series of PR service calls.<br />
<br />
===== Dependencies =====<br />
* Package Repository service<br />
* Keeper common <br />
<br />
===== Usage =====<br />
<pre><br />
java ClientPackageRepository pkgRepositoryURI store diligentID serviceArchiveURI description<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeAndApproveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI approve diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI approveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI get diligentID packageName<br />
<br />
java ClientPackageRepository pkgRepositoryURI delete diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfile diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfileID class name<br />
<br />
java ClientPackageRepository pkgRepositoryURI listPending<br />
<br />
java ClientPackageRepository pkgRepositoryURI listApproved<br />
<br />
java ClientPackageRepository pkgRepositoryURI listNonDeployable<br />
<br />
java ClientPackageRepository pkgRepositoryURI listAllDependenciesChain serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDHNPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDLPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameVOPackages serviceID<br />
</pre><br />
<br />
Where:<br />
* pkgRepositoryURI: Package Repository address.<br />
* diligentID: The unique ID of a Service Archive.<br />
* serviceArchiveURI: The address from where the Service Archive can be downloaded.<br />
* description: The Service Archive description.<br />
* storeListFile: a list with Service Archives to store {diligentID, URI, description}.<br />
* class: The Service Class.<br />
* name: The Service Name.<br />
* packageName: The package Name.<br />
<br />
==== DILIGENT infrastructure initialization ====<br />
<br />
In order to speed up the setting up of a DILIGENT infrastructure, and align available DILIGENT packages with current development process, an automated client that initialize the core DCL services (DIS and PR) is provided with the Package Repository component. <br />
<br />
The procedure consists on a Thread that run the initialization method described below:<br />
<pre><br />
1. Download from ETICS list of last SA built<br />
2. Delete from DIS all SPs<br />
3. Delete from PR all packages<br />
4. For each SA built<br />
4.1. create a new resource into the DIS<br />
4.2. if successful store SA on PR<br />
4.2.1. if successful log success<br />
else remove resource from DIS and log failure<br />
else log failure<br />
</pre><br />
<br />
The Infrastructure Initialization Thread can be run by typing:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -initInfra<br />
</pre><br />
<br />
The same client can be used to download togheter with the SA the related Source Packages and Javadoc Packages,<br />
and create a local storage of source/bynaries/javadoc that can be stored on CVS/SVN repository.<br />
To store a SA on the PR:<br />
<pre> <br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -insert -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
</pre><br />
To update a previously stored SA on the PR ( and the related Service Profile on the DIS):<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -update -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
-id:<SA_ID> <br />
</pre><br />
To Remove a SA from the PR (and the related ServiceProfile from the DIS)<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -delete -id:<SA_ID><br />
</pre><br />
To Download a SA binary package togheter with the related source packages and javadoc packages:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -get -module:<SERVICE_ARCHIVE_MODULE_NAME> <br />
</pre><br />
<br />
<br />
<br />
===== Dependencies =====<br />
* activation.jar<br />
* commons-compress-20061201.jar<br />
* jaxb-api.jar<br />
* jaxb-impl.jar<br />
* jaxb-xjc.jar<br />
* jaxb1-impl.jar<br />
* jsr173_api.jar<br />
* org_diligentproject_common_profilemanager.jar<br />
* org_diligentproject_keeperservice_packagerepository_stubs.jar<br />
* org_diligentproject_informationservice_disregistry_stubs.jar<br />
<br />
===== Usage =====<br />
<br />
Update appropriately the required parameters on the properties file <br />
<pre><br />
org/diligentproject/keeperservice/packagerepositoryclients/InfrastructureInitialization.properties<br />
</pre><br />
to refer to a completely deployed infrastructure:<br />
* VERSION the gCube SA Version (i.e. 0.3.0)<br />
* REPOSITORY_DIR the local dir where a SVN/CVS Repository is defined<br />
* SLEEP_TIME: Thread sleep time in minutes<br />
* TMP_DIR: directory where all Service Archives from build repository will be downloaded and parsed<br />
* ETICS_SA_LIST_URL: build repository URI<br />
* VO: The VO to Initialize<br />
* PR_EPR: PR to update address<br />
* SECURITY_ENABLED true/false if the security is enabled on the infra<br />
* UPDATE_PR true/false if the Initialization thread has to update the PR<br />
* UPDATE_DIS true/false if the Initialization thread has to update the DIS<br />
* PROXY_FILE the local proxy file<br />
* BASE_HTTP_ULR teh base HTTP Url where Etics SA are stored<br />
* LOG4JFILE a custom log4j <br />
<br />
Run the program from a machine with the CLASSPATH set appropriately.<br />
<br />
=== Know Bugs and Limitations ===<br />
<br />
In current implementation the proxy to access to the Grid need to be created manually.</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3400Core Services Installation2007-12-17T16:47:13Z<p>Andrea: /* DLManagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTTP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3399Core Services Installation2007-12-17T16:36:40Z<p>Andrea: /* Security Settings */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTPP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3398Core Services Installation2007-12-17T16:36:27Z<p>Andrea: /* Security Settings */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<br />
[[Image:Alert_icon2.gif]] <pre> 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.<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTPP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3397Core Services Installation2007-12-17T16:36:09Z<p>Andrea: /* Security Settings */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
<pre><br />
[[Image:Alert_icon2.gif]] 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.<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTPP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3396Core Services Installation2007-12-17T16:34:42Z<p>Andrea: /* Security Settings */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> -accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> <br />
-serviceClass Keeper -serviceName DLManagement<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> <br />
-host <CredentialHost> -port CredentialPort -voName <VO> -groupName <VOMS group> -serviceClass Keeper <br />
-serviceName DLManagement -proxy <proxyFile><br />
-delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService <br />
-period 24 -roles Credentials-Manager<br />
</pre><br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTPP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3395Core Services Installation2007-12-17T16:34:09Z<p>Andrea: /* Security Settings */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
First you have to create a MyProxy CA Online account that idnentifies the DLManagement Service.<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> -username <username><br />
</pre><br />
<br />
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:<br />
<br />
<pre><br />
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<br />
</pre><br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
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<br />
</pre><br />
<br />
[[Image:Alert_icon2.gif]] 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.<br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTPP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3394Core Services Installation2007-12-17T16:32:40Z<p>Andrea: /* Security Setting */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTPP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> <br />
-port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost><br />
-port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem <br />
-serviceName DIS-Registry -proxy <proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3393Core Services Installation2007-12-17T16:31:42Z<p>Andrea: /* DLManagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN UniqueID<br />
*id : a Unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTPP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3392Core Services Installation2007-12-17T16:30:46Z<p>Andrea: /* DLManagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
<br />
DLManagementUI options/parameters:<br />
<br />
*vo/dl/ : operation context ( vo /dl ), the context in not mandatory in the createVO operation;<br />
*secure : enable security on DLManagement operation<br />
*restart : force DHN reboot after the apply patch operation<br />
*groupName : the VOMS group the DL/VO is managing<br />
*serviceId : service UniqueID<br />
*dhnId : a DHN ID<br />
*id : a unique Identifier associated to a deploy/undeploy/update/patch operation<br />
*packageName : the package Name as specified inside a Service Profile<br />
*packageType : the packageType, it can be:<br />
**Library<br />
**WSRFService<br />
**ExternalSoftware<br />
*patchUrl : an HTPP URL where the patch is located<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3391Core Services Installation2007-12-17T16:18:19Z<p>Andrea: /* DLManagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> <br />
<br />
-packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3390Core Services Installation2007-12-17T16:15:54Z<p>Andrea: /* DLManagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service functionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/ImpECt/Role=Credentials-Manager <br />
</pre><br />
<br />
<br />
The DLMamanegement UI syntax is the following:<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
*Deploy a service (inside a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-deploy [-secure] -groupName:<groupName> -dhnId:<DHNID>-serviceId:<ServiceID><br />
</pre><br />
<br />
*UnDeploy a service (from a VO /DL):<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-undeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
</pre><br />
<br />
*Apply Patch to a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-patch [-secure] [-restart] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -patchUrl:<HttpLocation> -packageName:<PackageName> -packageType:<PackageType><br />
</pre><br />
<br />
*Update a deployed package:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-update [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID> -packageName:<PackageName> <br />
-packageType:<PackageType><br />
</pre><br />
<br />
*Get Logs related to a deploy/undeploy/patch operation:<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-getLog [-secure] -groupName:<groupName> -id:<ID><br />
</pre><br />
<br />
*Get an XML report related to a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ]<br />
-getReport [-secure] -groupName:<groupName> -dhnId:<DHNID><br />
</pre><br />
<br />
*Print the deployment status related to a ServiceID and a DHN<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> [-vo|-dl | ] <br />
-checkDeploy [-secure] -groupName:<groupName> -dhnId:<DHNID> -serviceId:<ServiceID><br />
<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3389Core Services Installation2007-12-17T16:02:21Z<p>Andrea: /* DLManagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service funcionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/Role=Credentials-Manager <br />
</pre><br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3388Core Services Installation2007-12-17T16:02:01Z<p>Andrea: /* DLManagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service funcionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters: in the syntax shown above the parameter beetween<br />
brackets are optional.<br />
The proxyFile parameter is mandatory for all the operation and has to be created in this way:<br />
<br />
<pre><br />
i.e.<br />
If the operation has to be performed in the context of the /diligent/ImpECt VO the proxy has to contain the <br />
role Credential Manager for the VOMS group /diligent/ImpECt:<br />
<br />
voms-proxy-init -voms diligent:/diligent/Role=Credentials-Manager <br />
</pre><br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3387Core Services Installation2007-12-17T15:53:16Z<p>Andrea: /* DLManagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service funcionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters:<br />
the <br />
<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> <br />
-create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3386Core Services Installation2007-12-17T15:53:02Z<p>Andrea: /* DLMAnagement UI */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLManagement UI ====<br />
<br />
In order to access to DLManagement Service funcionality ( without using Administration portal), a UI has been implemented.<br />
The DLManagement UI allows to perform teh following administration operation:<br />
* create a VO ( create a DLManagement VOScope Resource to manage a new VO);<br />
* Deploy a Service inside a DL/VO;<br />
* Undeploy a Service from a DL/VO;<br />
* Apply a patch to an already deployed package;<br />
* Update an already deployed package;<br />
* Get the logs related to a deploy/undeploy/patch operation;<br />
* Get an XML report containing all the operation applied to a DHN;<br />
* Print the deployment status of a service ( and the related packages);<br />
<br />
The DLManagement UI operations need some optional/mandatory parameters:<br />
the <br />
<br />
<br />
*Create VO operation:<br />
<br />
<pre><br />
java org.diligentproject.keeperservice.dlmanagement.ui.DLManagementUI -proxyFile:<ProxyFilePath> -create [-secure] -groupName:<groupName><br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3385Core Services Installation2007-12-17T15:10:49Z<p>Andrea: /* DL Management */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== DLMAnagement UI ====<br />
<br />
<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually (it comes together with the [[DHN_Installation|DHN installation]]), since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
==== Pre-installation setup ====<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a DHN installed and configured<br />
* a set of environment variables to be defined.<br />
<br />
Depending on the configuration, it may require:<br />
* a node from where it is possible to access to the Grid storage;<br />
<br />
===== Setting up the Access to the Grid Storage =====<br />
<br />
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. <br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
<br />
<br />
==== Main installation procedure ====<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to under the <br />
<br />
<pre><br />
~/.globus<br />
</pre><br />
folder<br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
==== Post-installation configuration ====<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
==== Installation troubleshooting ====<br />
<br />
===== Common administration tasks =====<br />
<br />
1:. Manual proxy generation when proxy certificate reach its valid time.<br />
<pre><br />
voms-proxy-init -voms diligent <br />
</pre><br />
<br />
2:. Control that Apache is up and running<br />
<br />
3:. Control that PR user has write right access to $HTTP_APACHE_DIR<br />
<br />
4:. To test if the PR service is up and running use the [[ Package_Repository#Package_Repository_client | PR client]]<br />
<br />
===== Audit Logs ===== <br />
<br />
Package Repository uses log4j library to log all its outputs messages. Update appropriately the $GLOBUS_LOCATION/log4j.properties file to change log messages level.<br />
<br />
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).<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Package_Repository&diff=3378Package Repository2007-12-12T11:54:12Z<p>Andrea: /* Dependencies */</p>
<hr />
<div>== Package Repository ==<br />
<br />
=== Introduction ===<br />
<br />
The Package Repository validates, stores, and manages DILIGENT packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. <br />
<br />
This repository accepts registration requests coming from the Service Archive Registration Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
<br />
=== Implentation Overview ===<br />
<br />
This component is responsible for the validation, storage, and maintenance of the [[ Service_Archive_Specification | DILIGENT service archives]], each service archive contains all files declared on the [[ Profile_Specification | Service Profile]] . It checks packages dependencies and by ensuring access to them, it supports the dynamic packages deployment. <br />
<br />
The Package Repository is a WSRF service, implemented as specified by the Singleton Pattern . Accordingly, it splits the implementation into three sub-components: (i) the resource itself that contains Package Repository state, (ii) the resource home that manages the resource, and (iii) the web service that gives access to components functionality. <br />
<br />
The resource state contains information about the stored service archives. The resource home is used by the web service to create and find the resource. <br />
<br />
The web service provides to the clients, e.g. HNM, access to the Package Repository functionality ([[ Package_Repository#Functionality | see below ]]).<br />
<br />
This service is internally composed by a (i) Parser component and by a (ii) Grid access interface.<br />
<br />
Parser component includes a Validation phase that checks service archives based on service profiles declarations. It assumes that service profiles are valid against the service profile schema. Controls performed includes checking that all declared files are in the right place into the service archive structure, that all service profiles includes at least a WSRF service, that the declared stubs library point to the corresponding package, etc. After this phase was completed PR create a tar gz file for each declared pakage that is provided on request to the HNM.<br />
<br />
Grid Access inteface is in charge of store all PR data structures and packages into the Grid, as well as get from the Grid packages when requested.<br />
Package Repository stores all its data structures and packages into a local cache and into the Grid.<br />
<br />
<br />
==== Functionality ====<br />
<br />
The signatures of the actual implemented methods are presented below. These operations allow uploading, deleting, list, and getting a DILIGENT package. As well as other advanced operations that operate over packages dependencies. <br />
<br />
<br />
:1. '''store'''<br />
<pre><br />
store (ServiceIDURLDescription) -> String<br />
</pre><br />
<br />
This operation stores a service archive into the Package Repository and assigns status pending to it. Pending status means that service archive is valid, and unique ID was not previously used but cannot be deployed.<br />
<br />
''ServiceIDURLDescription'' type contains the unique ID assigned to the service, the URL from where the service archive can be downloaded, and the service description.<br />
<br />
''Return'' String contains unique ID if service archive is valid, null otherwise.<br />
<br />
:2. '''approve'''<br />
<pre><br />
approve (String) -> String<br />
</pre><br />
<br />
Approve an already stored service achive, if unique ID passed exists with pending status.<br />
<br />
''Return'' It returns approved if operation success, an error message otherwise.<br />
<br />
:3. '''delete'''<br />
<pre><br />
delete (String) -> String<br />
</pre><br />
<br />
This operation deletes a stored DILIGENT service archive from the Package Repository if unique ID passed exists. This implies the removal of all software packages from the Grid and from the local cache. <br />
<br />
''Return'' A message reporting success of failure is returned.<br />
<br />
:4. '''get'''<br />
<pre><br />
get (ServiceIDPackage) -> String<br />
</pre><br />
<br />
To identify an unique package on the repository two values must be provided: (i) DILIGENT unique ID and (ii) package name.<br />
<br />
''Return'' The method returns the URI from where the requested package can be downloaded.<br />
<br />
:5. '''getServiceProfile'''<br />
<pre><br />
getServiceProfile (String) -> String<br />
</pre><br />
<br />
''Return'' From a given unique ID this method return the corresponding Service Profile if exists, null otherwise.<br />
<br />
:6. '''getServiceProfileID'''<br />
<pre><br />
getServiceProfileID (ClsssName) -> String<br />
</pre><br />
<br />
''Return'' From a given class and name parameter this method return the corresponding DILIGENT unique ID if exists, null otherwise.<br />
<br />
:7. '''listPending'''<br />
<pre><br />
listPending ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status pending. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:8. '''listApproved'''<br />
<pre><br />
listApproved ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status approved. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:9. '''listNonDeployableServices'''<br />
<pre><br />
listNonDeployableServices ( ) -> String<br />
</pre><br />
<br />
With this functionality it is possible to know which stored packages are not deployable due missing dependencies.<br />
<br />
''Return'' a XML with the following structure:<br />
<pre><br />
<Resultset><br />
<Result><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:10. '''listAllDependenciesChain'''<br />
<pre><br />
listAllDependenciesChain (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:11. '''listSameDHNPackages'''<br />
<pre><br />
listSameDHNPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DHN dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:12. '''listSameDLPackages'''<br />
<pre><br />
listSameDLPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DL dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:13. '''listSameVOPackages'''<br />
<pre><br />
listSameVOPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same VO dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type.<br />
<br />
<br />
=== Dependencies ===<br />
<br />
The dependencies of the Package Repository Service are:<br />
*DHN: to host service.<br />
*NAL: to access to HNM.<br />
*Keeper common: for type definition.<br />
*Grid Storage: to store DILIGENT packages on the Grid.<br />
*Profile Manager: to parse Service Profile<br />
*Commons-io from Jakarta: to File system functionality.<br />
*Commons-compress from Jakarta: to File compress functionality.<br />
<br />
=== Usage Example ===<br />
<br />
==== Package Repository client ====<br />
<br />
A Package Repository client is provided. The client uses all PR functionality in different ways, i.e. by calling directly the PR operations and by pre-processing the client input to generate the appropriate series of PR service calls.<br />
<br />
===== Dependencies =====<br />
* Package Repository service<br />
* Keeper common <br />
<br />
===== Usage =====<br />
<pre><br />
java ClientPackageRepository pkgRepositoryURI store diligentID serviceArchiveURI description<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeAndApproveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI approve diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI approveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI get diligentID packageName<br />
<br />
java ClientPackageRepository pkgRepositoryURI delete diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfile diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfileID class name<br />
<br />
java ClientPackageRepository pkgRepositoryURI listPending<br />
<br />
java ClientPackageRepository pkgRepositoryURI listApproved<br />
<br />
java ClientPackageRepository pkgRepositoryURI listNonDeployable<br />
<br />
java ClientPackageRepository pkgRepositoryURI listAllDependenciesChain serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDHNPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDLPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameVOPackages serviceID<br />
</pre><br />
<br />
Where:<br />
* pkgRepositoryURI: Package Repository address.<br />
* diligentID: The unique ID of a Service Archive.<br />
* serviceArchiveURI: The address from where the Service Archive can be downloaded.<br />
* description: The Service Archive description.<br />
* storeListFile: a list with Service Archives to store {diligentID, URI, description}.<br />
* class: The Service Class.<br />
* name: The Service Name.<br />
* packageName: The package Name.<br />
<br />
==== DILIGENT infrastructure initialization ====<br />
<br />
In order to speed up the setting up of a DILIGENT infrastructure, and align available DILIGENT packages with current development process, an automated client that initialize the core DCL services (DIS and PR) is provided with the Package Repository component. <br />
<br />
The procedure consists on a Thread that run the initialization method described below:<br />
<pre><br />
1. Download from ETICS list of last SA built<br />
2. Delete from DIS all SPs<br />
3. Delete from PR all packages<br />
4. For each SA built<br />
4.1. create a new resource into the DIS<br />
4.2. if successful store SA on PR<br />
4.2.1. if successful log success<br />
else remove resource from DIS and log failure<br />
else log failure<br />
</pre><br />
<br />
The Infrastructure Initialization Thread can be run by typing:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -initInfra<br />
</pre><br />
<br />
The same client can be used to download togheter with the SA the related Source Packages and Javadoc Packages,<br />
and create a local storage of source/bynaries/javadoc that can be stored on CVS/SVN repository.<br />
To store a SA on the PR:<br />
<pre> <br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -insert -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
</pre><br />
To update a previously stored SA on the PR ( and the related Service Profile on the DIS):<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -update -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
-update -id:<SA_ID> <br />
</pre><br />
To Remove a SA from the PR (and the related ServiceProfile from the DIS)<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -delete -id:<SA_ID><br />
</pre><br />
To Download a SA binary package togheter with the related source packages and javadoc packages:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -get -module:<SERVICE_ARCHIVE_MODULE_NAME> <br />
</pre><br />
<br />
<br />
<br />
===== Dependencies =====<br />
* activation.jar<br />
* commons-compress-20061201.jar<br />
* jaxb-api.jar<br />
* jaxb-impl.jar<br />
* jaxb-xjc.jar<br />
* jaxb1-impl.jar<br />
* jsr173_api.jar<br />
* org_diligentproject_common_profilemanager.jar<br />
* org_diligentproject_keeperservice_packagerepository_stubs.jar<br />
* org_diligentproject_informationservice_disregistry_stubs.jar<br />
<br />
===== Usage =====<br />
<br />
Update appropriately the required parameters on the properties file <br />
<pre><br />
org/diligentproject/keeperservice/packagerepositoryclients/InfrastructureInitialization.properties<br />
</pre><br />
to refer to a completely deployed infrastructure:<br />
* VERSION the gCube SA Version (i.e. 0.3.0)<br />
* REPOSITORY_DIR the local dir where a SVN/CVS Repository is defined<br />
* SLEEP_TIME: Thread sleep time in minutes<br />
* TMP_DIR: directory where all Service Archives from build repository will be downloaded and parsed<br />
* ETICS_SA_LIST_URL: build repository URI<br />
* VO: The VO to Initialize<br />
* PR_EPR: PR to update address<br />
* SECURITY_ENABLED true/false if the security is enabled on the infra<br />
* UPDATE_PR true/false if the Initialization thread has to update the PR<br />
* UPDATE_DIS true/false if the Initialization thread has to update the DIS<br />
* PROXY_FILE the local proxy file<br />
* BASE_HTTP_ULR teh base HTTP Url where Etics SA are stored<br />
* LOG4JFILE a custom log4j <br />
<br />
Run the program from a machine with the CLASSPATH set appropriately.<br />
<br />
=== Know Bugs and Limitations ===<br />
<br />
In current implementation the proxy to access to the Grid need to be created manually.</div>Andreahttps://wiki.gcube-system.org/index.php?title=Package_Repository&diff=3377Package Repository2007-12-12T11:52:37Z<p>Andrea: /* Usage */</p>
<hr />
<div>== Package Repository ==<br />
<br />
=== Introduction ===<br />
<br />
The Package Repository validates, stores, and manages DILIGENT packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. <br />
<br />
This repository accepts registration requests coming from the Service Archive Registration Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
<br />
=== Implentation Overview ===<br />
<br />
This component is responsible for the validation, storage, and maintenance of the [[ Service_Archive_Specification | DILIGENT service archives]], each service archive contains all files declared on the [[ Profile_Specification | Service Profile]] . It checks packages dependencies and by ensuring access to them, it supports the dynamic packages deployment. <br />
<br />
The Package Repository is a WSRF service, implemented as specified by the Singleton Pattern . Accordingly, it splits the implementation into three sub-components: (i) the resource itself that contains Package Repository state, (ii) the resource home that manages the resource, and (iii) the web service that gives access to components functionality. <br />
<br />
The resource state contains information about the stored service archives. The resource home is used by the web service to create and find the resource. <br />
<br />
The web service provides to the clients, e.g. HNM, access to the Package Repository functionality ([[ Package_Repository#Functionality | see below ]]).<br />
<br />
This service is internally composed by a (i) Parser component and by a (ii) Grid access interface.<br />
<br />
Parser component includes a Validation phase that checks service archives based on service profiles declarations. It assumes that service profiles are valid against the service profile schema. Controls performed includes checking that all declared files are in the right place into the service archive structure, that all service profiles includes at least a WSRF service, that the declared stubs library point to the corresponding package, etc. After this phase was completed PR create a tar gz file for each declared pakage that is provided on request to the HNM.<br />
<br />
Grid Access inteface is in charge of store all PR data structures and packages into the Grid, as well as get from the Grid packages when requested.<br />
Package Repository stores all its data structures and packages into a local cache and into the Grid.<br />
<br />
<br />
==== Functionality ====<br />
<br />
The signatures of the actual implemented methods are presented below. These operations allow uploading, deleting, list, and getting a DILIGENT package. As well as other advanced operations that operate over packages dependencies. <br />
<br />
<br />
:1. '''store'''<br />
<pre><br />
store (ServiceIDURLDescription) -> String<br />
</pre><br />
<br />
This operation stores a service archive into the Package Repository and assigns status pending to it. Pending status means that service archive is valid, and unique ID was not previously used but cannot be deployed.<br />
<br />
''ServiceIDURLDescription'' type contains the unique ID assigned to the service, the URL from where the service archive can be downloaded, and the service description.<br />
<br />
''Return'' String contains unique ID if service archive is valid, null otherwise.<br />
<br />
:2. '''approve'''<br />
<pre><br />
approve (String) -> String<br />
</pre><br />
<br />
Approve an already stored service achive, if unique ID passed exists with pending status.<br />
<br />
''Return'' It returns approved if operation success, an error message otherwise.<br />
<br />
:3. '''delete'''<br />
<pre><br />
delete (String) -> String<br />
</pre><br />
<br />
This operation deletes a stored DILIGENT service archive from the Package Repository if unique ID passed exists. This implies the removal of all software packages from the Grid and from the local cache. <br />
<br />
''Return'' A message reporting success of failure is returned.<br />
<br />
:4. '''get'''<br />
<pre><br />
get (ServiceIDPackage) -> String<br />
</pre><br />
<br />
To identify an unique package on the repository two values must be provided: (i) DILIGENT unique ID and (ii) package name.<br />
<br />
''Return'' The method returns the URI from where the requested package can be downloaded.<br />
<br />
:5. '''getServiceProfile'''<br />
<pre><br />
getServiceProfile (String) -> String<br />
</pre><br />
<br />
''Return'' From a given unique ID this method return the corresponding Service Profile if exists, null otherwise.<br />
<br />
:6. '''getServiceProfileID'''<br />
<pre><br />
getServiceProfileID (ClsssName) -> String<br />
</pre><br />
<br />
''Return'' From a given class and name parameter this method return the corresponding DILIGENT unique ID if exists, null otherwise.<br />
<br />
:7. '''listPending'''<br />
<pre><br />
listPending ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status pending. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:8. '''listApproved'''<br />
<pre><br />
listApproved ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status approved. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:9. '''listNonDeployableServices'''<br />
<pre><br />
listNonDeployableServices ( ) -> String<br />
</pre><br />
<br />
With this functionality it is possible to know which stored packages are not deployable due missing dependencies.<br />
<br />
''Return'' a XML with the following structure:<br />
<pre><br />
<Resultset><br />
<Result><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:10. '''listAllDependenciesChain'''<br />
<pre><br />
listAllDependenciesChain (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:11. '''listSameDHNPackages'''<br />
<pre><br />
listSameDHNPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DHN dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:12. '''listSameDLPackages'''<br />
<pre><br />
listSameDLPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DL dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:13. '''listSameVOPackages'''<br />
<pre><br />
listSameVOPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same VO dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type.<br />
<br />
<br />
=== Dependencies ===<br />
<br />
The dependencies of the Package Repository Service are:<br />
*DHN: to host service.<br />
*NAL: to access to HNM.<br />
*Keeper common: for type definition.<br />
*Grid Storage: to store DILIGENT packages on the Grid.<br />
*Profile Manager: to parse Service Profile<br />
*Commons-io from Jakarta: to File system functionality.<br />
*Commons-compress from Jakarta: to File compress functionality.<br />
<br />
=== Usage Example ===<br />
<br />
==== Package Repository client ====<br />
<br />
A Package Repository client is provided. The client uses all PR functionality in different ways, i.e. by calling directly the PR operations and by pre-processing the client input to generate the appropriate series of PR service calls.<br />
<br />
===== Dependencies =====<br />
* Package Repository service<br />
* Keeper common <br />
<br />
===== Usage =====<br />
<pre><br />
java ClientPackageRepository pkgRepositoryURI store diligentID serviceArchiveURI description<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeAndApproveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI approve diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI approveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI get diligentID packageName<br />
<br />
java ClientPackageRepository pkgRepositoryURI delete diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfile diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfileID class name<br />
<br />
java ClientPackageRepository pkgRepositoryURI listPending<br />
<br />
java ClientPackageRepository pkgRepositoryURI listApproved<br />
<br />
java ClientPackageRepository pkgRepositoryURI listNonDeployable<br />
<br />
java ClientPackageRepository pkgRepositoryURI listAllDependenciesChain serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDHNPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDLPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameVOPackages serviceID<br />
</pre><br />
<br />
Where:<br />
* pkgRepositoryURI: Package Repository address.<br />
* diligentID: The unique ID of a Service Archive.<br />
* serviceArchiveURI: The address from where the Service Archive can be downloaded.<br />
* description: The Service Archive description.<br />
* storeListFile: a list with Service Archives to store {diligentID, URI, description}.<br />
* class: The Service Class.<br />
* name: The Service Name.<br />
* packageName: The package Name.<br />
<br />
==== DILIGENT infrastructure initialization ====<br />
<br />
In order to speed up the setting up of a DILIGENT infrastructure, and align available DILIGENT packages with current development process, an automated client that initialize the core DCL services (DIS and PR) is provided with the Package Repository component. <br />
<br />
The procedure consists on a Thread that run the initialization method described below:<br />
<pre><br />
1. Download from ETICS list of last SA built<br />
2. Delete from DIS all SPs<br />
3. Delete from PR all packages<br />
4. For each SA built<br />
4.1. create a new resource into the DIS<br />
4.2. if successful store SA on PR<br />
4.2.1. if successful log success<br />
else remove resource from DIS and log failure<br />
else log failure<br />
</pre><br />
<br />
The Infrastructure Initialization Thread can be run by typing:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -initInfra<br />
</pre><br />
<br />
The same client can be used to download togheter with the SA the related Source Packages and Javadoc Packages,<br />
and create a local storage of source/bynaries/javadoc that can be stored on CVS/SVN repository.<br />
To store a SA on the PR:<br />
<pre> <br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -insert -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
</pre><br />
To update a previously stored SA on the PR ( and the related Service Profile on the DIS):<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -update -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
-update -id:<SA_ID> <br />
</pre><br />
To Remove a SA from the PR (and the related ServiceProfile from the DIS)<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -delete -id:<SA_ID><br />
</pre><br />
To Download a SA binary package togheter with the related source packages and javadoc packages:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -get -module:<SERVICE_ARCHIVE_MODULE_NAME> <br />
</pre><br />
<br />
<br />
<br />
===== Dependencies =====<br />
* activation.jar<br />
* commons-compress-20061201.jar<br />
* jaxb-api.jar<br />
* jaxb-impl.jar<br />
* jaxb-xjc.jar<br />
* jaxb1-impl.jar<br />
* jsr173_api.jar<br />
* org_diligentproject_common_profilemanager.jar<br />
* org_diligentproject_keeperservice_packagerepository_stubs.jar<br />
* org_diligentproject_informationservice_disregistry_stubs.jar<br />
* source globus-devel-env.sh<br />
<br />
<br />
<br />
===== Usage =====<br />
<br />
Update appropriately the required parameters on the properties file <br />
<pre><br />
org/diligentproject/keeperservice/packagerepositoryclients/InfrastructureInitialization.properties<br />
</pre><br />
to refer to a completely deployed infrastructure:<br />
* VERSION the gCube SA Version (i.e. 0.3.0)<br />
* REPOSITORY_DIR the local dir where a SVN/CVS Repository is defined<br />
* SLEEP_TIME: Thread sleep time in minutes<br />
* TMP_DIR: directory where all Service Archives from build repository will be downloaded and parsed<br />
* ETICS_SA_LIST_URL: build repository URI<br />
* VO: The VO to Initialize<br />
* PR_EPR: PR to update address<br />
* SECURITY_ENABLED true/false if the security is enabled on the infra<br />
* UPDATE_PR true/false if the Initialization thread has to update the PR<br />
* UPDATE_DIS true/false if the Initialization thread has to update the DIS<br />
* PROXY_FILE the local proxy file<br />
* BASE_HTTP_ULR teh base HTTP Url where Etics SA are stored<br />
* LOG4JFILE a custom log4j <br />
<br />
Run the program from a machine with the CLASSPATH set appropriately.<br />
<br />
=== Know Bugs and Limitations ===<br />
<br />
In current implementation the proxy to access to the Grid need to be created manually.</div>Andreahttps://wiki.gcube-system.org/index.php?title=Package_Repository&diff=3373Package Repository2007-12-12T11:43:00Z<p>Andrea: /* DILIGENT infrastructure initialization */</p>
<hr />
<div>== Package Repository ==<br />
<br />
=== Introduction ===<br />
<br />
The Package Repository validates, stores, and manages DILIGENT packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. <br />
<br />
This repository accepts registration requests coming from the Service Archive Registration Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
<br />
=== Implentation Overview ===<br />
<br />
This component is responsible for the validation, storage, and maintenance of the [[ Service_Archive_Specification | DILIGENT service archives]], each service archive contains all files declared on the [[ Profile_Specification | Service Profile]] . It checks packages dependencies and by ensuring access to them, it supports the dynamic packages deployment. <br />
<br />
The Package Repository is a WSRF service, implemented as specified by the Singleton Pattern . Accordingly, it splits the implementation into three sub-components: (i) the resource itself that contains Package Repository state, (ii) the resource home that manages the resource, and (iii) the web service that gives access to components functionality. <br />
<br />
The resource state contains information about the stored service archives. The resource home is used by the web service to create and find the resource. <br />
<br />
The web service provides to the clients, e.g. HNM, access to the Package Repository functionality ([[ Package_Repository#Functionality | see below ]]).<br />
<br />
This service is internally composed by a (i) Parser component and by a (ii) Grid access interface.<br />
<br />
Parser component includes a Validation phase that checks service archives based on service profiles declarations. It assumes that service profiles are valid against the service profile schema. Controls performed includes checking that all declared files are in the right place into the service archive structure, that all service profiles includes at least a WSRF service, that the declared stubs library point to the corresponding package, etc. After this phase was completed PR create a tar gz file for each declared pakage that is provided on request to the HNM.<br />
<br />
Grid Access inteface is in charge of store all PR data structures and packages into the Grid, as well as get from the Grid packages when requested.<br />
Package Repository stores all its data structures and packages into a local cache and into the Grid.<br />
<br />
<br />
==== Functionality ====<br />
<br />
The signatures of the actual implemented methods are presented below. These operations allow uploading, deleting, list, and getting a DILIGENT package. As well as other advanced operations that operate over packages dependencies. <br />
<br />
<br />
:1. '''store'''<br />
<pre><br />
store (ServiceIDURLDescription) -> String<br />
</pre><br />
<br />
This operation stores a service archive into the Package Repository and assigns status pending to it. Pending status means that service archive is valid, and unique ID was not previously used but cannot be deployed.<br />
<br />
''ServiceIDURLDescription'' type contains the unique ID assigned to the service, the URL from where the service archive can be downloaded, and the service description.<br />
<br />
''Return'' String contains unique ID if service archive is valid, null otherwise.<br />
<br />
:2. '''approve'''<br />
<pre><br />
approve (String) -> String<br />
</pre><br />
<br />
Approve an already stored service achive, if unique ID passed exists with pending status.<br />
<br />
''Return'' It returns approved if operation success, an error message otherwise.<br />
<br />
:3. '''delete'''<br />
<pre><br />
delete (String) -> String<br />
</pre><br />
<br />
This operation deletes a stored DILIGENT service archive from the Package Repository if unique ID passed exists. This implies the removal of all software packages from the Grid and from the local cache. <br />
<br />
''Return'' A message reporting success of failure is returned.<br />
<br />
:4. '''get'''<br />
<pre><br />
get (ServiceIDPackage) -> String<br />
</pre><br />
<br />
To identify an unique package on the repository two values must be provided: (i) DILIGENT unique ID and (ii) package name.<br />
<br />
''Return'' The method returns the URI from where the requested package can be downloaded.<br />
<br />
:5. '''getServiceProfile'''<br />
<pre><br />
getServiceProfile (String) -> String<br />
</pre><br />
<br />
''Return'' From a given unique ID this method return the corresponding Service Profile if exists, null otherwise.<br />
<br />
:6. '''getServiceProfileID'''<br />
<pre><br />
getServiceProfileID (ClsssName) -> String<br />
</pre><br />
<br />
''Return'' From a given class and name parameter this method return the corresponding DILIGENT unique ID if exists, null otherwise.<br />
<br />
:7. '''listPending'''<br />
<pre><br />
listPending ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status pending. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:8. '''listApproved'''<br />
<pre><br />
listApproved ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status approved. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:9. '''listNonDeployableServices'''<br />
<pre><br />
listNonDeployableServices ( ) -> String<br />
</pre><br />
<br />
With this functionality it is possible to know which stored packages are not deployable due missing dependencies.<br />
<br />
''Return'' a XML with the following structure:<br />
<pre><br />
<Resultset><br />
<Result><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:10. '''listAllDependenciesChain'''<br />
<pre><br />
listAllDependenciesChain (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:11. '''listSameDHNPackages'''<br />
<pre><br />
listSameDHNPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DHN dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:12. '''listSameDLPackages'''<br />
<pre><br />
listSameDLPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DL dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:13. '''listSameVOPackages'''<br />
<pre><br />
listSameVOPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same VO dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type.<br />
<br />
<br />
=== Dependencies ===<br />
<br />
The dependencies of the Package Repository Service are:<br />
*DHN: to host service.<br />
*NAL: to access to HNM.<br />
*Keeper common: for type definition.<br />
*Grid Storage: to store DILIGENT packages on the Grid.<br />
*Profile Manager: to parse Service Profile<br />
*Commons-io from Jakarta: to File system functionality.<br />
*Commons-compress from Jakarta: to File compress functionality.<br />
<br />
=== Usage Example ===<br />
<br />
==== Package Repository client ====<br />
<br />
A Package Repository client is provided. The client uses all PR functionality in different ways, i.e. by calling directly the PR operations and by pre-processing the client input to generate the appropriate series of PR service calls.<br />
<br />
===== Dependencies =====<br />
* Package Repository service<br />
* Keeper common <br />
<br />
===== Usage =====<br />
<pre><br />
java ClientPackageRepository pkgRepositoryURI store diligentID serviceArchiveURI description<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeAndApproveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI approve diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI approveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI get diligentID packageName<br />
<br />
java ClientPackageRepository pkgRepositoryURI delete diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfile diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfileID class name<br />
<br />
java ClientPackageRepository pkgRepositoryURI listPending<br />
<br />
java ClientPackageRepository pkgRepositoryURI listApproved<br />
<br />
java ClientPackageRepository pkgRepositoryURI listNonDeployable<br />
<br />
java ClientPackageRepository pkgRepositoryURI listAllDependenciesChain serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDHNPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDLPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameVOPackages serviceID<br />
</pre><br />
<br />
Where:<br />
* pkgRepositoryURI: Package Repository address.<br />
* diligentID: The unique ID of a Service Archive.<br />
* serviceArchiveURI: The address from where the Service Archive can be downloaded.<br />
* description: The Service Archive description.<br />
* storeListFile: a list with Service Archives to store {diligentID, URI, description}.<br />
* class: The Service Class.<br />
* name: The Service Name.<br />
* packageName: The package Name.<br />
<br />
==== DILIGENT infrastructure initialization ====<br />
<br />
In order to speed up the setting up of a DILIGENT infrastructure, and align available DILIGENT packages with current development process, an automated client that initialize the core DCL services (DIS and PR) is provided with the Package Repository component. <br />
<br />
The procedure consists on a Thread that run the initialization method described below:<br />
<pre><br />
1. Download from ETICS list of last SA built<br />
2. Delete from DIS all SPs<br />
3. Delete from PR all packages<br />
4. For each SA built<br />
4.1. create a new resource into the DIS<br />
4.2. if successful store SA on PR<br />
4.2.1. if successful log success<br />
else remove resource from DIS and log failure<br />
else log failure<br />
</pre><br />
<br />
The Infrastructure Initialization Thread can be run by typing:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -initInfra<br />
</pre><br />
<br />
The same client can be used to download togheter with the SA the related Source Packages and Javadoc Packages,<br />
and create a local storage of source/bynaries/javadoc that can be stored on CVS/SVN repository.<br />
To store a SA on the PR:<br />
<pre> <br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -insert -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
</pre><br />
To update a previously stored SA on the PR ( and the related Service Profile on the DIS):<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -update -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
-update -id:<SA_ID> <br />
</pre><br />
To Remove a SA from the PR (and the related ServiceProfile from the DIS)<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -delete -id:<SA_ID><br />
</pre><br />
To Download a SA binary package togheter with the related source packages and javadoc packages:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -get -module:<SERVICE_ARCHIVE_MODULE_NAME> <br />
</pre><br />
<br />
<br />
<br />
===== Dependencies =====<br />
* activation.jar<br />
* commons-compress-20061201.jar<br />
* jaxb-api.jar<br />
* jaxb-impl.jar<br />
* jaxb-xjc.jar<br />
* jaxb1-impl.jar<br />
* jsr173_api.jar<br />
* org_diligentproject_common_profilemanager.jar<br />
* org_diligentproject_keeperservice_packagerepository_stubs.jar<br />
* org_diligentproject_informationservice_disregistry_stubs.jar<br />
* source globus-devel-env.sh<br />
<br />
<br />
<br />
===== Usage =====<br />
<br />
Update appropriately the required parameters on the properties file <br />
<pre><br />
org/diligentproject/keeperservice/packagerepositoryclients/InfrastructureInitialization.properties<br />
</pre><br />
to refer to a completely deployed infrastructure:<br />
<br />
* SLEEP_TIME: Thread sleep time in minutes<br />
* TMP_DIR: directory where all Service Archives from build repository will be downloaded and parsed<br />
* ETICS_SA_LIST_URL: build repository URI<br />
* VO: The VO to Initialize<br />
* PR_EPR: PR to update address<br />
<br />
Run the program from a machine with the CLASSPATH set appropriately.<br />
<br />
=== Know Bugs and Limitations ===<br />
<br />
In current implementation the proxy to access to the Grid need to be created manually.</div>Andreahttps://wiki.gcube-system.org/index.php?title=Package_Repository&diff=3372Package Repository2007-12-12T11:42:45Z<p>Andrea: /* DILIGENT infrastructure initialization */</p>
<hr />
<div>== Package Repository ==<br />
<br />
=== Introduction ===<br />
<br />
The Package Repository validates, stores, and manages DILIGENT packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. <br />
<br />
This repository accepts registration requests coming from the Service Archive Registration Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
<br />
=== Implentation Overview ===<br />
<br />
This component is responsible for the validation, storage, and maintenance of the [[ Service_Archive_Specification | DILIGENT service archives]], each service archive contains all files declared on the [[ Profile_Specification | Service Profile]] . It checks packages dependencies and by ensuring access to them, it supports the dynamic packages deployment. <br />
<br />
The Package Repository is a WSRF service, implemented as specified by the Singleton Pattern . Accordingly, it splits the implementation into three sub-components: (i) the resource itself that contains Package Repository state, (ii) the resource home that manages the resource, and (iii) the web service that gives access to components functionality. <br />
<br />
The resource state contains information about the stored service archives. The resource home is used by the web service to create and find the resource. <br />
<br />
The web service provides to the clients, e.g. HNM, access to the Package Repository functionality ([[ Package_Repository#Functionality | see below ]]).<br />
<br />
This service is internally composed by a (i) Parser component and by a (ii) Grid access interface.<br />
<br />
Parser component includes a Validation phase that checks service archives based on service profiles declarations. It assumes that service profiles are valid against the service profile schema. Controls performed includes checking that all declared files are in the right place into the service archive structure, that all service profiles includes at least a WSRF service, that the declared stubs library point to the corresponding package, etc. After this phase was completed PR create a tar gz file for each declared pakage that is provided on request to the HNM.<br />
<br />
Grid Access inteface is in charge of store all PR data structures and packages into the Grid, as well as get from the Grid packages when requested.<br />
Package Repository stores all its data structures and packages into a local cache and into the Grid.<br />
<br />
<br />
==== Functionality ====<br />
<br />
The signatures of the actual implemented methods are presented below. These operations allow uploading, deleting, list, and getting a DILIGENT package. As well as other advanced operations that operate over packages dependencies. <br />
<br />
<br />
:1. '''store'''<br />
<pre><br />
store (ServiceIDURLDescription) -> String<br />
</pre><br />
<br />
This operation stores a service archive into the Package Repository and assigns status pending to it. Pending status means that service archive is valid, and unique ID was not previously used but cannot be deployed.<br />
<br />
''ServiceIDURLDescription'' type contains the unique ID assigned to the service, the URL from where the service archive can be downloaded, and the service description.<br />
<br />
''Return'' String contains unique ID if service archive is valid, null otherwise.<br />
<br />
:2. '''approve'''<br />
<pre><br />
approve (String) -> String<br />
</pre><br />
<br />
Approve an already stored service achive, if unique ID passed exists with pending status.<br />
<br />
''Return'' It returns approved if operation success, an error message otherwise.<br />
<br />
:3. '''delete'''<br />
<pre><br />
delete (String) -> String<br />
</pre><br />
<br />
This operation deletes a stored DILIGENT service archive from the Package Repository if unique ID passed exists. This implies the removal of all software packages from the Grid and from the local cache. <br />
<br />
''Return'' A message reporting success of failure is returned.<br />
<br />
:4. '''get'''<br />
<pre><br />
get (ServiceIDPackage) -> String<br />
</pre><br />
<br />
To identify an unique package on the repository two values must be provided: (i) DILIGENT unique ID and (ii) package name.<br />
<br />
''Return'' The method returns the URI from where the requested package can be downloaded.<br />
<br />
:5. '''getServiceProfile'''<br />
<pre><br />
getServiceProfile (String) -> String<br />
</pre><br />
<br />
''Return'' From a given unique ID this method return the corresponding Service Profile if exists, null otherwise.<br />
<br />
:6. '''getServiceProfileID'''<br />
<pre><br />
getServiceProfileID (ClsssName) -> String<br />
</pre><br />
<br />
''Return'' From a given class and name parameter this method return the corresponding DILIGENT unique ID if exists, null otherwise.<br />
<br />
:7. '''listPending'''<br />
<pre><br />
listPending ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status pending. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:8. '''listApproved'''<br />
<pre><br />
listApproved ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status approved. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:9. '''listNonDeployableServices'''<br />
<pre><br />
listNonDeployableServices ( ) -> String<br />
</pre><br />
<br />
With this functionality it is possible to know which stored packages are not deployable due missing dependencies.<br />
<br />
''Return'' a XML with the following structure:<br />
<pre><br />
<Resultset><br />
<Result><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:10. '''listAllDependenciesChain'''<br />
<pre><br />
listAllDependenciesChain (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:11. '''listSameDHNPackages'''<br />
<pre><br />
listSameDHNPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DHN dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:12. '''listSameDLPackages'''<br />
<pre><br />
listSameDLPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DL dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:13. '''listSameVOPackages'''<br />
<pre><br />
listSameVOPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same VO dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type.<br />
<br />
<br />
=== Dependencies ===<br />
<br />
The dependencies of the Package Repository Service are:<br />
*DHN: to host service.<br />
*NAL: to access to HNM.<br />
*Keeper common: for type definition.<br />
*Grid Storage: to store DILIGENT packages on the Grid.<br />
*Profile Manager: to parse Service Profile<br />
*Commons-io from Jakarta: to File system functionality.<br />
*Commons-compress from Jakarta: to File compress functionality.<br />
<br />
=== Usage Example ===<br />
<br />
==== Package Repository client ====<br />
<br />
A Package Repository client is provided. The client uses all PR functionality in different ways, i.e. by calling directly the PR operations and by pre-processing the client input to generate the appropriate series of PR service calls.<br />
<br />
===== Dependencies =====<br />
* Package Repository service<br />
* Keeper common <br />
<br />
===== Usage =====<br />
<pre><br />
java ClientPackageRepository pkgRepositoryURI store diligentID serviceArchiveURI description<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeAndApproveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI approve diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI approveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI get diligentID packageName<br />
<br />
java ClientPackageRepository pkgRepositoryURI delete diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfile diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfileID class name<br />
<br />
java ClientPackageRepository pkgRepositoryURI listPending<br />
<br />
java ClientPackageRepository pkgRepositoryURI listApproved<br />
<br />
java ClientPackageRepository pkgRepositoryURI listNonDeployable<br />
<br />
java ClientPackageRepository pkgRepositoryURI listAllDependenciesChain serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDHNPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDLPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameVOPackages serviceID<br />
</pre><br />
<br />
Where:<br />
* pkgRepositoryURI: Package Repository address.<br />
* diligentID: The unique ID of a Service Archive.<br />
* serviceArchiveURI: The address from where the Service Archive can be downloaded.<br />
* description: The Service Archive description.<br />
* storeListFile: a list with Service Archives to store {diligentID, URI, description}.<br />
* class: The Service Class.<br />
* name: The Service Name.<br />
* packageName: The package Name.<br />
<br />
==== DILIGENT infrastructure initialization ====<br />
<br />
In order to speed up the setting up of a DILIGENT infrastructure, and align available DILIGENT packages with current development process, an automated client that initialize the core DCL services (DIS and PR) is provided with the Package Repository component. <br />
<br />
The procedure consists on a Thread that run the initialization method described below:<br />
<pre><br />
1. Download from ETICS list of last SA built<br />
2. Delete from DIS all SPs<br />
3. Delete from PR all packages<br />
4. For each SA built<br />
4.1. create a new resource into the DIS<br />
4.2. if successful store SA on PR<br />
4.2.1. if successful log success<br />
else remove resource from DIS and log failure<br />
else log failure<br />
</pre><br />
<br />
The Infrastructure Initialization Thread can be run by typing:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -initInfra<br />
</pre><br />
<br />
The same client can be used to download togheter with the SA the related Source Packages and Javadoc Packages,<br />
and create a local storage of source/bynaries/javadoc that can be stored on CVS/SVN repository.<br />
To store a SA on the PR:<br />
<pre> <br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -insert -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
</pre><br />
To update a previously stored SA on the PR ( and the related Service Profile on the DIS):<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization> -update -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
-update -id:<SA_ID> <br />
</pre><br />
To Remove a SA from the PR (and the related ServiceProfile from the DIS)<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -delete -id:<SA_ID><br />
</pre><br />
To Download a SA binary package togheter with the related source packages and javadoc packages:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -get -module:<SERVICE_ARCHIVE_MODULE_NAME> <br />
</pre><br />
<br />
<br />
<br />
===== Dependencies =====<br />
* activation.jar<br />
* commons-compress-20061201.jar<br />
* jaxb-api.jar<br />
* jaxb-impl.jar<br />
* jaxb-xjc.jar<br />
* jaxb1-impl.jar<br />
* jsr173_api.jar<br />
* org_diligentproject_common_profilemanager.jar<br />
* org_diligentproject_keeperservice_packagerepository_stubs.jar<br />
* org_diligentproject_informationservice_disregistry_stubs.jar<br />
* source globus-devel-env.sh<br />
<br />
<br />
<br />
===== Usage =====<br />
<br />
Update appropriately the required parameters on the properties file <br />
<pre><br />
org/diligentproject/keeperservice/packagerepositoryclients/InfrastructureInitialization.properties<br />
</pre><br />
to refer to a completely deployed infrastructure:<br />
<br />
* SLEEP_TIME: Thread sleep time in minutes<br />
* TMP_DIR: directory where all Service Archives from build repository will be downloaded and parsed<br />
* ETICS_SA_LIST_URL: build repository URI<br />
* VO: The VO to Initialize<br />
* PR_EPR: PR to update address<br />
<br />
Run the program from a machine with the CLASSPATH set appropriately.<br />
<br />
=== Know Bugs and Limitations ===<br />
<br />
In current implementation the proxy to access to the Grid need to be created manually.</div>Andreahttps://wiki.gcube-system.org/index.php?title=Package_Repository&diff=3371Package Repository2007-12-12T11:42:29Z<p>Andrea: /* DILIGENT infrastructure initialization */</p>
<hr />
<div>== Package Repository ==<br />
<br />
=== Introduction ===<br />
<br />
The Package Repository validates, stores, and manages DILIGENT packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. <br />
<br />
This repository accepts registration requests coming from the Service Archive Registration Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
<br />
=== Implentation Overview ===<br />
<br />
This component is responsible for the validation, storage, and maintenance of the [[ Service_Archive_Specification | DILIGENT service archives]], each service archive contains all files declared on the [[ Profile_Specification | Service Profile]] . It checks packages dependencies and by ensuring access to them, it supports the dynamic packages deployment. <br />
<br />
The Package Repository is a WSRF service, implemented as specified by the Singleton Pattern . Accordingly, it splits the implementation into three sub-components: (i) the resource itself that contains Package Repository state, (ii) the resource home that manages the resource, and (iii) the web service that gives access to components functionality. <br />
<br />
The resource state contains information about the stored service archives. The resource home is used by the web service to create and find the resource. <br />
<br />
The web service provides to the clients, e.g. HNM, access to the Package Repository functionality ([[ Package_Repository#Functionality | see below ]]).<br />
<br />
This service is internally composed by a (i) Parser component and by a (ii) Grid access interface.<br />
<br />
Parser component includes a Validation phase that checks service archives based on service profiles declarations. It assumes that service profiles are valid against the service profile schema. Controls performed includes checking that all declared files are in the right place into the service archive structure, that all service profiles includes at least a WSRF service, that the declared stubs library point to the corresponding package, etc. After this phase was completed PR create a tar gz file for each declared pakage that is provided on request to the HNM.<br />
<br />
Grid Access inteface is in charge of store all PR data structures and packages into the Grid, as well as get from the Grid packages when requested.<br />
Package Repository stores all its data structures and packages into a local cache and into the Grid.<br />
<br />
<br />
==== Functionality ====<br />
<br />
The signatures of the actual implemented methods are presented below. These operations allow uploading, deleting, list, and getting a DILIGENT package. As well as other advanced operations that operate over packages dependencies. <br />
<br />
<br />
:1. '''store'''<br />
<pre><br />
store (ServiceIDURLDescription) -> String<br />
</pre><br />
<br />
This operation stores a service archive into the Package Repository and assigns status pending to it. Pending status means that service archive is valid, and unique ID was not previously used but cannot be deployed.<br />
<br />
''ServiceIDURLDescription'' type contains the unique ID assigned to the service, the URL from where the service archive can be downloaded, and the service description.<br />
<br />
''Return'' String contains unique ID if service archive is valid, null otherwise.<br />
<br />
:2. '''approve'''<br />
<pre><br />
approve (String) -> String<br />
</pre><br />
<br />
Approve an already stored service achive, if unique ID passed exists with pending status.<br />
<br />
''Return'' It returns approved if operation success, an error message otherwise.<br />
<br />
:3. '''delete'''<br />
<pre><br />
delete (String) -> String<br />
</pre><br />
<br />
This operation deletes a stored DILIGENT service archive from the Package Repository if unique ID passed exists. This implies the removal of all software packages from the Grid and from the local cache. <br />
<br />
''Return'' A message reporting success of failure is returned.<br />
<br />
:4. '''get'''<br />
<pre><br />
get (ServiceIDPackage) -> String<br />
</pre><br />
<br />
To identify an unique package on the repository two values must be provided: (i) DILIGENT unique ID and (ii) package name.<br />
<br />
''Return'' The method returns the URI from where the requested package can be downloaded.<br />
<br />
:5. '''getServiceProfile'''<br />
<pre><br />
getServiceProfile (String) -> String<br />
</pre><br />
<br />
''Return'' From a given unique ID this method return the corresponding Service Profile if exists, null otherwise.<br />
<br />
:6. '''getServiceProfileID'''<br />
<pre><br />
getServiceProfileID (ClsssName) -> String<br />
</pre><br />
<br />
''Return'' From a given class and name parameter this method return the corresponding DILIGENT unique ID if exists, null otherwise.<br />
<br />
:7. '''listPending'''<br />
<pre><br />
listPending ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status pending. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:8. '''listApproved'''<br />
<pre><br />
listApproved ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status approved. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:9. '''listNonDeployableServices'''<br />
<pre><br />
listNonDeployableServices ( ) -> String<br />
</pre><br />
<br />
With this functionality it is possible to know which stored packages are not deployable due missing dependencies.<br />
<br />
''Return'' a XML with the following structure:<br />
<pre><br />
<Resultset><br />
<Result><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:10. '''listAllDependenciesChain'''<br />
<pre><br />
listAllDependenciesChain (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:11. '''listSameDHNPackages'''<br />
<pre><br />
listSameDHNPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DHN dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:12. '''listSameDLPackages'''<br />
<pre><br />
listSameDLPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DL dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:13. '''listSameVOPackages'''<br />
<pre><br />
listSameVOPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same VO dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type.<br />
<br />
<br />
=== Dependencies ===<br />
<br />
The dependencies of the Package Repository Service are:<br />
*DHN: to host service.<br />
*NAL: to access to HNM.<br />
*Keeper common: for type definition.<br />
*Grid Storage: to store DILIGENT packages on the Grid.<br />
*Profile Manager: to parse Service Profile<br />
*Commons-io from Jakarta: to File system functionality.<br />
*Commons-compress from Jakarta: to File compress functionality.<br />
<br />
=== Usage Example ===<br />
<br />
==== Package Repository client ====<br />
<br />
A Package Repository client is provided. The client uses all PR functionality in different ways, i.e. by calling directly the PR operations and by pre-processing the client input to generate the appropriate series of PR service calls.<br />
<br />
===== Dependencies =====<br />
* Package Repository service<br />
* Keeper common <br />
<br />
===== Usage =====<br />
<pre><br />
java ClientPackageRepository pkgRepositoryURI store diligentID serviceArchiveURI description<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeAndApproveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI approve diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI approveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI get diligentID packageName<br />
<br />
java ClientPackageRepository pkgRepositoryURI delete diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfile diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfileID class name<br />
<br />
java ClientPackageRepository pkgRepositoryURI listPending<br />
<br />
java ClientPackageRepository pkgRepositoryURI listApproved<br />
<br />
java ClientPackageRepository pkgRepositoryURI listNonDeployable<br />
<br />
java ClientPackageRepository pkgRepositoryURI listAllDependenciesChain serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDHNPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDLPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameVOPackages serviceID<br />
</pre><br />
<br />
Where:<br />
* pkgRepositoryURI: Package Repository address.<br />
* diligentID: The unique ID of a Service Archive.<br />
* serviceArchiveURI: The address from where the Service Archive can be downloaded.<br />
* description: The Service Archive description.<br />
* storeListFile: a list with Service Archives to store {diligentID, URI, description}.<br />
* class: The Service Class.<br />
* name: The Service Name.<br />
* packageName: The package Name.<br />
<br />
==== DILIGENT infrastructure initialization ====<br />
<br />
In order to speed up the setting up of a DILIGENT infrastructure, and align available DILIGENT packages with current development process, an automated client that initialize the core DCL services (DIS and PR) is provided with the Package Repository component. <br />
<br />
The procedure consists on a Thread that run the initialization method described below:<br />
<pre><br />
1. Download from ETICS list of last SA built<br />
2. Delete from DIS all SPs<br />
3. Delete from PR all packages<br />
4. For each SA built<br />
4.1. create a new resource into the DIS<br />
4.2. if successful store SA on PR<br />
4.2.1. if successful log success<br />
else remove resource from DIS and log failure<br />
else log failure<br />
</pre><br />
<br />
The Infrastructure Initialization Thread can be run by typing:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -initInfra<br />
</pre><br />
<br />
The same client can be used to download togheter with the SA the related Source Packages and Javadoc Packages,<br />
and create a local storage of source/bynaries/javadoc that can be stored on CVS/SVN repository.<br />
To store a SA on the PR:<br />
<pre> <br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -insert -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
</pre><br />
To update a previously stored SA on the PR ( and the related Service Profile on the DIS):<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization> -update -module:<SERVICE_ARCHIVE_MODULE_NAME> -update -id:<SA_ID> <br />
</pre><br />
To Remove a SA from the PR (and the related ServiceProfile from the DIS)<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -delete -id:<SA_ID><br />
</pre><br />
To Download a SA binary package togheter with the related source packages and javadoc packages:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -get -module:<SERVICE_ARCHIVE_MODULE_NAME> <br />
</pre><br />
<br />
<br />
<br />
===== Dependencies =====<br />
* activation.jar<br />
* commons-compress-20061201.jar<br />
* jaxb-api.jar<br />
* jaxb-impl.jar<br />
* jaxb-xjc.jar<br />
* jaxb1-impl.jar<br />
* jsr173_api.jar<br />
* org_diligentproject_common_profilemanager.jar<br />
* org_diligentproject_keeperservice_packagerepository_stubs.jar<br />
* org_diligentproject_informationservice_disregistry_stubs.jar<br />
* source globus-devel-env.sh<br />
<br />
<br />
<br />
===== Usage =====<br />
<br />
Update appropriately the required parameters on the properties file <br />
<pre><br />
org/diligentproject/keeperservice/packagerepositoryclients/InfrastructureInitialization.properties<br />
</pre><br />
to refer to a completely deployed infrastructure:<br />
<br />
* SLEEP_TIME: Thread sleep time in minutes<br />
* TMP_DIR: directory where all Service Archives from build repository will be downloaded and parsed<br />
* ETICS_SA_LIST_URL: build repository URI<br />
* VO: The VO to Initialize<br />
* PR_EPR: PR to update address<br />
<br />
Run the program from a machine with the CLASSPATH set appropriately.<br />
<br />
=== Know Bugs and Limitations ===<br />
<br />
In current implementation the proxy to access to the Grid need to be created manually.</div>Andreahttps://wiki.gcube-system.org/index.php?title=Package_Repository&diff=3370Package Repository2007-12-12T11:42:00Z<p>Andrea: /* DILIGENT infrastructure initialization */</p>
<hr />
<div>== Package Repository ==<br />
<br />
=== Introduction ===<br />
<br />
The Package Repository validates, stores, and manages DILIGENT packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. <br />
<br />
This repository accepts registration requests coming from the Service Archive Registration Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
<br />
=== Implentation Overview ===<br />
<br />
This component is responsible for the validation, storage, and maintenance of the [[ Service_Archive_Specification | DILIGENT service archives]], each service archive contains all files declared on the [[ Profile_Specification | Service Profile]] . It checks packages dependencies and by ensuring access to them, it supports the dynamic packages deployment. <br />
<br />
The Package Repository is a WSRF service, implemented as specified by the Singleton Pattern . Accordingly, it splits the implementation into three sub-components: (i) the resource itself that contains Package Repository state, (ii) the resource home that manages the resource, and (iii) the web service that gives access to components functionality. <br />
<br />
The resource state contains information about the stored service archives. The resource home is used by the web service to create and find the resource. <br />
<br />
The web service provides to the clients, e.g. HNM, access to the Package Repository functionality ([[ Package_Repository#Functionality | see below ]]).<br />
<br />
This service is internally composed by a (i) Parser component and by a (ii) Grid access interface.<br />
<br />
Parser component includes a Validation phase that checks service archives based on service profiles declarations. It assumes that service profiles are valid against the service profile schema. Controls performed includes checking that all declared files are in the right place into the service archive structure, that all service profiles includes at least a WSRF service, that the declared stubs library point to the corresponding package, etc. After this phase was completed PR create a tar gz file for each declared pakage that is provided on request to the HNM.<br />
<br />
Grid Access inteface is in charge of store all PR data structures and packages into the Grid, as well as get from the Grid packages when requested.<br />
Package Repository stores all its data structures and packages into a local cache and into the Grid.<br />
<br />
<br />
==== Functionality ====<br />
<br />
The signatures of the actual implemented methods are presented below. These operations allow uploading, deleting, list, and getting a DILIGENT package. As well as other advanced operations that operate over packages dependencies. <br />
<br />
<br />
:1. '''store'''<br />
<pre><br />
store (ServiceIDURLDescription) -> String<br />
</pre><br />
<br />
This operation stores a service archive into the Package Repository and assigns status pending to it. Pending status means that service archive is valid, and unique ID was not previously used but cannot be deployed.<br />
<br />
''ServiceIDURLDescription'' type contains the unique ID assigned to the service, the URL from where the service archive can be downloaded, and the service description.<br />
<br />
''Return'' String contains unique ID if service archive is valid, null otherwise.<br />
<br />
:2. '''approve'''<br />
<pre><br />
approve (String) -> String<br />
</pre><br />
<br />
Approve an already stored service achive, if unique ID passed exists with pending status.<br />
<br />
''Return'' It returns approved if operation success, an error message otherwise.<br />
<br />
:3. '''delete'''<br />
<pre><br />
delete (String) -> String<br />
</pre><br />
<br />
This operation deletes a stored DILIGENT service archive from the Package Repository if unique ID passed exists. This implies the removal of all software packages from the Grid and from the local cache. <br />
<br />
''Return'' A message reporting success of failure is returned.<br />
<br />
:4. '''get'''<br />
<pre><br />
get (ServiceIDPackage) -> String<br />
</pre><br />
<br />
To identify an unique package on the repository two values must be provided: (i) DILIGENT unique ID and (ii) package name.<br />
<br />
''Return'' The method returns the URI from where the requested package can be downloaded.<br />
<br />
:5. '''getServiceProfile'''<br />
<pre><br />
getServiceProfile (String) -> String<br />
</pre><br />
<br />
''Return'' From a given unique ID this method return the corresponding Service Profile if exists, null otherwise.<br />
<br />
:6. '''getServiceProfileID'''<br />
<pre><br />
getServiceProfileID (ClsssName) -> String<br />
</pre><br />
<br />
''Return'' From a given class and name parameter this method return the corresponding DILIGENT unique ID if exists, null otherwise.<br />
<br />
:7. '''listPending'''<br />
<pre><br />
listPending ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status pending. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:8. '''listApproved'''<br />
<pre><br />
listApproved ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status approved. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:9. '''listNonDeployableServices'''<br />
<pre><br />
listNonDeployableServices ( ) -> String<br />
</pre><br />
<br />
With this functionality it is possible to know which stored packages are not deployable due missing dependencies.<br />
<br />
''Return'' a XML with the following structure:<br />
<pre><br />
<Resultset><br />
<Result><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:10. '''listAllDependenciesChain'''<br />
<pre><br />
listAllDependenciesChain (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:11. '''listSameDHNPackages'''<br />
<pre><br />
listSameDHNPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DHN dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:12. '''listSameDLPackages'''<br />
<pre><br />
listSameDLPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DL dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:13. '''listSameVOPackages'''<br />
<pre><br />
listSameVOPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same VO dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type.<br />
<br />
<br />
=== Dependencies ===<br />
<br />
The dependencies of the Package Repository Service are:<br />
*DHN: to host service.<br />
*NAL: to access to HNM.<br />
*Keeper common: for type definition.<br />
*Grid Storage: to store DILIGENT packages on the Grid.<br />
*Profile Manager: to parse Service Profile<br />
*Commons-io from Jakarta: to File system functionality.<br />
*Commons-compress from Jakarta: to File compress functionality.<br />
<br />
=== Usage Example ===<br />
<br />
==== Package Repository client ====<br />
<br />
A Package Repository client is provided. The client uses all PR functionality in different ways, i.e. by calling directly the PR operations and by pre-processing the client input to generate the appropriate series of PR service calls.<br />
<br />
===== Dependencies =====<br />
* Package Repository service<br />
* Keeper common <br />
<br />
===== Usage =====<br />
<pre><br />
java ClientPackageRepository pkgRepositoryURI store diligentID serviceArchiveURI description<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeAndApproveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI approve diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI approveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI get diligentID packageName<br />
<br />
java ClientPackageRepository pkgRepositoryURI delete diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfile diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfileID class name<br />
<br />
java ClientPackageRepository pkgRepositoryURI listPending<br />
<br />
java ClientPackageRepository pkgRepositoryURI listApproved<br />
<br />
java ClientPackageRepository pkgRepositoryURI listNonDeployable<br />
<br />
java ClientPackageRepository pkgRepositoryURI listAllDependenciesChain serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDHNPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDLPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameVOPackages serviceID<br />
</pre><br />
<br />
Where:<br />
* pkgRepositoryURI: Package Repository address.<br />
* diligentID: The unique ID of a Service Archive.<br />
* serviceArchiveURI: The address from where the Service Archive can be downloaded.<br />
* description: The Service Archive description.<br />
* storeListFile: a list with Service Archives to store {diligentID, URI, description}.<br />
* class: The Service Class.<br />
* name: The Service Name.<br />
* packageName: The package Name.<br />
<br />
==== DILIGENT infrastructure initialization ====<br />
<br />
In order to speed up the setting up of a DILIGENT infrastructure, and align available DILIGENT packages with current development process, an automated client that initialize the core DCL services (DIS and PR) is provided with the Package Repository component. <br />
<br />
The procedure consists on a Thread that run the initialization method described below:<br />
<pre><br />
1. Download from ETICS list of last SA built<br />
2. Delete from DIS all SPs<br />
3. Delete from PR all packages<br />
4. For each SA built<br />
4.1. create a new resource into the DIS<br />
4.2. if successful store SA on PR<br />
4.2.1. if successful log success<br />
else remove resource from DIS and log failure<br />
else log failure<br />
</pre><br />
<br />
The client can be run by typing:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -initInfra<br />
</pre><br />
<br />
The same client can be used to download togheter with the SA the related Source Packages and Javadoc Packages,<br />
and create a local storage of source/bynaries/javadoc that can be stored on CVS/SVN repository.<br />
To store a SA on the PR:<br />
<pre> <br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -insert -module:<SERVICE_ARCHIVE_MODULE_NAME><br />
</pre><br />
To update a previously stored SA on the PR ( and the related Service Profile on the DIS):<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization> -update -module:<SERVICE_ARCHIVE_MODULE_NAME> -update -id:<SA_ID> <br />
</pre><br />
To Remove a SA from the PR (and the related ServiceProfile from the DIS)<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -delete -id:<SA_ID><br />
</pre><br />
To Download a SA binary package togheter with the related source packages and javadoc packages:<br />
<pre><br />
java org.diligentproject.keeperservice.packagerepositoryclients.InfrastructureInitialization -get -module:<SERVICE_ARCHIVE_MODULE_NAME> <br />
</pre><br />
<br />
<br />
<br />
===== Dependencies =====<br />
* activation.jar<br />
* commons-compress-20061201.jar<br />
* jaxb-api.jar<br />
* jaxb-impl.jar<br />
* jaxb-xjc.jar<br />
* jaxb1-impl.jar<br />
* jsr173_api.jar<br />
* org_diligentproject_common_profilemanager.jar<br />
* org_diligentproject_keeperservice_packagerepository_stubs.jar<br />
* org_diligentproject_informationservice_disregistry_stubs.jar<br />
* source globus-devel-env.sh<br />
<br />
<br />
<br />
===== Usage =====<br />
<br />
Update appropriately the required parameters on the properties file <br />
<pre><br />
org/diligentproject/keeperservice/packagerepositoryclients/InfrastructureInitialization.properties<br />
</pre><br />
to refer to a completely deployed infrastructure:<br />
<br />
* SLEEP_TIME: Thread sleep time in minutes<br />
* TMP_DIR: directory where all Service Archives from build repository will be downloaded and parsed<br />
* ETICS_SA_LIST_URL: build repository URI<br />
* VO: The VO to Initialize<br />
* PR_EPR: PR to update address<br />
<br />
Run the program from a machine with the CLASSPATH set appropriately.<br />
<br />
=== Know Bugs and Limitations ===<br />
<br />
In current implementation the proxy to access to the Grid need to be created manually.</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=3363Core Services Installation2007-12-12T10:52:13Z<p>Andrea: /* Security Setting */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 DL service and the HNM service. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to persist its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed together with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
=== DL Management ===<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
==== Security Settings ====<br />
<br />
<br />
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.<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
==== Post-installation configuration ====<br />
<br />
The DLManagement Service installation depends on the type of VO that the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
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:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLManagement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
==== Installation troubleshooting ====<br />
No known problem to be reported.<br />
<br />
=== HNM Service ===<br />
The HNM service installation is always performed manually, since it is the service devoted to the management of the local node. Its configuration is the configuration of the DHN it manages. <br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS: the PPS infrastructure (in case the DHN has to join Arte or ImpECt VOs)<br />
** development: the development infrastructure (in case the DHN has to join the devsec VO)<br />
The default value is PPS.<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO <br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a free text placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
*''rootDHN''<br />
** state if the DHN is a root DHN or not (the root DHNs are special nodes dedicated to the VO management)<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
===== DHN static description file =====<br />
The DHN profile can be enriched with some static labels that describes the DHN characteristics. These labels are matched at deployment time with the ones reported . Such labels can be added to the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/customDHNlabels.xml'' file.<br />
<br />
===== VOMap files =====<br />
A VO Map is a file placed in the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder reporting all the basic EPRs needed to properly startup a DHN. Such EPRs are the starting point to discover all the others gCube resource available in the VO.<br />
<br><br />
An example of VO Map file can be found [[DHN_Installation:VOMap-example|here]]<br />
<br><br />
The file name has to follow a naming convention:<br />
* ''VOMap_<VO-name>.xml'' if the VO is not the root one in the current infrastructure<br />
* ''VOMap_<VO-name>_<infrastructure-name>.xml'' if the VO is the root one<br />
<br />
==== Installation troubleshooting ====<br />
In case something goes wrong in the restart of the Java WS Core container after an upgrade of the HNM Service, it is possible to source the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/utils/cleanDHNstate.sh'' script. This script cleans up the DHN state and forces the HNM Service to rebuild the DHN state from scratch. The script has to be executed when the container is not running.<br />
<br />
=== Package Repository ===<br />
The Package 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.<br />
<br />
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. <br />
<br />
Package Repository service is distributed with a [[ Package_Repository#Package_Repository_client | PR client]] that can be used to check all PR functionalities as well as a system to [[ Package_Repository#DILIGENT_infrastructure_initialization | initialize a DILIGENT infrastructure ]] from scratch.<br />
<br />
=== Pre-installation setup ===<br />
The PR Service is an Infrastructure specific service (there is the need of an instance of it for each Infrastructure). <br />
<br />
The service installation requires:<br />
* a node from where it is possible to access to the Grid storage;<br />
* a DHN installed and configured; and<br />
* a set of environment variables to be defined.<br />
<br />
==== Setting up the Access to the Grid Storage ====<br />
<br />
Access to a gLIte SE (e.g. DPM) and a gLite LFC is mandatory to run the Package Repository.<br />
<br />
From the machine where PR will be deployed execute as root following operations:<br />
<br />
'''OS and gLite Installation'''<br />
<br />
1:. Install SLC3<br />
<br />
2:. Install APT: <br />
<pre><br />
wget ftp://ftp.scientificlinux.org/linux/scientific/30x/i386/SL/RPMS/apt-xxx.i386.rpm <br />
rpm -ivh apt-XXX.i386.rpm<br />
</pre><br />
<br />
3:. Check/add APT repositories to the configuration files:<br />
<pre><br />
/etc/apt/sources.list.d/glite.list: rpm http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/ rhel30 externals Release3.0 updates<br />
/etc/apt/sources.list.d/lcg-ca.list: rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG_CA/en/i386 lcg<br />
</pre><br />
<br />
4:. Install the following APT packages:<br />
<pre><br />
apt-get install lcg_util<br />
apt-get install LFC-client LFC-interfaces<br />
apt-get install glite-security-voms-clients<br />
</pre><br />
<br />
<br />
'''Security Configuration'''<br />
<br />
1:. Install CA certificate:<br />
<pre><br />
apt-get install lcg-CA<br />
rpm -ivh ca_ENG-xxx.rpm<br />
rpm -ivh ca_UMIT-xxx.rpm<br />
</pre><br />
<br />
2:. Install VOMS server certificate:<br />
<pre><br />
/etc/grid-security/vomsdir/grids03.eng.it.pem<br />
</pre><br />
<br />
3:. Install host certificates:<br />
<pre><br />
/etc/grid-security/hostcert.pem<br />
/etc/grid-security/hostkey.pem<br />
</pre><br />
check files permissions (chmod 644 and 400)<br />
<br />
==== Install a DHN ====<br />
see [[ DHN_Installation | here ]].<br />
<br />
<br />
=== Main installation procedure ===<br />
The PR ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
<br />
1:. From the PR (user) account unpack the ServiceArchive tar.gz file;<br />
<br />
2:. Type <br />
<pre><br />
globus-deploy-gar org_diligentproject_keeperservice_packagerepository.gar <br />
</pre><br />
to deploy the PR Service on the local container; <br />
<br />
3:. Copy <br />
<pre><br />
ServiceProfile_PackageRepository_Keeper.xml <br />
</pre><br />
<br />
under the <br />
<pre><br />
$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/<br />
</pre> <br />
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.<br />
<br />
4:. Configure environment <br />
<pre><br />
* update $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_packagerepository/PackageRepository/PR.properties<br />
<br />
* update start-PR.sh script variables <br />
<br />
* change $HTTP_APACHE_DIR directory rights to allow write<br />
</pre><br />
<br />
Source start-PR.sh and ${GLOBUS_LOCATION}/etc/globus-devel-env.sh<br />
<br />
5:. Create vomses file<br />
<pre><br />
~/.glite/vomses: "diligent" "grids03.eng.it" "15001" "/O=Grid/OU=GlobusTest/OU=simpleCA-gauss.eng.it/CN=grids03.eng.it" "diligent"<br />
</pre><br />
<br />
copy user certificates to user account<br />
<pre><br />
~/.globus<br />
</pre><br />
<br />
6:. Copy all libs into Java WS-Core lib ($GLOBUS_LOCATION/lib) if not already installed <br />
<pre><br />
activation.jar (*)<br />
commons-compress-20061201.jar <br />
jaxb1-impl.jar (*)<br />
jaxb-api.jar (*)<br />
jaxb-impl.jar (*)<br />
jaxb-xjc.jar (*)<br />
jsr173_api.jar (*)<br />
org_diligentproject_common_profile.jar (*)<br />
org.diligentproject.keeperservice.hnm.impl.nal.jar (*)<br />
org_diligentproject_keeperservice_hnm_stubs.jar (*)<br />
yu_1.2_forDiligent.jar<br />
</pre><br />
<br />
(*) already installed with DHN.<br />
<br />
=== Post-installation configuration ===<br />
<br />
1:. Manual proxy generation<br />
<pre><br />
voms-proxy-init -voms diligent<br />
</pre><br />
<br />
2:. Start Apache<br />
<pre> <br />
/etc/init.d/httpd start<br />
</pre><br />
<br />
3:. Start container<br />
<pre><br />
globus-start-container -nosec -debug >container.log 2>error.log &<br />
</pre><br />
<br />
=== Testing and verifying the installation ===<br />
Check Developers manual client section....<br />
<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
First you have to create a MyProxy CAOnline Account (if not present) that will identify the DIS-Registry-Service:<br />
<pre> <br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -createCAAccount -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile> <br />
-username <username><br />
</pre><br />
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:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addContext -host <CredentialHost> -port <CredentialPort> -proxy <proxyFile><br />
-accountID <ID_Previously_Created> voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry<br />
</pre><br />
<br />
Setting DIS-Registry Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID_Previously_Created> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
<proxyFile> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library that provides DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
* VOMS-API library - A library that provides some utility method useful to manage VOMS service (part of the Diligent infrastrucutre)<br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
[[Image:Alert_icon2.gif]] A valid proxy certificate of the VOMS VO Administrator <br />
(containing the VO-Admin role at the root level) is required to install this service<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
An installer is avalible to automatically configure the infrastructure, deploy the Credentials Renewal service and configure it.<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* install the voms-proxy-init command from the rpm in http://dlib.sns.it/bscw/bscw.cgi/0/33487 (This is a temporary step to solve an installer bug)<br />
* perform an "apt-get update" and "apt-get upgrade" of the system to update the command to the current version. (This is a temporary step to solve an installer bug)<br />
* copy in the $GLOBUS_LOCATION/lib dir the comons-codec.jar and commons-httpclient.jar libraries from engrepository (use the last versions present in the engrepository). (This is a temporary step to solve an installer bug)<br />
* Unpack the ServiceArchive tar.gz file;<br />
* Enter in the install directory with the command <code>cd install</code><br />
* Set following parameters accordingly to your infrastructure in the <code>install.properties</code> file:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| voAdminProxy || The location of the proxy certificate of a VOMS VO Administrator (containing the VO-Admin role at the root level) || /root/AdminProxy<br />
|-<br />
| myProxyRepositoryHost || The host name where the myProxy Repository is running || grids02.eng.it<br />
|-<br />
| myProxyOnlineCAHost || The host name where the myProxy Online CA is running || grids04.eng.it<br />
|-<br />
| voName || The name of the VOMS VO used by this service ( as contained in the local vomses file ) || diligent<br />
|-<br />
| groupName || The group where this Credentials Renewal service will operate || /diligent<br />
|-<br />
| servletHost || The host name where the VOMS Servlet is running || grids15.eng.it<br />
|-<br />
| servletPort || The port number of the container hosting the VOMS Servlet || 8094<br />
|-<br />
| servletCertFile || The servlet certificate file || /home/dhnUser/certs/servletCertFile.pem<br />
|-<br />
| hostCertFile || The DHN certificate file (as contained in the container security descriptor file) || /etc/grid-security/containercert.pem<br />
|-<br />
| hostKeyFile || The DHN key file (as contained in the container security descriptor file) || /etc/grid-security/containerkey.pem<br />
<br />
|}<br />
* Launch the installation script using the command <code>ant -file install.xml</code>. This procedure will automatically:<br />
** Configure the VOMS selected to enable operations of the CredentialsRenewal service<br />
** Deploy the service in the local DHN<br />
** Configure the jndi-config file of the CredentialsRenewal service with parameters set in the previous installation step<br />
<br />
[[Image:Alert_icon2.gif]] '''Please be sure to start the container from the $GLOBUS_LOCATION dir.'''<br />
<br />
==== Authorization Service Installation ====<br />
The service needs only a globus-deploy-gar of the dvos.authorization.gar.<br />
<br />
<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
====Failed None of the contacted servers for diligent were capable of returning a valid AC for the user====<br />
This exception can occur if the container has not been started from the $GLOBUS_CONTAINER dir.<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=XML_Indexer&diff=3362XML Indexer2007-12-11T16:59:48Z<p>Andrea: /* Usage Examples */</p>
<hr />
<div>=== Introduction ===<br />
The XMLIndexer Service is a generic indexer of XML data homogeneous collections. The service allows creating, populating and resolving queries against such collections. <br />
We distinguish between two types of XMLIndexer, each of them manages a collection of XML documents: <br /><br />
*GenericXMLIndexer – a GenericXMLIndexer is completely unaware about the collection and the data handled. This means that it does not impose any constraint about them and, therefore, it assumes that the clients know the schema of the documents to query. It can be used each time it is useful to index and query a (temporary) set of XML data, like a result set.<br />
*MetadataXMLIndexer – a MetadataXMLIndexer is bound to a specific Metadata Collection and it is used to index the elements of such a collection. When a new indexable Metadata Collection is created, the Metadata Catalog Service creates also a new related MetadataXMLIndexer and, each time a new Metadata Object is added/updated in such collection, the Metadata Catalog Service also adds/updates the MetadataXMLIndexer by feeding it with the new element.<br />
<br />
<br />
The XMLIndexer follows the Factory pattern and it is composed by:<br />
*the XMLIndexerFactory creates new XMLIndexers<br />
*the GenericXMLIndexer service<br />
*the MetadataXMLIndexer service<br />
<br />
=== Managed Resources ===<br />
<br />
The XMLIndexerFactory creates a WS-Resource per each XMLIndexer. Since there are two kinds of XMLIndexer, there are also two kinds of WS-Resource that the Factory service can create: the GenericXMLIndexer resource and the MetadataXMLIndexer resource.<br />
The state of each Indexer is published in the DIS by means of its WS-ResourceProperties. These resource properties includes the creation parameters and, if the Indexer is a GenericXMLIndexer, the SetTerminationTime and CurrentTime WS-ResourceProperties.<br />
<br />
=== MetadataXMLIndexer ===<br />
<br />
A MetadataXMLIndexer operates over a collection of homogeneous XML documents bound to a specific Metadata Collection. Since the managed XMLDocuments are wrapped in the Metadata envelope, each document is identified by a unique ID (the Metadata Object ID) and this allows a more advanced management of this type of Indexer with respect to the GenericXMLIndexer one. In fact, this type of Indexers can be populated, updated, recreated and queried. <br />
The XMLIndexer extends the standard WSRF ImmediateResourceTermination portType implemented by the DestroyProvider operation provider and this means that it has to be explicitly destroyed.<br />
<br />
* '''<tt>AddElements(Documents[]) --> void</tt>'''<br>This operation take a list of Documents and adds them to the current collection in exist1.1 DB. A Document is a pair of id and a String representation of the XMLDocument. This operation can be used to update elements already stored given the same id of an existing document.<br><br />
* '''<tt>AddElementsRS(String) --> void</tt>'''<br>This operation take a string representing a reference to a RSLocator <tt>(see ResultSetService)</tt>. The AddElementRS create a RSReader and stores the element readed in exist1.1 DB.<br> <br />
* '''<tt>ExecuteXPath(string) --> string[]</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection.<br><br />
* '''<tt>ExecuteXPath(string) --> string</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br />
* '''<tt>ExecuteXQuery(string) --> string[]</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return an array of string.<br><br />
* '''<tt>ExecuteXPathRS(string) --> string</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br><br />
<br />
=== Implementation Detail ===<br />
<br />
The XMLIndexer Service is built as a wrapper around an XML database (eXist 1.1). At the first start up time, the service creates an embedded database instance. <br />
Each XMLIndexer manages a collection of data in the database instance. These collections are always created together with the Indexer in the case of a GenericXMLIndexer creation. On the other hand, whenever the CreateMetadataIndexer() operation is invoked on the XMLIndexerFactory, it checks if an XML collection for that Metadata Collection is already available in the database instance. If not, a new XML collection for that Metadata Collection is created, otherwise the already available collection is used.<br />
<br />
=== Dependencies ===<br />
<br />
These are the dependencies of the Service :<br />
* '''eXist1.1'''<br />
* '''ResultSetService'''<br />
<br />
=== Usage Examples ===<br />
<br />
This example shows how to create a XMLIndexer WS-Resource and how to add elements to the created collection using ResultSetService:<br />
<br />
<pre><br />
<br />
...<br />
<br />
XMLIndexerFactoryServiceAddressingLocator factoryIndexerLocator= new XMLIndexerFactoryServiceAddressingLocator();<br />
MetadataXMLIndexerServiceAddressingLocator serviceIndexerLocator= new MetadataXMLIndexerServiceAddressingLocator();<br />
<br />
try{<br />
<br />
String[] eprs=DISHLSClient.getRunningInstanceManager(credential, epr).getEPRsRIFromClassAndName("MetadataManagement", "XMLIndexer", "diligentproject/metadatamanagement/xmlindexer/XMLIndexerFactoryService", credential, epr);<br />
if (eprs.length==0) throw new Exception("non XMLIndexer Factory Service instance retreived");<br />
EndpointReferenceType factoryEPR= new EndpointReferenceType();<br />
factoryEPR.setAddress(new AttributedURI(eprs[0]));<br />
XMLIndexerFactoryPortType factoryPortType=factoryIndexerLocator.getXMLIndexerFactoryPortTypePort(factoryEPR);<br />
<br />
CreateMetadataIndexerMessage request=new metadataIndexerMessage();<br />
request.setRecreate(true);<br />
request.setId(collectionID);<br />
CreateMetadataIndexerResponse response=factoryPortType.createMetadataIndexer(request);<br />
MetadataXMLIndexerPortType indexerServicePortTypePort=serviceIndexerLocator.getMetadataXMLIndexerPortTypePort(response.getEndpointReference());<br />
indexerServicePortTypePort.addElementRS(RSlocator);<br />
<br />
}catch(Exception e){...}<br />
<br />
....</div>Andreahttps://wiki.gcube-system.org/index.php?title=XML_Indexer&diff=3361XML Indexer2007-12-11T16:57:34Z<p>Andrea: /* Usage Examples */</p>
<hr />
<div>=== Introduction ===<br />
The XMLIndexer Service is a generic indexer of XML data homogeneous collections. The service allows creating, populating and resolving queries against such collections. <br />
We distinguish between two types of XMLIndexer, each of them manages a collection of XML documents: <br /><br />
*GenericXMLIndexer – a GenericXMLIndexer is completely unaware about the collection and the data handled. This means that it does not impose any constraint about them and, therefore, it assumes that the clients know the schema of the documents to query. It can be used each time it is useful to index and query a (temporary) set of XML data, like a result set.<br />
*MetadataXMLIndexer – a MetadataXMLIndexer is bound to a specific Metadata Collection and it is used to index the elements of such a collection. When a new indexable Metadata Collection is created, the Metadata Catalog Service creates also a new related MetadataXMLIndexer and, each time a new Metadata Object is added/updated in such collection, the Metadata Catalog Service also adds/updates the MetadataXMLIndexer by feeding it with the new element.<br />
<br />
<br />
The XMLIndexer follows the Factory pattern and it is composed by:<br />
*the XMLIndexerFactory creates new XMLIndexers<br />
*the GenericXMLIndexer service<br />
*the MetadataXMLIndexer service<br />
<br />
=== Managed Resources ===<br />
<br />
The XMLIndexerFactory creates a WS-Resource per each XMLIndexer. Since there are two kinds of XMLIndexer, there are also two kinds of WS-Resource that the Factory service can create: the GenericXMLIndexer resource and the MetadataXMLIndexer resource.<br />
The state of each Indexer is published in the DIS by means of its WS-ResourceProperties. These resource properties includes the creation parameters and, if the Indexer is a GenericXMLIndexer, the SetTerminationTime and CurrentTime WS-ResourceProperties.<br />
<br />
=== MetadataXMLIndexer ===<br />
<br />
A MetadataXMLIndexer operates over a collection of homogeneous XML documents bound to a specific Metadata Collection. Since the managed XMLDocuments are wrapped in the Metadata envelope, each document is identified by a unique ID (the Metadata Object ID) and this allows a more advanced management of this type of Indexer with respect to the GenericXMLIndexer one. In fact, this type of Indexers can be populated, updated, recreated and queried. <br />
The XMLIndexer extends the standard WSRF ImmediateResourceTermination portType implemented by the DestroyProvider operation provider and this means that it has to be explicitly destroyed.<br />
<br />
* '''<tt>AddElements(Documents[]) --> void</tt>'''<br>This operation take a list of Documents and adds them to the current collection in exist1.1 DB. A Document is a pair of id and a String representation of the XMLDocument. This operation can be used to update elements already stored given the same id of an existing document.<br><br />
* '''<tt>AddElementsRS(String) --> void</tt>'''<br>This operation take a string representing a reference to a RSLocator <tt>(see ResultSetService)</tt>. The AddElementRS create a RSReader and stores the element readed in exist1.1 DB.<br> <br />
* '''<tt>ExecuteXPath(string) --> string[]</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection.<br><br />
* '''<tt>ExecuteXPath(string) --> string</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br />
* '''<tt>ExecuteXQuery(string) --> string[]</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return an array of string.<br><br />
* '''<tt>ExecuteXPathRS(string) --> string</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br><br />
<br />
=== Implementation Detail ===<br />
<br />
The XMLIndexer Service is built as a wrapper around an XML database (eXist 1.1). At the first start up time, the service creates an embedded database instance. <br />
Each XMLIndexer manages a collection of data in the database instance. These collections are always created together with the Indexer in the case of a GenericXMLIndexer creation. On the other hand, whenever the CreateMetadataIndexer() operation is invoked on the XMLIndexerFactory, it checks if an XML collection for that Metadata Collection is already available in the database instance. If not, a new XML collection for that Metadata Collection is created, otherwise the already available collection is used.<br />
<br />
=== Dependencies ===<br />
<br />
These are the dependencies of the Service :<br />
* '''eXist1.1'''<br />
* '''ResultSetService'''<br />
<br />
=== Usage Examples ===<br />
<br />
This example shows the creation of a XMLIndexer WS-Resource and adds elements to collection using ResultSetService :<br />
<br />
<pre><br />
<br />
...<br />
<br />
XMLIndexerFactoryServiceAddressingLocator factoryIndexerLocator= new XMLIndexerFactoryServiceAddressingLocator();<br />
MetadataXMLIndexerServiceAddressingLocator serviceIndexerLocator= new MetadataXMLIndexerServiceAddressingLocator();<br />
<br />
try{<br />
<br />
String[] eprs=DISHLSClient.getRunningInstanceManager(credential, epr).getEPRsRIFromClassAndName("MetadataManagement", "XMLIndexer", "diligentproject/metadatamanagement/xmlindexer/XMLIndexerFactoryService", credential, epr);<br />
if (eprs.length==0) throw new Exception("non XMLIndexer Factory Service instance retreived");<br />
EndpointReferenceType factoryEPR= new EndpointReferenceType();<br />
factoryEPR.setAddress(new AttributedURI(eprs[0]));<br />
XMLIndexerFactoryPortType factoryPortType=factoryIndexerLocator.getXMLIndexerFactoryPortTypePort(factoryEPR);<br />
<br />
CreateMetadataIndexerMessage request=new metadataIndexerMessage();<br />
request.setRecreate(true);<br />
request.setId(collectionID);<br />
CreateMetadataIndexerResponse response=factoryPortType.createMetadataIndexer(request);<br />
MetadataXMLIndexerPortType indexerServicePortTypePort=serviceIndexerLocator.getMetadataXMLIndexerPortTypePort(response.getEndpointReference());<br />
indexerServicePortTypePort.addElementRS(RSlocator);<br />
<br />
}catch(Exception e){...}<br />
<br />
....</div>Andreahttps://wiki.gcube-system.org/index.php?title=XML_Indexer&diff=3360XML Indexer2007-12-11T16:56:45Z<p>Andrea: /* Usage Examples */</p>
<hr />
<div>=== Introduction ===<br />
The XMLIndexer Service is a generic indexer of XML data homogeneous collections. The service allows creating, populating and resolving queries against such collections. <br />
We distinguish between two types of XMLIndexer, each of them manages a collection of XML documents: <br /><br />
*GenericXMLIndexer – a GenericXMLIndexer is completely unaware about the collection and the data handled. This means that it does not impose any constraint about them and, therefore, it assumes that the clients know the schema of the documents to query. It can be used each time it is useful to index and query a (temporary) set of XML data, like a result set.<br />
*MetadataXMLIndexer – a MetadataXMLIndexer is bound to a specific Metadata Collection and it is used to index the elements of such a collection. When a new indexable Metadata Collection is created, the Metadata Catalog Service creates also a new related MetadataXMLIndexer and, each time a new Metadata Object is added/updated in such collection, the Metadata Catalog Service also adds/updates the MetadataXMLIndexer by feeding it with the new element.<br />
<br />
<br />
The XMLIndexer follows the Factory pattern and it is composed by:<br />
*the XMLIndexerFactory creates new XMLIndexers<br />
*the GenericXMLIndexer service<br />
*the MetadataXMLIndexer service<br />
<br />
=== Managed Resources ===<br />
<br />
The XMLIndexerFactory creates a WS-Resource per each XMLIndexer. Since there are two kinds of XMLIndexer, there are also two kinds of WS-Resource that the Factory service can create: the GenericXMLIndexer resource and the MetadataXMLIndexer resource.<br />
The state of each Indexer is published in the DIS by means of its WS-ResourceProperties. These resource properties includes the creation parameters and, if the Indexer is a GenericXMLIndexer, the SetTerminationTime and CurrentTime WS-ResourceProperties.<br />
<br />
=== MetadataXMLIndexer ===<br />
<br />
A MetadataXMLIndexer operates over a collection of homogeneous XML documents bound to a specific Metadata Collection. Since the managed XMLDocuments are wrapped in the Metadata envelope, each document is identified by a unique ID (the Metadata Object ID) and this allows a more advanced management of this type of Indexer with respect to the GenericXMLIndexer one. In fact, this type of Indexers can be populated, updated, recreated and queried. <br />
The XMLIndexer extends the standard WSRF ImmediateResourceTermination portType implemented by the DestroyProvider operation provider and this means that it has to be explicitly destroyed.<br />
<br />
* '''<tt>AddElements(Documents[]) --> void</tt>'''<br>This operation take a list of Documents and adds them to the current collection in exist1.1 DB. A Document is a pair of id and a String representation of the XMLDocument. This operation can be used to update elements already stored given the same id of an existing document.<br><br />
* '''<tt>AddElementsRS(String) --> void</tt>'''<br>This operation take a string representing a reference to a RSLocator <tt>(see ResultSetService)</tt>. The AddElementRS create a RSReader and stores the element readed in exist1.1 DB.<br> <br />
* '''<tt>ExecuteXPath(string) --> string[]</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection.<br><br />
* '''<tt>ExecuteXPath(string) --> string</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br />
* '''<tt>ExecuteXQuery(string) --> string[]</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return an array of string.<br><br />
* '''<tt>ExecuteXPathRS(string) --> string</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br><br />
<br />
=== Implementation Detail ===<br />
<br />
The XMLIndexer Service is built as a wrapper around an XML database (eXist 1.1). At the first start up time, the service creates an embedded database instance. <br />
Each XMLIndexer manages a collection of data in the database instance. These collections are always created together with the Indexer in the case of a GenericXMLIndexer creation. On the other hand, whenever the CreateMetadataIndexer() operation is invoked on the XMLIndexerFactory, it checks if an XML collection for that Metadata Collection is already available in the database instance. If not, a new XML collection for that Metadata Collection is created, otherwise the already available collection is used.<br />
<br />
=== Dependencies ===<br />
<br />
These are the dependencies of the Service :<br />
* '''eXist1.1'''<br />
* '''ResultSetService'''<br />
<br />
=== Usage Examples ===<br />
<br />
This example shows the creation of a XMLIndexer WS-Resource and adding elements to collection:<br />
<br />
<pre><br />
<br />
...<br />
<br />
XMLIndexerFactoryServiceAddressingLocator factoryIndexerLocator= new XMLIndexerFactoryServiceAddressingLocator();<br />
MetadataXMLIndexerServiceAddressingLocator serviceIndexerLocator= new MetadataXMLIndexerServiceAddressingLocator();<br />
<br />
try{<br />
<br />
String[] eprs=DISHLSClient.getRunningInstanceManager(credential, epr).getEPRsRIFromClassAndName("MetadataManagement", "XMLIndexer", "diligentproject/metadatamanagement/xmlindexer/XMLIndexerFactoryService", credential, epr);<br />
if (eprs.length==0) throw new Exception("non XMLIndexer Factory Service instance retreived");<br />
EndpointReferenceType factoryEPR= new EndpointReferenceType();<br />
factoryEPR.setAddress(new AttributedURI(eprs[0]));<br />
XMLIndexerFactoryPortType factoryPortType=factoryIndexerLocator.getXMLIndexerFactoryPortTypePort(factoryEPR);<br />
<br />
CreateMetadataIndexerMessage request=new metadataIndexerMessage();<br />
request.setRecreate(true);<br />
request.setId(collectionID);<br />
CreateMetadataIndexerResponse response=factoryPortType.createMetadataIndexer(request);<br />
MetadataXMLIndexerPortType indexerServicePortTypePort=serviceIndexerLocator.getMetadataXMLIndexerPortTypePort(response.getEndpointReference());<br />
indexerServicePortTypePort.addElementRS(RSlocator);<br />
<br />
}catch(Exception e){...}<br />
<br />
....</div>Andreahttps://wiki.gcube-system.org/index.php?title=XML_Indexer&diff=3359XML Indexer2007-12-11T16:31:01Z<p>Andrea: /* Usage Examples */</p>
<hr />
<div>=== Introduction ===<br />
The XMLIndexer Service is a generic indexer of XML data homogeneous collections. The service allows creating, populating and resolving queries against such collections. <br />
We distinguish between two types of XMLIndexer, each of them manages a collection of XML documents: <br /><br />
*GenericXMLIndexer – a GenericXMLIndexer is completely unaware about the collection and the data handled. This means that it does not impose any constraint about them and, therefore, it assumes that the clients know the schema of the documents to query. It can be used each time it is useful to index and query a (temporary) set of XML data, like a result set.<br />
*MetadataXMLIndexer – a MetadataXMLIndexer is bound to a specific Metadata Collection and it is used to index the elements of such a collection. When a new indexable Metadata Collection is created, the Metadata Catalog Service creates also a new related MetadataXMLIndexer and, each time a new Metadata Object is added/updated in such collection, the Metadata Catalog Service also adds/updates the MetadataXMLIndexer by feeding it with the new element.<br />
<br />
<br />
The XMLIndexer follows the Factory pattern and it is composed by:<br />
*the XMLIndexerFactory creates new XMLIndexers<br />
*the GenericXMLIndexer service<br />
*the MetadataXMLIndexer service<br />
<br />
=== Managed Resources ===<br />
<br />
The XMLIndexerFactory creates a WS-Resource per each XMLIndexer. Since there are two kinds of XMLIndexer, there are also two kinds of WS-Resource that the Factory service can create: the GenericXMLIndexer resource and the MetadataXMLIndexer resource.<br />
The state of each Indexer is published in the DIS by means of its WS-ResourceProperties. These resource properties includes the creation parameters and, if the Indexer is a GenericXMLIndexer, the SetTerminationTime and CurrentTime WS-ResourceProperties.<br />
<br />
=== MetadataXMLIndexer ===<br />
<br />
A MetadataXMLIndexer operates over a collection of homogeneous XML documents bound to a specific Metadata Collection. Since the managed XMLDocuments are wrapped in the Metadata envelope, each document is identified by a unique ID (the Metadata Object ID) and this allows a more advanced management of this type of Indexer with respect to the GenericXMLIndexer one. In fact, this type of Indexers can be populated, updated, recreated and queried. <br />
The XMLIndexer extends the standard WSRF ImmediateResourceTermination portType implemented by the DestroyProvider operation provider and this means that it has to be explicitly destroyed.<br />
<br />
* '''<tt>AddElements(Documents[]) --> void</tt>'''<br>This operation take a list of Documents and adds them to the current collection in exist1.1 DB. A Document is a pair of id and a String representation of the XMLDocument. This operation can be used to update elements already stored given the same id of an existing document.<br><br />
* '''<tt>AddElementsRS(String) --> void</tt>'''<br>This operation take a string representing a reference to a RSLocator <tt>(see ResultSetService)</tt>. The AddElementRS create a RSReader and stores the element readed in exist1.1 DB.<br> <br />
* '''<tt>ExecuteXPath(string) --> string[]</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection.<br><br />
* '''<tt>ExecuteXPath(string) --> string</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br />
* '''<tt>ExecuteXQuery(string) --> string[]</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return an array of string.<br><br />
* '''<tt>ExecuteXPathRS(string) --> string</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br><br />
<br />
=== Implementation Detail ===<br />
<br />
The XMLIndexer Service is built as a wrapper around an XML database (eXist 1.1). At the first start up time, the service creates an embedded database instance. <br />
Each XMLIndexer manages a collection of data in the database instance. These collections are always created together with the Indexer in the case of a GenericXMLIndexer creation. On the other hand, whenever the CreateMetadataIndexer() operation is invoked on the XMLIndexerFactory, it checks if an XML collection for that Metadata Collection is already available in the database instance. If not, a new XML collection for that Metadata Collection is created, otherwise the already available collection is used.<br />
<br />
=== Dependencies ===<br />
<br />
These are the dependencies of the Service :<br />
* '''eXist1.1'''<br />
* '''ResultSetService'''<br />
<br />
=== Usage Examples ===<br />
<br />
<pre><br />
<br />
...<br />
<br />
XMLIndexerFactoryServiceAddressingLocator factoryIndexerLocator= new XMLIndexerFactoryServiceAddressingLocator();<br />
MetadataXMLIndexerServiceAddressingLocator serviceIndexerLocator= new MetadataXMLIndexerServiceAddressingLocator();<br />
<br />
try{<br />
<br />
String[] eprs=DISHLSClient.getRunningInstanceManager(null, null).getEPRsRIFromClassAndName("MetadataManagement", "XMLIndexer", "diligentproject/metadatamanagement/xmlindexer/XMLIndexerFactoryService", null, null);<br />
if (eprs.length==0) throw new Exception("non XMLIndexer Factory Service instance retreived");<br />
EndpointReferenceType factoryEPR= new EndpointReferenceType();<br />
factoryEPR.setAddress(new AttributedURI(eprs[0]));<br />
XMLIndexerFactoryPortType factoryPortType=factoryIndexerLocator.getXMLIndexerFactoryPortTypePort(factoryEPR);<br />
<br />
CreateMetadataIndexerMessage request=new metadataIndexerMessage();<br />
request.setRecreate(true);<br />
request.setId(collectionID);<br />
CreateMetadataIndexerResponse response=factoryPortType.createMetadataIndexer(request);<br />
MetadataXMLIndexerPortType indexerServicePortTypePort=serviceIndexerLocator.getMetadataXMLIndexerPortTypePort(response.getEndpointReference());<br />
indexerServicePortTypePort.addElement(elements);<br />
<br />
}catch(Exception e){...}<br />
<br />
....</div>Andreahttps://wiki.gcube-system.org/index.php?title=XML_Indexer&diff=3347XML Indexer2007-12-11T13:50:55Z<p>Andrea: /* Dependencies */</p>
<hr />
<div>=== Introduction ===<br />
The XMLIndexer Service is a generic indexer of XML data homogeneous collections. The service allows creating, populating and resolving queries against such collections. <br />
We distinguish between two types of XMLIndexer, each of them manages a collection of XML documents: <br /><br />
*GenericXMLIndexer – a GenericXMLIndexer is completely unaware about the collection and the data handled. This means that it does not impose any constraint about them and, therefore, it assumes that the clients know the schema of the documents to query. It can be used each time it is useful to index and query a (temporary) set of XML data, like a result set.<br />
*MetadataXMLIndexer – a MetadataXMLIndexer is bound to a specific Metadata Collection and it is used to index the elements of such a collection. When a new indexable Metadata Collection is created, the Metadata Catalog Service creates also a new related MetadataXMLIndexer and, each time a new Metadata Object is added/updated in such collection, the Metadata Catalog Service also adds/updates the MetadataXMLIndexer by feeding it with the new element.<br />
<br />
<br />
The XMLIndexer follows the Factory pattern and it is composed by:<br />
*the XMLIndexerFactory creates new XMLIndexers<br />
*the GenericXMLIndexer service<br />
*the MetadataXMLIndexer service<br />
<br />
=== Managed Resources ===<br />
<br />
The XMLIndexerFactory creates a WS-Resource per each XMLIndexer. Since there are two kinds of XMLIndexer, there are also two kinds of WS-Resource that the Factory service can create: the GenericXMLIndexer resource and the MetadataXMLIndexer resource.<br />
The state of each Indexer is published in the DIS by means of its WS-ResourceProperties. These resource properties includes the creation parameters and, if the Indexer is a GenericXMLIndexer, the SetTerminationTime and CurrentTime WS-ResourceProperties.<br />
<br />
=== MetadataXMLIndexer ===<br />
<br />
A MetadataXMLIndexer operates over a collection of homogeneous XML documents bound to a specific Metadata Collection. Since the managed XMLDocuments are wrapped in the Metadata envelope, each document is identified by a unique ID (the Metadata Object ID) and this allows a more advanced management of this type of Indexer with respect to the GenericXMLIndexer one. In fact, this type of Indexers can be populated, updated, recreated and queried. <br />
The XMLIndexer extends the standard WSRF ImmediateResourceTermination portType implemented by the DestroyProvider operation provider and this means that it has to be explicitly destroyed.<br />
<br />
* '''<tt>AddElements(Documents[]) --> void</tt>'''<br>This operation take a list of Documents and adds them to the current collection in exist1.1 DB. A Document is a pair of id and a String representation of the XMLDocument. This operation can be used to update elements already stored given the same id of an existing document.<br><br />
* '''<tt>AddElementsRS(String) --> void</tt>'''<br>This operation take a string representing a reference to a RSLocator <tt>(see ResultSetService)</tt>. The AddElementRS create a RSReader and stores the element readed in exist1.1 DB.<br> <br />
* '''<tt>ExecuteXPath(string) --> string[]</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection.<br><br />
* '''<tt>ExecuteXPath(string) --> string</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br />
* '''<tt>ExecuteXQuery(string) --> string[]</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return an array of string.<br><br />
* '''<tt>ExecuteXPathRS(string) --> string</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br><br />
<br />
=== Implementation Detail ===<br />
<br />
The XMLIndexer Service is built as a wrapper around an XML database (eXist 1.1). At the first start up time, the service creates an embedded database instance. <br />
Each XMLIndexer manages a collection of data in the database instance. These collections are always created together with the Indexer in the case of a GenericXMLIndexer creation. On the other hand, whenever the CreateMetadataIndexer() operation is invoked on the XMLIndexerFactory, it checks if an XML collection for that Metadata Collection is already available in the database instance. If not, a new XML collection for that Metadata Collection is created, otherwise the already available collection is used.<br />
<br />
=== Dependencies ===<br />
<br />
These are the dependencies of the Service :<br />
* '''eXist1.1'''<br />
* '''ResultSetService'''<br />
<br />
=== Usage Examples ===</div>Andreahttps://wiki.gcube-system.org/index.php?title=XML_Indexer&diff=3346XML Indexer2007-12-11T13:48:37Z<p>Andrea: /* Dependencies */</p>
<hr />
<div>=== Introduction ===<br />
The XMLIndexer Service is a generic indexer of XML data homogeneous collections. The service allows creating, populating and resolving queries against such collections. <br />
We distinguish between two types of XMLIndexer, each of them manages a collection of XML documents: <br /><br />
*GenericXMLIndexer – a GenericXMLIndexer is completely unaware about the collection and the data handled. This means that it does not impose any constraint about them and, therefore, it assumes that the clients know the schema of the documents to query. It can be used each time it is useful to index and query a (temporary) set of XML data, like a result set.<br />
*MetadataXMLIndexer – a MetadataXMLIndexer is bound to a specific Metadata Collection and it is used to index the elements of such a collection. When a new indexable Metadata Collection is created, the Metadata Catalog Service creates also a new related MetadataXMLIndexer and, each time a new Metadata Object is added/updated in such collection, the Metadata Catalog Service also adds/updates the MetadataXMLIndexer by feeding it with the new element.<br />
<br />
<br />
The XMLIndexer follows the Factory pattern and it is composed by:<br />
*the XMLIndexerFactory creates new XMLIndexers<br />
*the GenericXMLIndexer service<br />
*the MetadataXMLIndexer service<br />
<br />
=== Managed Resources ===<br />
<br />
The XMLIndexerFactory creates a WS-Resource per each XMLIndexer. Since there are two kinds of XMLIndexer, there are also two kinds of WS-Resource that the Factory service can create: the GenericXMLIndexer resource and the MetadataXMLIndexer resource.<br />
The state of each Indexer is published in the DIS by means of its WS-ResourceProperties. These resource properties includes the creation parameters and, if the Indexer is a GenericXMLIndexer, the SetTerminationTime and CurrentTime WS-ResourceProperties.<br />
<br />
=== MetadataXMLIndexer ===<br />
<br />
A MetadataXMLIndexer operates over a collection of homogeneous XML documents bound to a specific Metadata Collection. Since the managed XMLDocuments are wrapped in the Metadata envelope, each document is identified by a unique ID (the Metadata Object ID) and this allows a more advanced management of this type of Indexer with respect to the GenericXMLIndexer one. In fact, this type of Indexers can be populated, updated, recreated and queried. <br />
The XMLIndexer extends the standard WSRF ImmediateResourceTermination portType implemented by the DestroyProvider operation provider and this means that it has to be explicitly destroyed.<br />
<br />
* '''<tt>AddElements(Documents[]) --> void</tt>'''<br>This operation take a list of Documents and adds them to the current collection in exist1.1 DB. A Document is a pair of id and a String representation of the XMLDocument. This operation can be used to update elements already stored given the same id of an existing document.<br><br />
* '''<tt>AddElementsRS(String) --> void</tt>'''<br>This operation take a string representing a reference to a RSLocator <tt>(see ResultSetService)</tt>. The AddElementRS create a RSReader and stores the element readed in exist1.1 DB.<br> <br />
* '''<tt>ExecuteXPath(string) --> string[]</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection.<br><br />
* '''<tt>ExecuteXPath(string) --> string</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br />
* '''<tt>ExecuteXQuery(string) --> string[]</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return an array of string.<br><br />
* '''<tt>ExecuteXPathRS(string) --> string</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br><br />
<br />
=== Implementation Detail ===<br />
<br />
The XMLIndexer Service is built as a wrapper around an XML database (eXist 1.1). At the first start up time, the service creates an embedded database instance. <br />
Each XMLIndexer manages a collection of data in the database instance. These collections are always created together with the Indexer in the case of a GenericXMLIndexer creation. On the other hand, whenever the CreateMetadataIndexer() operation is invoked on the XMLIndexerFactory, it checks if an XML collection for that Metadata Collection is already available in the database instance. If not, a new XML collection for that Metadata Collection is created, otherwise the already available collection is used.<br />
<br />
=== Dependencies ===<br />
<br />
eXist1.1<br/><br />
ResultSetService<br />
<br />
=== Usage Examples ===</div>Andreahttps://wiki.gcube-system.org/index.php?title=XML_Indexer&diff=3345XML Indexer2007-12-11T13:48:11Z<p>Andrea: /* Dependencies */</p>
<hr />
<div>=== Introduction ===<br />
The XMLIndexer Service is a generic indexer of XML data homogeneous collections. The service allows creating, populating and resolving queries against such collections. <br />
We distinguish between two types of XMLIndexer, each of them manages a collection of XML documents: <br /><br />
*GenericXMLIndexer – a GenericXMLIndexer is completely unaware about the collection and the data handled. This means that it does not impose any constraint about them and, therefore, it assumes that the clients know the schema of the documents to query. It can be used each time it is useful to index and query a (temporary) set of XML data, like a result set.<br />
*MetadataXMLIndexer – a MetadataXMLIndexer is bound to a specific Metadata Collection and it is used to index the elements of such a collection. When a new indexable Metadata Collection is created, the Metadata Catalog Service creates also a new related MetadataXMLIndexer and, each time a new Metadata Object is added/updated in such collection, the Metadata Catalog Service also adds/updates the MetadataXMLIndexer by feeding it with the new element.<br />
<br />
<br />
The XMLIndexer follows the Factory pattern and it is composed by:<br />
*the XMLIndexerFactory creates new XMLIndexers<br />
*the GenericXMLIndexer service<br />
*the MetadataXMLIndexer service<br />
<br />
=== Managed Resources ===<br />
<br />
The XMLIndexerFactory creates a WS-Resource per each XMLIndexer. Since there are two kinds of XMLIndexer, there are also two kinds of WS-Resource that the Factory service can create: the GenericXMLIndexer resource and the MetadataXMLIndexer resource.<br />
The state of each Indexer is published in the DIS by means of its WS-ResourceProperties. These resource properties includes the creation parameters and, if the Indexer is a GenericXMLIndexer, the SetTerminationTime and CurrentTime WS-ResourceProperties.<br />
<br />
=== MetadataXMLIndexer ===<br />
<br />
A MetadataXMLIndexer operates over a collection of homogeneous XML documents bound to a specific Metadata Collection. Since the managed XMLDocuments are wrapped in the Metadata envelope, each document is identified by a unique ID (the Metadata Object ID) and this allows a more advanced management of this type of Indexer with respect to the GenericXMLIndexer one. In fact, this type of Indexers can be populated, updated, recreated and queried. <br />
The XMLIndexer extends the standard WSRF ImmediateResourceTermination portType implemented by the DestroyProvider operation provider and this means that it has to be explicitly destroyed.<br />
<br />
* '''<tt>AddElements(Documents[]) --> void</tt>'''<br>This operation take a list of Documents and adds them to the current collection in exist1.1 DB. A Document is a pair of id and a String representation of the XMLDocument. This operation can be used to update elements already stored given the same id of an existing document.<br><br />
* '''<tt>AddElementsRS(String) --> void</tt>'''<br>This operation take a string representing a reference to a RSLocator <tt>(see ResultSetService)</tt>. The AddElementRS create a RSReader and stores the element readed in exist1.1 DB.<br> <br />
* '''<tt>ExecuteXPath(string) --> string[]</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection.<br><br />
* '''<tt>ExecuteXPath(string) --> string</tt>'''<br>This operation take a string representing the XPath. It executes the given XPath on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br />
* '''<tt>ExecuteXQuery(string) --> string[]</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return an array of string.<br><br />
* '''<tt>ExecuteXPathRS(string) --> string</tt>'''<br>This operation take a string representing the XQuery. It executes the given XQuery on the current collection and return a string representing a reference to RSLocator <tt>(see ResultSetService)</tt>.<br><br />
<br />
=== Implementation Detail ===<br />
<br />
The XMLIndexer Service is built as a wrapper around an XML database (eXist 1.1). At the first start up time, the service creates an embedded database instance. <br />
Each XMLIndexer manages a collection of data in the database instance. These collections are always created together with the Indexer in the case of a GenericXMLIndexer creation. On the other hand, whenever the CreateMetadataIndexer() operation is invoked on the XMLIndexerFactory, it checks if an XML collection for that Metadata Collection is already available in the database instance. If not, a new XML collection for that Metadata Collection is created, otherwise the already available collection is used.<br />
<br />
=== Dependencies ===<br />
<br />
eXist1.1<br />
ResultSetService<br />
<br />
=== Usage Examples ===</div>Andreahttps://wiki.gcube-system.org/index.php?title=Administrator%27s_Guide:_How_to_set_up_a_gCube_infrastructure&diff=3300Administrator's Guide: How to set up a gCube infrastructure2007-12-05T13:39:03Z<p>Andrea: /* Minimal configuration */</p>
<hr />
<div>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.<br><br />
== Non-secure configuration ==<br />
==== Minimal configuration ====<br />
Perform the following steps to create and configure a non-secure infrastructure:<br />
#decide a name for the new infrastructure<br />
#decide the VOs hierarchy configuration: at least one root VO and a subVO are required to be there<br />
#identify a set of machines to turn on as DHNs (their number may vary depending on the infrastructure needs)<br />
#[[DHN_Installation#VOMap_files|prepare a VO Map]] file for each VO<br />
#setup the root VO<br />
##identify two machines to dedicate to the VO management<br />
##[[DHN_Installation|install the DHN 1.0 bundle]] in the two machines and copy the VO Map files under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder<br />
##[[DHN_Installation#HNMService|configure]] one DHN (named ''DIS root DHN'') as root, join it to the root VO as default VO and [[Core_Services_Installation#DILIGENT_Information_Service_.28DIS.29|install the DIS core services]] (DIS-IC, DIS-Registry, DIS-Broker) there dedicated to the management of the root VO<br />
##[[DHN_Installation#Post-installation_configuration|configure]] one DHN (named ''DLMan root DHN'') to join it to the root VO as default VO and<br />
##*[[Core_Services_Installation#Package_Repository|install and populate a Package Repository]] there <br />
##*[[Core_Services_Installation#DL_Management|install and configure a DL Management Service]] there<br />
##start the container on the ''DIS root DHN'' and then on the ''DLMan root DHN'' and verify that they work properly<br />
#setup the subVO<br />
##identify two machines to dedicate to the subVO management<br />
##[[DHN_Installation|install the DHN 1.0 bundle]] in the two machines and copy the VO Map files under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder<br />
##[[DHN_Installation#HNMService|configure]] one DHN as root, join it to the subVO as default VO and [[Core_Services_Installation#DILIGENT_Information_Service_.28DIS.29|install the DIS core services]] (DIS-IC, DIS-Registry, DIS-Broker) there dedicated to the subVO (named ''DIS subVO DHN'')<br />
##[[DHN_Installation#HNMService|configure]] one DHN (named ''DLMan subVO DHN'') to join it to the subVO as default VO and [[Core_Services_Installation#DL_Management|install and configure a DL Management Service]] there <br />
##start the container on the ''DIS subVO DHN'' and then on the ''DLMan subVO DHN'' and verify that they work properly<br />
#configure and start generic DHNs<br />
##[[DHN_Installation|install the DHN 1.0 bundle]] in each machine and copy the VO Map files under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder<br />
##[[DHN_Installation#Post-installation_configuration|configure]] the DHNs to join the subVO as default VO:<br />
##start the container on each machine and verify that the DHN is correctly published both in the root VO and in the subVO DIS<br />
#setup the portal by following the [[DILIGENT Gridsphere and Portal Security patch]] instructions.<br />
#configure one or more VREs by exploiting the [[Administration]] user interface capability reported in the User's Guide manual.<br />
<br />
==== Other possible configurations ====<br />
Alternative configurations can improve the infrastructure performances. In particular:<br />
* the DIS-Broker can be hosted on a different(and standard, i.e. non-root) DHN with respect to the other two DIS core services<br />
* the Package Repository can be hosted on a different (and standard, i.e. non-root) DHN with respect to the DL Management service<br />
* multiple subVOs can be defined <br />
* more than one DIS can be setup for each VO in order to distribute the load over them<br />
<br />
The 'optimal' configuration mainly depends on the number of available DHNs. More DHNs joining the infrastructure means a better distribution of resources and services across them.<br />
<br />
== Secure configuration ==<br />
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. <br><br />
The steps described for the [[Administrator's_Guide:How_to_set_up_a_gCube_infrastructure#Non-secure_configuration|non-secure configurations]] have to be integrated by the additional actions reported below.<br />
<br><br />
<br />
*Steps 5.2, 6.2 e 7.1 requires the following:<br />
:a) [[How_To_Configure_DHN_Security|configure the Java WS Core container]] running on each DHN to run with host credentials<br />
:b) [[DHN_Installation#JNDI_file|configure the HNM Service]] hosted on each DHN to run with the security enabled<br />
<br />
*The setup of the root VO includes this preliminary actions:<br />
:a) [[Core_Services_Installation#Pre-installation_setup_6|install]] a MyProxy repository and a MyProxy OnlineCA<br />
:b) [[Core_Services_Installation#Pre-installation_setup_6|install]] a VOMS service<br />
:c) [[DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet|install]] a VOMSServlet on a Tomcat hosting environment<br />
:d) identify a further DHN to dedicate to the VO management and [[DHN_Installation#Post-installation_configuration|configure]] it (named ''CR root DHN'') as root, join it to the root VO as default VO <br />
:e) [[Core_Services_Installation#Credentials_Renewal_Installation|install an instance of the Credentials Renewal service]] on the ''CR root DHN''<br />
:f) [[How_To_Configure_Service_Security|configure each service]] to use the security<br />
: 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<br />
<br />
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.<br><br />
'''Service credentials'''<br />
:a) [[How_To_Configure_Identities_For_DILIGENT_Services#Delegate_credentials_to_MyProxy|delegate proxy credentials]] on the MyProxy for the service stored on the Package Repository<br />
:b) [[How_To_Configure_Identities_For_DILIGENT_Services#Create_a_new_Credentials_Renewal_account|create an Account]] on the Credential Renewal instance for each proxy credentials stored<br />
:c) create a Renewal Task (using the appropriate Account Resource) on the Credentials Renewal instance for each Running Instance of a gCube service<br />
:*this operation is performed automatically by the CL services in case of dynamically deployed instances<br />
:*this operation has to be done [[How_To_Configure_Identities_For_DILIGENT_Services#Set-up_a_credentials_renewal_task|manually]] in case of statically deployed instances<br />
:d) each running instance [[How_To_Configure_Service_Security#Provide_your_service_with_credentials|retrieves its own credentials]] from the local Delegation Service for the current VRE (extracted from the caller credentials) <br />
<br />
'''Caller credentials'''<br />
:a) each running instance retrieves the credentials from the context (delegated from the caller credentials)<br />
:b) each running instance is invoked by using the Full Delegation modality<br />
<br />
<br><br />
<br><br />
[[User:Manuelesimi|Manuelesimi]] 13:45, 5 December 2007 (EET)</div>Andreahttps://wiki.gcube-system.org/index.php?title=DHN_Installation&diff=2499DHN Installation2007-10-17T14:43:59Z<p>Andrea: /* JNDI file */</p>
<hr />
<div>== Host preparation ==<br />
<br />
=== Minimal host requirements ===<br />
<br />
* Operating System<br />
** any Unix-based tested platform for Java WS Core<br />
*** tested platform: SL3.0, Red Hat FC6, Ubuntu<br />
<br />
* Connectivity<br />
** a machine configured with a static IP address<br />
<br />
* Software<br />
** [http://java.sun.com/j2se/1.5.0/ java 1.5]<br />
** [http://ant.apache.org/ Apache ANT 1.6.0] or higher<br />
** [http://www.globus.org/toolkit/downloads/4.0.4/ Java Ws Core 4.0.4]<br />
<br />
=== Migrating from the previous releases ===<br />
<br />
The last version of the DHN bundle (1.0 FRCv3) can be installed as a full installation as well as an upgrade from a previous DHN distribution.<br />
<br />
== Package Installation ==<br />
<br />
=== Download === <br />
<br />
The DHN 1.0 Final Release Candidate v3 can be downloaded from [https://elibrary.isti.cnr.it/svn_public/diligent_GAR/DHNInstaller/1.0RC/ here].<br />
<br />
=== Installation Procedure ===<br />
<br />
After having prepared the node as described in [[DHN_Installation:Host_preparation| Host preparation]], the following steps have to be performed in order to install the DHN:<br />
* uncompress the ''DHN_installer_1.0RC.tar.gz'' file<br />
* stop the Java WS Core container (if any)<br />
* source your ${GLOBUS_LOCATION}/etc/globus-devel-env.sh file<br />
* if you are installing the DHN from scratch<br />
** type ''make install'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous FRC installation:<br />
** type ''make upgradeFromFRC'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous Beta installation:<br />
** type ''make upgradeFromBeta'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* follow the [[DHN_Installation:Post-installation_configuration| Post-installation configuration steps]]<br />
* (re)start the container<br />
<br />
=== Included software ===<br />
<br />
The Final Release Candidate version of the DHN Installer includes the following Collective Layer components:<br />
* NAL 1.0 Final RC<br />
* DIS-HLSClient 1.0 Final RC<br />
* DIS-IP 1.0 Final RC<br />
* HNM Service 1.0 Final RC<br />
* HNM Service stubs 1.0 Final RC<br />
* DIS-IC stubs 1.0 Final RC<br />
* DIS-Registry stubs 1.0 Final RC<br />
* DIS-Broker stubs 1.0 Final RC<br />
* DLManagement stubs 1.0 Final RC<br />
* KeeperCommon Library 1.0 Final RC<br />
* DIS-Util Library 1.0 Final RC<br />
* ProfileManagement Library 1.0 Final RC<br />
* DILIGENTProvider 1.0 Final RC<br />
* DILIGENT Provider Stubs 1.0 Final RC<br />
* Authentication API 1.0 Final RC<br />
* Delegation Service 1.0 Final RC<br />
* Delegation Stubs 1.0 Final RC<br />
* DVOS Common Library 1.0 Final RC<br />
* Gas Stubs 1.0 Final RC<br />
* a customised distribution of the Aggregator Framework for Java WS Core 4.0.4<br />
All the components above are also available in ETICS in their *_0_3_0 configurations.<br />
<br />
== Post-installation configuration ==<br />
<br />
=== Configuration files ===<br />
<br />
Configuration files that have to be edited after the installation:<br />
<br />
==== Java WS Core ====<br />
<br />
===== container-log4j.properties =====<br />
<br />
The Log4J output should be redirected on the file system in order to simplify the debugging of what is happening on the DHN and the exchange of such information. The following configuration in the ''$GLOBUS_LOCATION/container-log4j.properties'' file has to replace the default one for the log4j.appender.A1:<br />
<pre><br />
# A1 is set to be a RollingFileAppender<br />
log4j.appender.A1=org.apache.log4j.RollingFileAppender<br />
log4j.appender.A1.file=container.log<br />
log4j.appender.A1.MaxFileSize=10000KB<br />
# Keep 100 backup files<br />
log4j.appender.A1.MaxBackupIndex=100<br />
<br />
<br />
# A1 uses PatternLayout.<br />
log4j.appender.A1.layout=org.apache.log4j.PatternLayout<br />
log4j.appender.A1.layout.ConversionPattern=%d{ISO8601} %-5p %c{2} [%t,%M:%L] %m%n<br />
<br />
# Display any warnings generated by our code<br />
log4j.category.org.globus=INFO<br />
</pre><br />
<br />
This configuration enables the file rolling behavior and a rollover schedule when the file log size reaches 10MB by managing in this way 100 log files.<br />
<br />
Moreover, we initially suggest also to enable a DEBUG log level for the HNMService and the Profile Management Library. In order to do that, add the following lines to the same file:<br />
<pre><br />
log4j.category.org.diligentproject.keeperservice.hnm.impl=DEBUG<br />
log4j.category.org.diligentproject.common.profile.impl=DEBUG<br />
</pre><br />
<br />
===== server-config.wsdd =====<br />
This file includes a set of global properties related to the container. It is located in the ''$GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd''.<br />
It must be changed in order to allow the DHN to publish its hostname. The following two lines have to be added in the <globalConfiguration> section: <br />
<br />
<pre><br />
<parameter name="logicalHost" value="yourHostName.yourDomain"/><br />
<parameter name="publishHostName" value="true"/><br />
</pre><br />
<br />
Of course, the ''yourHostName.yourDomain'' string must be replaced with your real hostname.<br />
<br />
==== HNMService ====<br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS : the PPS infrastructure ( in case the DHN has to join Arte or Impect VOs)<br />
** development : the development infra ( in case the DHN has to join the devsec VO)<br />
<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO (working in the pre-production infrastructure)<br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a freetext placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
=== Scripts ===<br />
<br />
Scripts that have to be run that take care of post installation activities: NA<br />
<br />
== Testing and Verification ==<br />
<br />
After the installation the DHN automatically joins the Beta infrastructure of DILIGENT. This is a completely new infrastructure that officially becomes the target infrastructure for the Beta releases of all the DILIGENT components. All the profiles produced by the DHN software are published on this new infrastructure glued together by the Beta release of the Collective Layer components. <br />
<br />
To understand if a DHN has been successfully installed it is important to check if the DHN profile and the HNMService Running Instance profiles are correctly published in the DIS of such a infrastructure. A new [http://dlib25.isti.cnr.it/ DILIGENT Administrative Portal] is available to manage this new infrastructure. In order to access to the monitoring capabilities of the Portal, you can use the following:<br />
* user ''monitoring''<br />
* pass ''monitoring''<br />
<br />
== Installation Troubleshooting ==<br />
NA</div>Andreahttps://wiki.gcube-system.org/index.php?title=DHN_Installation&diff=2498DHN Installation2007-10-17T14:29:39Z<p>Andrea: /* JNDI file */</p>
<hr />
<div>== Host preparation ==<br />
<br />
=== Minimal host requirements ===<br />
<br />
* Operating System<br />
** any Unix-based tested platform for Java WS Core<br />
*** tested platform: SL3.0, Red Hat FC6, Ubuntu<br />
<br />
* Connectivity<br />
** a machine configured with a static IP address<br />
<br />
* Software<br />
** [http://java.sun.com/j2se/1.5.0/ java 1.5]<br />
** [http://ant.apache.org/ Apache ANT 1.6.0] or higher<br />
** [http://www.globus.org/toolkit/downloads/4.0.4/ Java Ws Core 4.0.4]<br />
<br />
=== Migrating from the previous releases ===<br />
<br />
The last version of the DHN bundle (1.0 FRCv3) can be installed as a full installation as well as an upgrade from a previous DHN distribution.<br />
<br />
== Package Installation ==<br />
<br />
=== Download === <br />
<br />
The DHN 1.0 Final Release Candidate v3 can be downloaded from [https://elibrary.isti.cnr.it/svn_public/diligent_GAR/DHNInstaller/1.0RC/ here].<br />
<br />
=== Installation Procedure ===<br />
<br />
After having prepared the node as described in [[DHN_Installation:Host_preparation| Host preparation]], the following steps have to be performed in order to install the DHN:<br />
* uncompress the ''DHN_installer_1.0RC.tar.gz'' file<br />
* stop the Java WS Core container (if any)<br />
* source your ${GLOBUS_LOCATION}/etc/globus-devel-env.sh file<br />
* if you are installing the DHN from scratch<br />
** type ''make install'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous FRC installation:<br />
** type ''make upgradeFromFRC'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous Beta installation:<br />
** type ''make upgradeFromBeta'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* follow the [[DHN_Installation:Post-installation_configuration| Post-installation configuration steps]]<br />
* (re)start the container<br />
<br />
=== Included software ===<br />
<br />
The Final Release Candidate version of the DHN Installer includes the following Collective Layer components:<br />
* NAL 1.0 Final RC<br />
* DIS-HLSClient 1.0 Final RC<br />
* DIS-IP 1.0 Final RC<br />
* HNM Service 1.0 Final RC<br />
* HNM Service stubs 1.0 Final RC<br />
* DIS-IC stubs 1.0 Final RC<br />
* DIS-Registry stubs 1.0 Final RC<br />
* DIS-Broker stubs 1.0 Final RC<br />
* DLManagement stubs 1.0 Final RC<br />
* KeeperCommon Library 1.0 Final RC<br />
* DIS-Util Library 1.0 Final RC<br />
* ProfileManagement Library 1.0 Final RC<br />
* DILIGENTProvider 1.0 Final RC<br />
* DILIGENT Provider Stubs 1.0 Final RC<br />
* Authentication API 1.0 Final RC<br />
* Delegation Service 1.0 Final RC<br />
* Delegation Stubs 1.0 Final RC<br />
* DVOS Common Library 1.0 Final RC<br />
* Gas Stubs 1.0 Final RC<br />
* a customised distribution of the Aggregator Framework for Java WS Core 4.0.4<br />
All the components above are also available in ETICS in their *_0_3_0 configurations.<br />
<br />
== Post-installation configuration ==<br />
<br />
=== Configuration files ===<br />
<br />
Configuration files that have to be edited after the installation:<br />
<br />
==== Java WS Core ====<br />
<br />
===== container-log4j.properties =====<br />
<br />
The Log4J output should be redirected on the file system in order to simplify the debugging of what is happening on the DHN and the exchange of such information. The following configuration in the ''$GLOBUS_LOCATION/container-log4j.properties'' file has to replace the default one for the log4j.appender.A1:<br />
<pre><br />
# A1 is set to be a RollingFileAppender<br />
log4j.appender.A1=org.apache.log4j.RollingFileAppender<br />
log4j.appender.A1.file=container.log<br />
log4j.appender.A1.MaxFileSize=10000KB<br />
# Keep 100 backup files<br />
log4j.appender.A1.MaxBackupIndex=100<br />
<br />
<br />
# A1 uses PatternLayout.<br />
log4j.appender.A1.layout=org.apache.log4j.PatternLayout<br />
log4j.appender.A1.layout.ConversionPattern=%d{ISO8601} %-5p %c{2} [%t,%M:%L] %m%n<br />
<br />
# Display any warnings generated by our code<br />
log4j.category.org.globus=INFO<br />
</pre><br />
<br />
This configuration enables the file rolling behavior and a rollover schedule when the file log size reaches 10MB by managing in this way 100 log files.<br />
<br />
Moreover, we initially suggest also to enable a DEBUG log level for the HNMService and the Profile Management Library. In order to do that, add the following lines to the same file:<br />
<pre><br />
log4j.category.org.diligentproject.keeperservice.hnm.impl=DEBUG<br />
log4j.category.org.diligentproject.common.profile.impl=DEBUG<br />
</pre><br />
<br />
===== server-config.wsdd =====<br />
This file includes a set of global properties related to the container. It is located in the ''$GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd''.<br />
It must be changed in order to allow the DHN to publish its hostname. The following two lines have to be added in the <globalConfiguration> section: <br />
<br />
<pre><br />
<parameter name="logicalHost" value="yourHostName.yourDomain"/><br />
<parameter name="publishHostName" value="true"/><br />
</pre><br />
<br />
Of course, the ''yourHostName.yourDomain'' string must be replaced with your real hostname.<br />
<br />
==== HNMService ====<br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
*''infrastructure'' This parameter specify the type of infrastructure to join:<br />
** PPS : the PPS infrastructure ( in case the DHN has to join Arte or Impect VOs)<br />
** development : the development infra ( in cade the DHN has to join the devsec VO)<br />
<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO (working in the pre-production infrastructure)<br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent/devsec.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a freetext placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
=== Scripts ===<br />
<br />
Scripts that have to be run that take care of post installation activities: NA<br />
<br />
== Testing and Verification ==<br />
<br />
After the installation the DHN automatically joins the Beta infrastructure of DILIGENT. This is a completely new infrastructure that officially becomes the target infrastructure for the Beta releases of all the DILIGENT components. All the profiles produced by the DHN software are published on this new infrastructure glued together by the Beta release of the Collective Layer components. <br />
<br />
To understand if a DHN has been successfully installed it is important to check if the DHN profile and the HNMService Running Instance profiles are correctly published in the DIS of such a infrastructure. A new [http://dlib25.isti.cnr.it/ DILIGENT Administrative Portal] is available to manage this new infrastructure. In order to access to the monitoring capabilities of the Portal, you can use the following:<br />
* user ''monitoring''<br />
* pass ''monitoring''<br />
<br />
== Installation Troubleshooting ==<br />
NA</div>Andreahttps://wiki.gcube-system.org/index.php?title=DHN_Installation&diff=2497DHN Installation2007-10-17T14:06:11Z<p>Andrea: /* Installation Procedure */</p>
<hr />
<div>== Host preparation ==<br />
<br />
=== Minimal host requirements ===<br />
<br />
* Operating System<br />
** any Unix-based tested platform for Java WS Core<br />
*** tested platform: SL3.0, Red Hat FC6, Ubuntu<br />
<br />
* Connectivity<br />
** a machine configured with a static IP address<br />
<br />
* Software<br />
** [http://java.sun.com/j2se/1.5.0/ java 1.5]<br />
** [http://ant.apache.org/ Apache ANT 1.6.0] or higher<br />
** [http://www.globus.org/toolkit/downloads/4.0.4/ Java Ws Core 4.0.4]<br />
<br />
=== Migrating from the previous releases ===<br />
<br />
The last version of the DHN bundle (1.0 FRCv3) can be installed as a full installation as well as an upgrade from a previous DHN distribution.<br />
<br />
== Package Installation ==<br />
<br />
=== Download === <br />
<br />
The DHN 1.0 Final Release Candidate v3 can be downloaded from [https://elibrary.isti.cnr.it/svn_public/diligent_GAR/DHNInstaller/1.0RC/ here].<br />
<br />
=== Installation Procedure ===<br />
<br />
After having prepared the node as described in [[DHN_Installation:Host_preparation| Host preparation]], the following steps have to be performed in order to install the DHN:<br />
* uncompress the ''DHN_installer_1.0RC.tar.gz'' file<br />
* stop the Java WS Core container (if any)<br />
* source your ${GLOBUS_LOCATION}/etc/globus-devel-env.sh file<br />
* if you are installing the DHN from scratch<br />
** type ''make install'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous FRC installation:<br />
** type ''make upgradeFromFRC'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous Beta installation:<br />
** type ''make upgradeFromBeta'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* follow the [[DHN_Installation:Post-installation_configuration| Post-installation configuration steps]]<br />
* (re)start the container<br />
<br />
=== Included software ===<br />
<br />
The Final Release Candidate version of the DHN Installer includes the following Collective Layer components:<br />
* NAL 1.0 Final RC<br />
* DIS-HLSClient 1.0 Final RC<br />
* DIS-IP 1.0 Final RC<br />
* HNM Service 1.0 Final RC<br />
* HNM Service stubs 1.0 Final RC<br />
* DIS-IC stubs 1.0 Final RC<br />
* DIS-Registry stubs 1.0 Final RC<br />
* DIS-Broker stubs 1.0 Final RC<br />
* DLManagement stubs 1.0 Final RC<br />
* KeeperCommon Library 1.0 Final RC<br />
* DIS-Util Library 1.0 Final RC<br />
* ProfileManagement Library 1.0 Final RC<br />
* DILIGENTProvider 1.0 Final RC<br />
* DILIGENT Provider Stubs 1.0 Final RC<br />
* Authentication API 1.0 Final RC<br />
* Delegation Service 1.0 Final RC<br />
* Delegation Stubs 1.0 Final RC<br />
* DVOS Common Library 1.0 Final RC<br />
* Gas Stubs 1.0 Final RC<br />
* a customised distribution of the Aggregator Framework for Java WS Core 4.0.4<br />
All the components above are also available in ETICS in their *_0_3_0 configurations.<br />
<br />
== Post-installation configuration ==<br />
<br />
=== Configuration files ===<br />
<br />
Configuration files that have to be edited after the installation:<br />
<br />
==== Java WS Core ====<br />
<br />
===== container-log4j.properties =====<br />
<br />
The Log4J output should be redirected on the file system in order to simplify the debugging of what is happening on the DHN and the exchange of such information. The following configuration in the ''$GLOBUS_LOCATION/container-log4j.properties'' file has to replace the default one for the log4j.appender.A1:<br />
<pre><br />
# A1 is set to be a RollingFileAppender<br />
log4j.appender.A1=org.apache.log4j.RollingFileAppender<br />
log4j.appender.A1.file=container.log<br />
log4j.appender.A1.MaxFileSize=10000KB<br />
# Keep 100 backup files<br />
log4j.appender.A1.MaxBackupIndex=100<br />
<br />
<br />
# A1 uses PatternLayout.<br />
log4j.appender.A1.layout=org.apache.log4j.PatternLayout<br />
log4j.appender.A1.layout.ConversionPattern=%d{ISO8601} %-5p %c{2} [%t,%M:%L] %m%n<br />
<br />
# Display any warnings generated by our code<br />
log4j.category.org.globus=INFO<br />
</pre><br />
<br />
This configuration enables the file rolling behavior and a rollover schedule when the file log size reaches 10MB by managing in this way 100 log files.<br />
<br />
Moreover, we initially suggest also to enable a DEBUG log level for the HNMService and the Profile Management Library. In order to do that, add the following lines to the same file:<br />
<pre><br />
log4j.category.org.diligentproject.keeperservice.hnm.impl=DEBUG<br />
log4j.category.org.diligentproject.common.profile.impl=DEBUG<br />
</pre><br />
<br />
===== server-config.wsdd =====<br />
This file includes a set of global properties related to the container. It is located in the ''$GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd''.<br />
It must be changed in order to allow the DHN to publish its hostname. The following two lines have to be added in the <globalConfiguration> section: <br />
<br />
<pre><br />
<parameter name="logicalHost" value="yourHostName.yourDomain"/><br />
<parameter name="publishHostName" value="true"/><br />
</pre><br />
<br />
Of course, the ''yourHostName.yourDomain'' string must be replaced with your real hostname.<br />
<br />
==== HNMService ====<br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO (working in the pre-production infrastructure)<br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/dev &rarr; to join the Development VO (working in the development infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent/devsec.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a freetext placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
=== Scripts ===<br />
<br />
Scripts that have to be run that take care of post installation activities: NA<br />
<br />
== Testing and Verification ==<br />
<br />
After the installation the DHN automatically joins the Beta infrastructure of DILIGENT. This is a completely new infrastructure that officially becomes the target infrastructure for the Beta releases of all the DILIGENT components. All the profiles produced by the DHN software are published on this new infrastructure glued together by the Beta release of the Collective Layer components. <br />
<br />
To understand if a DHN has been successfully installed it is important to check if the DHN profile and the HNMService Running Instance profiles are correctly published in the DIS of such a infrastructure. A new [http://dlib25.isti.cnr.it/ DILIGENT Administrative Portal] is available to manage this new infrastructure. In order to access to the monitoring capabilities of the Portal, you can use the following:<br />
* user ''monitoring''<br />
* pass ''monitoring''<br />
<br />
== Installation Troubleshooting ==<br />
NA</div>Andreahttps://wiki.gcube-system.org/index.php?title=DHN_Installation&diff=2496DHN Installation2007-10-17T13:30:45Z<p>Andrea: /* Download */</p>
<hr />
<div>== Host preparation ==<br />
<br />
=== Minimal host requirements ===<br />
<br />
* Operating System<br />
** any Unix-based tested platform for Java WS Core<br />
*** tested platform: SL3.0, Red Hat FC6, Ubuntu<br />
<br />
* Connectivity<br />
** a machine configured with a static IP address<br />
<br />
* Software<br />
** [http://java.sun.com/j2se/1.5.0/ java 1.5]<br />
** [http://ant.apache.org/ Apache ANT 1.6.0] or higher<br />
** [http://www.globus.org/toolkit/downloads/4.0.4/ Java Ws Core 4.0.4]<br />
<br />
=== Migrating from the previous releases ===<br />
<br />
The last version of the DHN bundle (1.0 FRCv3) can be installed as a full installation as well as an upgrade from a previous DHN distribution.<br />
<br />
== Package Installation ==<br />
<br />
=== Download === <br />
<br />
The DHN 1.0 Final Release Candidate v3 can be downloaded from [https://elibrary.isti.cnr.it/svn_public/diligent_GAR/DHNInstaller/1.0RC/ here].<br />
<br />
=== Installation Procedure ===<br />
<br />
After having prepared the node as described in [[DHN_Installation:Host_preparation| Host preparation]], the following steps have to be performed in order to install the DHN:<br />
* uncompress the ''DHN_installer_1.0RC.tar.gz'' file<br />
* stop the Java WS Core container (if any)<br />
* source your ${GLOBUS_LOCATION}/etc/globus-devel-env.sh file<br />
* if you are installing the DHN from scratch<br />
** type ''make install'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous FRC1 installation:<br />
** type ''make upgradeFromFRC1'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous Beta installation:<br />
** type ''make upgradeFromBeta'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* follow the [[DHN_Installation:Post-installation_configuration| Post-installation configuration steps]]<br />
* (re)start the container<br />
<br />
=== Included software ===<br />
<br />
The Final Release Candidate version of the DHN Installer includes the following Collective Layer components:<br />
* NAL 1.0 Final RC<br />
* DIS-HLSClient 1.0 Final RC<br />
* DIS-IP 1.0 Final RC<br />
* HNM Service 1.0 Final RC<br />
* HNM Service stubs 1.0 Final RC<br />
* DIS-IC stubs 1.0 Final RC<br />
* DIS-Registry stubs 1.0 Final RC<br />
* DIS-Broker stubs 1.0 Final RC<br />
* DLManagement stubs 1.0 Final RC<br />
* KeeperCommon Library 1.0 Final RC<br />
* DIS-Util Library 1.0 Final RC<br />
* ProfileManagement Library 1.0 Final RC<br />
* DILIGENTProvider 1.0 Final RC<br />
* DILIGENT Provider Stubs 1.0 Final RC<br />
* Authentication API 1.0 Final RC<br />
* Delegation Service 1.0 Final RC<br />
* Delegation Stubs 1.0 Final RC<br />
* DVOS Common Library 1.0 Final RC<br />
* Gas Stubs 1.0 Final RC<br />
* a customised distribution of the Aggregator Framework for Java WS Core 4.0.4<br />
All the components above are also available in ETICS in their *_0_3_0 configurations.<br />
<br />
== Post-installation configuration ==<br />
<br />
=== Configuration files ===<br />
<br />
Configuration files that have to be edited after the installation:<br />
<br />
==== Java WS Core ====<br />
<br />
===== container-log4j.properties =====<br />
<br />
The Log4J output should be redirected on the file system in order to simplify the debugging of what is happening on the DHN and the exchange of such information. The following configuration in the ''$GLOBUS_LOCATION/container-log4j.properties'' file has to replace the default one for the log4j.appender.A1:<br />
<pre><br />
# A1 is set to be a RollingFileAppender<br />
log4j.appender.A1=org.apache.log4j.RollingFileAppender<br />
log4j.appender.A1.file=container.log<br />
log4j.appender.A1.MaxFileSize=10000KB<br />
# Keep 100 backup files<br />
log4j.appender.A1.MaxBackupIndex=100<br />
<br />
<br />
# A1 uses PatternLayout.<br />
log4j.appender.A1.layout=org.apache.log4j.PatternLayout<br />
log4j.appender.A1.layout.ConversionPattern=%d{ISO8601} %-5p %c{2} [%t,%M:%L] %m%n<br />
<br />
# Display any warnings generated by our code<br />
log4j.category.org.globus=INFO<br />
</pre><br />
<br />
This configuration enables the file rolling behavior and a rollover schedule when the file log size reaches 10MB by managing in this way 100 log files.<br />
<br />
Moreover, we initially suggest also to enable a DEBUG log level for the HNMService and the Profile Management Library. In order to do that, add the following lines to the same file:<br />
<pre><br />
log4j.category.org.diligentproject.keeperservice.hnm.impl=DEBUG<br />
log4j.category.org.diligentproject.common.profile.impl=DEBUG<br />
</pre><br />
<br />
===== server-config.wsdd =====<br />
This file includes a set of global properties related to the container. It is located in the ''$GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd''.<br />
It must be changed in order to allow the DHN to publish its hostname. The following two lines have to be added in the <globalConfiguration> section: <br />
<br />
<pre><br />
<parameter name="logicalHost" value="yourHostName.yourDomain"/><br />
<parameter name="publishHostName" value="true"/><br />
</pre><br />
<br />
Of course, the ''yourHostName.yourDomain'' string must be replaced with your real hostname.<br />
<br />
==== HNMService ====<br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO (working in the pre-production infrastructure)<br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/dev &rarr; to join the Development VO (working in the development infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent/devsec.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a freetext placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
=== Scripts ===<br />
<br />
Scripts that have to be run that take care of post installation activities: NA<br />
<br />
== Testing and Verification ==<br />
<br />
After the installation the DHN automatically joins the Beta infrastructure of DILIGENT. This is a completely new infrastructure that officially becomes the target infrastructure for the Beta releases of all the DILIGENT components. All the profiles produced by the DHN software are published on this new infrastructure glued together by the Beta release of the Collective Layer components. <br />
<br />
To understand if a DHN has been successfully installed it is important to check if the DHN profile and the HNMService Running Instance profiles are correctly published in the DIS of such a infrastructure. A new [http://dlib25.isti.cnr.it/ DILIGENT Administrative Portal] is available to manage this new infrastructure. In order to access to the monitoring capabilities of the Portal, you can use the following:<br />
* user ''monitoring''<br />
* pass ''monitoring''<br />
<br />
== Installation Troubleshooting ==<br />
NA</div>Andreahttps://wiki.gcube-system.org/index.php?title=DHN_Installation&diff=2495DHN Installation2007-10-17T13:30:35Z<p>Andrea: /* Migrating from the previous releases */</p>
<hr />
<div>== Host preparation ==<br />
<br />
=== Minimal host requirements ===<br />
<br />
* Operating System<br />
** any Unix-based tested platform for Java WS Core<br />
*** tested platform: SL3.0, Red Hat FC6, Ubuntu<br />
<br />
* Connectivity<br />
** a machine configured with a static IP address<br />
<br />
* Software<br />
** [http://java.sun.com/j2se/1.5.0/ java 1.5]<br />
** [http://ant.apache.org/ Apache ANT 1.6.0] or higher<br />
** [http://www.globus.org/toolkit/downloads/4.0.4/ Java Ws Core 4.0.4]<br />
<br />
=== Migrating from the previous releases ===<br />
<br />
The last version of the DHN bundle (1.0 FRCv3) can be installed as a full installation as well as an upgrade from a previous DHN distribution.<br />
<br />
== Package Installation ==<br />
<br />
=== Download === <br />
<br />
The DHN 1.0 Final Release Candidate v2 can be downloaded from [https://elibrary.isti.cnr.it/svn_public/diligent_GAR/DHNInstaller/1.0RC/ here].<br />
<br />
=== Installation Procedure ===<br />
<br />
After having prepared the node as described in [[DHN_Installation:Host_preparation| Host preparation]], the following steps have to be performed in order to install the DHN:<br />
* uncompress the ''DHN_installer_1.0RC.tar.gz'' file<br />
* stop the Java WS Core container (if any)<br />
* source your ${GLOBUS_LOCATION}/etc/globus-devel-env.sh file<br />
* if you are installing the DHN from scratch<br />
** type ''make install'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous FRC1 installation:<br />
** type ''make upgradeFromFRC1'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* if you are upgrading a previous Beta installation:<br />
** type ''make upgradeFromBeta'' in the uncompressed ./DHN_installer_1.0RC folder<br />
* follow the [[DHN_Installation:Post-installation_configuration| Post-installation configuration steps]]<br />
* (re)start the container<br />
<br />
=== Included software ===<br />
<br />
The Final Release Candidate version of the DHN Installer includes the following Collective Layer components:<br />
* NAL 1.0 Final RC<br />
* DIS-HLSClient 1.0 Final RC<br />
* DIS-IP 1.0 Final RC<br />
* HNM Service 1.0 Final RC<br />
* HNM Service stubs 1.0 Final RC<br />
* DIS-IC stubs 1.0 Final RC<br />
* DIS-Registry stubs 1.0 Final RC<br />
* DIS-Broker stubs 1.0 Final RC<br />
* DLManagement stubs 1.0 Final RC<br />
* KeeperCommon Library 1.0 Final RC<br />
* DIS-Util Library 1.0 Final RC<br />
* ProfileManagement Library 1.0 Final RC<br />
* DILIGENTProvider 1.0 Final RC<br />
* DILIGENT Provider Stubs 1.0 Final RC<br />
* Authentication API 1.0 Final RC<br />
* Delegation Service 1.0 Final RC<br />
* Delegation Stubs 1.0 Final RC<br />
* DVOS Common Library 1.0 Final RC<br />
* Gas Stubs 1.0 Final RC<br />
* a customised distribution of the Aggregator Framework for Java WS Core 4.0.4<br />
All the components above are also available in ETICS in their *_0_3_0 configurations.<br />
<br />
== Post-installation configuration ==<br />
<br />
=== Configuration files ===<br />
<br />
Configuration files that have to be edited after the installation:<br />
<br />
==== Java WS Core ====<br />
<br />
===== container-log4j.properties =====<br />
<br />
The Log4J output should be redirected on the file system in order to simplify the debugging of what is happening on the DHN and the exchange of such information. The following configuration in the ''$GLOBUS_LOCATION/container-log4j.properties'' file has to replace the default one for the log4j.appender.A1:<br />
<pre><br />
# A1 is set to be a RollingFileAppender<br />
log4j.appender.A1=org.apache.log4j.RollingFileAppender<br />
log4j.appender.A1.file=container.log<br />
log4j.appender.A1.MaxFileSize=10000KB<br />
# Keep 100 backup files<br />
log4j.appender.A1.MaxBackupIndex=100<br />
<br />
<br />
# A1 uses PatternLayout.<br />
log4j.appender.A1.layout=org.apache.log4j.PatternLayout<br />
log4j.appender.A1.layout.ConversionPattern=%d{ISO8601} %-5p %c{2} [%t,%M:%L] %m%n<br />
<br />
# Display any warnings generated by our code<br />
log4j.category.org.globus=INFO<br />
</pre><br />
<br />
This configuration enables the file rolling behavior and a rollover schedule when the file log size reaches 10MB by managing in this way 100 log files.<br />
<br />
Moreover, we initially suggest also to enable a DEBUG log level for the HNMService and the Profile Management Library. In order to do that, add the following lines to the same file:<br />
<pre><br />
log4j.category.org.diligentproject.keeperservice.hnm.impl=DEBUG<br />
log4j.category.org.diligentproject.common.profile.impl=DEBUG<br />
</pre><br />
<br />
===== server-config.wsdd =====<br />
This file includes a set of global properties related to the container. It is located in the ''$GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd''.<br />
It must be changed in order to allow the DHN to publish its hostname. The following two lines have to be added in the <globalConfiguration> section: <br />
<br />
<pre><br />
<parameter name="logicalHost" value="yourHostName.yourDomain"/><br />
<parameter name="publishHostName" value="true"/><br />
</pre><br />
<br />
Of course, the ''yourHostName.yourDomain'' string must be replaced with your real hostname.<br />
<br />
==== HNMService ====<br />
<br />
===== JNDI file =====<br />
<br />
The HNMService performs JNDI lookups for some static configuration parameters. Its JNDI file is located in ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml''<br />
<br />
The global resource ''HNMServiceConfiguration'' groups the configuration parameters. The following ones have to be changed accordingly to the suggestions reported:<br />
<br />
* ''defaultVO''<br />
** This parameter has to be filled with the name of the VO in which the DHN will act. This is the Default VO where the DHN and all the hosted RIs will be published as default behavior. The DHN is pre-configured to work in three different VOs (ARTE, ImpECt and Development) or in the root VO (named diligent). One of the followings has to be specified as default VO value:<br />
*** /diligent &rarr; to join only the global DILIGENT VO (working in the pre-production infrastructure)<br />
*** /diligent/ARTE &rarr; to join the ARTE VO (working in the pre-production infrastructure)<br />
*** /diligent/ImpECt &rarr; to join the ImpECt VO (working in the pre-production infrastructure)<br />
*** /diligent/dev &rarr; to join the Development VO (working in the development infrastructure)<br />
*** /diligent/devsec &rarr; to join the Secure Development VO (working in the development infrastructure)<br />
<br />
The default value is /diligent/devsec.<br />
<br />
* ''DHNProfileUpdateIntervalInMillis''<br />
** the DHN profile is updated accordingly to this interval. The interval is specified as milliseconds.<br />
* ''latitude'' + ''longitude''<br />
** these two coordinates are used to correctly place the DHN on the Google Map visualized by the Monitoring Portlet. To discover which are the coordinates for the DILIGENT partner DHNs see [[DHN-coordinates|here]]<br />
* ''country'': two letter code of the country (e.g. IT)<br />
* ''location'': a freetext placeholder (e.g. Pisa)<br />
* ''localFileSystem''<br />
** the partition on your file system that you want to share with the hosted services<br />
* ''DHNType''<br />
** allowed values here are: ''Dynamic,'' ''Static'' and ''SelfCleaning.'' A static DHN is not used as target for the dynamic deployment, while a SelfCleaning is automatically cleaned every night (used just for demos). The default value is Dynamic.<br />
* ''securityEnabled''<br />
** if ''true,'' the DHN supports a secure context both at VO and DL level. In this case, it is necessary to <br />
# configure the DHN following the instructions reported [[How_To_Configure_DHN_Security|here]]<br />
# overwrite the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd'' with the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/deploy-server.wsdd_SEC'' <br />
<br />
There are other parameters in the resource and they have to be left with their default values.<br />
<br />
=== Scripts ===<br />
<br />
Scripts that have to be run that take care of post installation activities: NA<br />
<br />
== Testing and Verification ==<br />
<br />
After the installation the DHN automatically joins the Beta infrastructure of DILIGENT. This is a completely new infrastructure that officially becomes the target infrastructure for the Beta releases of all the DILIGENT components. All the profiles produced by the DHN software are published on this new infrastructure glued together by the Beta release of the Collective Layer components. <br />
<br />
To understand if a DHN has been successfully installed it is important to check if the DHN profile and the HNMService Running Instance profiles are correctly published in the DIS of such a infrastructure. A new [http://dlib25.isti.cnr.it/ DILIGENT Administrative Portal] is available to manage this new infrastructure. In order to access to the monitoring capabilities of the Portal, you can use the following:<br />
* user ''monitoring''<br />
* pass ''monitoring''<br />
<br />
== Installation Troubleshooting ==<br />
NA</div>Andreahttps://wiki.gcube-system.org/index.php?title=Gcube_Wiki:Community_Portal&diff=2429Gcube Wiki:Community Portal2007-09-19T12:22:15Z<p>Andrea: </p>
<hr />
<div>*[http://www.diligentproject.org DILIGENT Portal]<br />
*[http://www.gcube-system.org gCube Portal]<br />
*[http://diligent.di.uoa.gr/arte/gcube ARTE Scenario Portal] login: (username/password) ArteUser / ArteUser <br />
*[http://diligent.di.uoa.gr:8080/impect/gcube ImpECt Scenario Portal] login: (username/password) ImpectUser / ImpectUser</div>Andreahttps://wiki.gcube-system.org/index.php?title=Gcube_Wiki:Community_Portal&diff=2428Gcube Wiki:Community Portal2007-09-19T12:21:44Z<p>Andrea: </p>
<hr />
<div>*[http://www.diligentproject.org DILIGENT Portal]<br />
*[http://www.gcube-system.org gCube Portal]<br />
*[http://diligent.di.uoa.gr/arte/gcube Scenario Portal] login: (username/password) ArteUser / ArteUser <br />
*[http://diligent.di.uoa.gr:8080/impect/gcube ImpECt Scenario Portal] login: (username/password) ImpectUser / ImpectUser</div>Andreahttps://wiki.gcube-system.org/index.php?title=Package_Repository&diff=2404Package Repository2007-09-14T17:01:00Z<p>Andrea: /* Usage */</p>
<hr />
<div>== Package Repository ==<br />
<br />
=== Introduction ===<br />
<br />
The Package Repository validates, stores, and manages DILIGENT packages. It checks packages dependencies and giving both access to packages relations and access to the stored packages supports the dynamic packages deployment. <br />
<br />
This repository accepts registration requests coming from the Service Archive Registration Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
<br />
=== Implentation Overview ===<br />
<br />
This component is responsible for the validation, storage, and maintenance of the [[ Service_Archive_Specification | DILIGENT service archives]], each service archive contains all files declared on the [[ Profile_Specification | Service Profile]] . It checks packages dependencies and by ensuring access to them, it supports the dynamic packages deployment. <br />
<br />
The Package Repository is a WSRF service, implemented as specified by the Singleton Pattern . Accordingly, it splits the implementation into three sub-components: (i) the resource itself that contains Package Repository state, (ii) the resource home that manages the resource, and (iii) the web service that gives access to components functionality. <br />
<br />
The resource state contains information about the stored service archives. The resource home is used by the web service to create and find the resource. <br />
<br />
The web service provides to the clients, e.g. HNM, access to the Package Repository functionality ([[ Package_Repository#Functionality | see below ]]).<br />
<br />
This service is internally composed by a (i) Parser component and by a (ii) Grid access interface.<br />
<br />
Parser component includes a Validation phase that checks service archives based on service profiles declarations. It assumes that service profiles are valid against the service profile schema. Controls performed includes checking that all declared files are in the right place into the service archive structure, that all service profiles includes at least a WSRF service, that the declared stubs library point to the corresponding package, etc. After this phase was completed PR create a tar gz file for each declared pakage that is provided on request to the HNM.<br />
<br />
Grid Access inteface is in charge of store all PR data structures and packages into the Grid, as well as get from the Grid packages when requested.<br />
Package Repository stores all its data structures and packages into a local cache and into the Grid.<br />
<br />
<br />
==== Functionality ====<br />
<br />
The signatures of the actual implemented methods are presented below. These operations allow uploading, deleting, list, and getting a DILIGENT package. As well as other advanced operations that operate over packages dependencies. <br />
<br />
<br />
:1. '''store'''<br />
<pre><br />
store (ServiceIDURLDescription) -> String<br />
</pre><br />
<br />
This operation stores a service archive into the Package Repository and assigns status pending to it. Pending status means that service archive is valid, and unique ID was not previously used but cannot be deployed.<br />
<br />
''ServiceIDURLDescription'' type contains the unique ID assigned to the service, the URL from where the service archive can be downloaded, and the service description.<br />
<br />
''Return'' String contains unique ID if service archive is valid, null otherwise.<br />
<br />
:2. '''approve'''<br />
<pre><br />
approve (String) -> String<br />
</pre><br />
<br />
Approve an already stored service achive, if unique ID passed exists with pending status.<br />
<br />
''Return'' It returns approved if operation success, an error message otherwise.<br />
<br />
:3. '''delete'''<br />
<pre><br />
delete (String) -> String<br />
</pre><br />
<br />
This operation deletes a stored DILIGENT service archive from the Package Repository if unique ID passed exists. This implies the removal of all software packages from the Grid and from the local cache. <br />
<br />
''Return'' A message reporting success of failure is returned.<br />
<br />
:4. '''get'''<br />
<pre><br />
get (ServiceIDPackage) -> String<br />
</pre><br />
<br />
To identify an unique package on the repository two values must be provided: (i) DILIGENT unique ID and (ii) package name.<br />
<br />
''Return'' The method returns the URI from where the requested package can be downloaded.<br />
<br />
:5. '''getServiceProfile'''<br />
<pre><br />
getServiceProfile (String) -> String<br />
</pre><br />
<br />
''Return'' From a given unique ID this method return the corresponding Service Profile if exists, null otherwise.<br />
<br />
:6. '''getServiceProfileID'''<br />
<pre><br />
getServiceProfileID (ClsssName) -> String<br />
</pre><br />
<br />
''Return'' From a given class and name parameter this method return the corresponding DILIGENT unique ID if exists, null otherwise.<br />
<br />
:7. '''listPending'''<br />
<pre><br />
listPending ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status pending. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:8. '''listApproved'''<br />
<pre><br />
listApproved ( ) -> String<br />
</pre><br />
<br />
''Return'' This operation returns an XML containing all stored service archives with status approved. The XML structure is as follow:<br />
<pre><br />
<Resultset><br />
<Result><br />
<UniqueID>String</UniqueID><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:9. '''listNonDeployableServices'''<br />
<pre><br />
listNonDeployableServices ( ) -> String<br />
</pre><br />
<br />
With this functionality it is possible to know which stored packages are not deployable due missing dependencies.<br />
<br />
''Return'' a XML with the following structure:<br />
<pre><br />
<Resultset><br />
<Result><br />
<Class>String</Class><br />
<Name>String</Name><br />
<PackageName>String</PackageName><br />
</Result><br />
</Resultset><br />
</pre><br />
<br />
:10. '''listAllDependenciesChain'''<br />
<pre><br />
listAllDependenciesChain (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:11. '''listSameDHNPackages'''<br />
<pre><br />
listSameDHNPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DHN dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:12. '''listSameDLPackages'''<br />
<pre><br />
listSameDLPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same DL dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type. <br />
<br />
:13. '''listSameVOPackages'''<br />
<pre><br />
listSameVOPackages (String) -> ListPackageArray<br />
</pre><br />
<br />
This operation lists all same VO dependencies declared on the WSRF package declared on the service profile of a given unique ID. <br />
<br />
''Return'' Returned object type includes unique ID, package name, and type.<br />
<br />
<br />
=== Dependencies ===<br />
<br />
The dependencies of the Package Repository Service are:<br />
*DHN: to host service.<br />
*NAL: to access to HNM.<br />
*Keeper common: for type definition.<br />
*Grid Storage: to store DILIGENT packages on the Grid.<br />
*Profile Manager: to parse Service Profile<br />
*Commons-io from Jakarta: to File system functionality.<br />
*Commons-compress from Jakarta: to File compress functionality.<br />
<br />
=== Usage Example ===<br />
<br />
==== Package Repository client ====<br />
<br />
A Package Repository client is provided. The client uses all PR functionality in different ways, i.e. by calling directly the PR operations and by pre-processing the client input to generate the appropriate series of PR service calls.<br />
<br />
===== Dependencies =====<br />
* Package Repository service<br />
* Keeper common <br />
<br />
===== Usage =====<br />
<pre><br />
java ClientPackageRepository pkgRepositoryURI store diligentID serviceArchiveURI description<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI storeAndApproveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI approve diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI approveList storeListFile<br />
<br />
java ClientPackageRepository pkgRepositoryURI get diligentID packageName<br />
<br />
java ClientPackageRepository pkgRepositoryURI delete diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfile diligentID<br />
<br />
java ClientPackageRepository pkgRepositoryURI getServProfileID class name<br />
<br />
java ClientPackageRepository pkgRepositoryURI listPending<br />
<br />
java ClientPackageRepository pkgRepositoryURI listApproved<br />
<br />
java ClientPackageRepository pkgRepositoryURI listNonDeployable<br />
<br />
java ClientPackageRepository pkgRepositoryURI listAllDependenciesChain serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDHNPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameDLPackages serviceID<br />
<br />
java ClientPackageRepository pkgRepositoryURI listSameVOPackages serviceID<br />
</pre><br />
<br />
Where:<br />
* pkgRepositoryURI: Package Repository address.<br />
* diligentID: The unique ID of a Service Archive.<br />
* serviceArchiveURI: The address from where the Service Archive can be downloaded.<br />
* description: The Service Archive description.<br />
* storeListFile: a list with Service Archives to store {diligentID, URI, description}.<br />
* class: The Service Class.<br />
* name: The Service Name.<br />
* packageName: The package Name.<br />
<br />
==== DILIGENT infrastructure initialization ====<br />
<br />
In order to speed up the setting up of a DILIGENT infrastructure, and align available DILIGENT packages with current development process, an automated client that initialize the core DCL services (DIS and PR) is provided with the Package Repository component.<br />
<br />
The procedure consists on a Thread that run the initialization method described below:<br />
<pre><br />
1. Download from ETICS list of last SA built<br />
2. Delete from DIS all SPs<br />
3. Delete from PR all packages<br />
4. For each SA built<br />
4.1. create a new resource into the DIS<br />
4.2. if successful store SA on PR<br />
4.2.1. if successful log success<br />
else remove resource from DIS and log failure<br />
else log failure<br />
</pre><br />
<br />
===== Dependencies =====<br />
* activation.jar<br />
* commons-compress-20061201.jar<br />
* jaxb-api.jar<br />
* jaxb-impl.jar<br />
* jaxb-xjc.jar<br />
* jaxb1-impl.jar<br />
* jsr173_api.jar<br />
* org_diligentproject_common_profilemanager.jar<br />
* org_diligentproject_keeperservice_packagerepository_stubs.jar<br />
* source globus-devel-env.sh<br />
<br />
===== Usage =====<br />
<br />
Update appropriately the required parameters on the properties file to refer to a completely deployed infrastructure:<br />
<br />
* SLEEP_TIME: Thread sleep time in minutes<br />
* TMP_DIR: directory where all Service Archives from build repository will be downloaded and parsed<br />
* ETICS_SA_LIST_URL: build repository URI<br />
* VO: The VO to Initialize<br />
* PR_EPR: PR to update address<br />
<br />
Run the program from a machine with the CLASSPATH set appropriately.<br />
<br />
=== Know Bugs and Limitations ===<br />
<br />
In current implementation the proxy to access to the Grid need to be created manually.</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=2374Core Services Installation2007-09-12T15:16:49Z<p>Andrea: /* Security Setting */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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 focusses on the entire lifecycle of software packages management ranging from the specifications and conventions they must follow to their physical deployment and relocation.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
*'''Grid Access Service''' (WSRFService) – The Grid Access Service (GAS) provides Grid storage capabilities to all services running in a DHN, allowing services to store on the Grid local files. GAS works at Running Instance level, so each service RI can store its state, or any other data that should survive besides the DHN life cicle. It manages soring, listing, and getting of its own Grid files. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node and giving access to GAS. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to store on the Grid its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed togheter with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
== DL Management ==<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
DONE!<br />
<br />
=== Security Settings ===<br />
<br />
<br />
he 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 .<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
<br />
DLManagement Service installation depends on the type of VO the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
In case of root VO the DLManagement Service needs static information about the root VO name and VOMap file. These parameters has to be configured<br />
through the Service JNDI file:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLMangement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
DONE!<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
The DIS-Registy and DIS-Broker 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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
Setting DIS-Registry and DIS-Broker Credential Renewal Task:<br />
<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass <serviceClass> -serviceName <ServiceName> -proxy \<br />
<proxyFil> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
'''IT'S IMPORTANT TO CREATE FIRST THE DIS-BROKER TASK, THEN THE DIS-REGISTRY TASK''' ( in order to have the DIS-Broker ready first)<br />
<br />
i.e TO create a DIS-Registry Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
/home/andrea/proxy -delegationID diligentproject/informationservice/disregistry/DISRegistryFactoryService \<br />
-delegationServiceURL http://dlib19.isti.cnr.it:8084/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
and a DIS-Broker Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass InformationSystem -serviceName DIS-Broker -proxy \<br />
/home/andrea/proxy -delegationID diligentproject/informationservice/disbroker/DISBrokerService \<br />
-delegationServiceURL http://dlib19.isti.cnr.it:8084/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library providing DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document. Following settings are then required to enable the Credentials Renewal Service to properly operate:<br />
** A <code>Credentials-Manager</code> role must be created in the VOMS VO<br />
** A new identity for the Credentials Renewal Service must be added to the VOMS VO. The CA of the identity must be the one backing the MyProxy OnlineCA installation <br />
** The identity just created must be associated to the <code>VO-Admin</code> role in the root group, as the Credentials Renewal Service must be able to fully manage the VO.<br />
** The Credentials Renewal Service must also be associated to the <code>Credentials-Manager</code> role in the root group, as it must be able to delegate credentials in the DILIGENT infrastructure.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type <code>$GLOBUS_LOCATION/bin/globus-deploy-gar dvos.credential-renewal-service.gar</code> to deploy the Credentials Renewal Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Authorization Service Installation ====<br />
<br />
TO BE ADDED<br />
<br />
=== Post-installation configuration ===<br />
<br />
==== Credentials Renewal Post-installation Configuration ====<br />
<br />
Following properties must be properly set in the $GLOBUS_LOCATION/etc/dvos.credential-renewal-service/jndi-config.xml file after the installation of the Credentials Renewal Service:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| myProxyRepositoryHost || The hostname of the machine hosting the MyProxy repository service || grids02.eng.it<br />
|-<br />
| myProxyRepositoryPort || The port number of the MyProxy repository service || 7512<br />
|-<br />
| myProxyOnlineCAHost || The hostname of the machine hosting the MyProxy online CA service || grids04.eng.it<br />
|-<br />
| myProxyOnlineCAPort || The port number of the MyProxy online CA service || 7512<br />
|-<br />
| voName || The name of the VOMS VO backing the DILIGENT VO, as in the vomses file of the local machine || diligent-dev<br />
|-<br />
| groupName || The name of the VO group where the Credentials Renewal service is entitled to operate || /diligent<br />
|-<br />
| serviceCA || The DN of the online CA in the OSG format || /O=Grid/OU=GlobusTest<br />
/OU=simpleCA-gauss.eng.it<br />
/CN=Globus Simple CA (on a single line)<br />
|-<br />
| serviceDN || The DN of the Credentials Renewal Service certificate in the OSG format || /O=Grid/OU=GlobusTest<br />
/OU=simpleCA-gauss.eng.it<br />
/OU=eng.it/CN=CredentialsRenewalService (on a single line)<br />
|-<br />
| servletHost || The VOMS Servlet host name || grids15.eng.it<br />
|-<br />
| servletPort || The VOMS Servlet port name || 8094<br />
|}<br />
<br />
==== Authorization Service Post-installation Configuration ====<br />
<br />
TO BE ADDED<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=2373Core Services Installation2007-09-12T15:16:33Z<p>Andrea: /* Security Setting */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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 focusses on the entire lifecycle of software packages management ranging from the specifications and conventions they must follow to their physical deployment and relocation.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
*'''Grid Access Service''' (WSRFService) – The Grid Access Service (GAS) provides Grid storage capabilities to all services running in a DHN, allowing services to store on the Grid local files. GAS works at Running Instance level, so each service RI can store its state, or any other data that should survive besides the DHN life cicle. It manages soring, listing, and getting of its own Grid files. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node and giving access to GAS. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to store on the Grid its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed togheter with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
== DL Management ==<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
DONE!<br />
<br />
=== Security Settings ===<br />
<br />
<br />
he 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 .<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
<br />
DLManagement Service installation depends on the type of VO the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
In case of root VO the DLManagement Service needs static information about the root VO name and VOMap file. These parameters has to be configured<br />
through the Service JNDI file:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLMangement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
DONE!<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
The DIS-Registy and DIS-Broker 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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
Setting DIS-Registry and DIS-Broker Credential Renewal Task:<br />
<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass <serviceClass> -serviceName <ServiceName> -proxy \<br />
<proxyFil> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
'''<br />
IT'S IMPORTANT TO CREATE FIRST THE DIS-BROKER TASK, THEN THE DIS-REGISTRY TASK''' ( in order to have the DIS-Broker ready first)<br />
<br />
i.e TO create a DIS-Registry Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
/home/andrea/proxy -delegationID diligentproject/informationservice/disregistry/DISRegistryFactoryService \<br />
-delegationServiceURL http://dlib19.isti.cnr.it:8084/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
and a DIS-Broker Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass InformationSystem -serviceName DIS-Broker -proxy \<br />
/home/andrea/proxy -delegationID diligentproject/informationservice/disbroker/DISBrokerService \<br />
-delegationServiceURL http://dlib19.isti.cnr.it:8084/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library providing DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document. Following settings are then required to enable the Credentials Renewal Service to properly operate:<br />
** A <code>Credentials-Manager</code> role must be created in the VOMS VO<br />
** A new identity for the Credentials Renewal Service must be added to the VOMS VO. The CA of the identity must be the one backing the MyProxy OnlineCA installation <br />
** The identity just created must be associated to the <code>VO-Admin</code> role in the root group, as the Credentials Renewal Service must be able to fully manage the VO.<br />
** The Credentials Renewal Service must also be associated to the <code>Credentials-Manager</code> role in the root group, as it must be able to delegate credentials in the DILIGENT infrastructure.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type <code>$GLOBUS_LOCATION/bin/globus-deploy-gar dvos.credential-renewal-service.gar</code> to deploy the Credentials Renewal Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Authorization Service Installation ====<br />
<br />
TO BE ADDED<br />
<br />
=== Post-installation configuration ===<br />
<br />
==== Credentials Renewal Post-installation Configuration ====<br />
<br />
Following properties must be properly set in the $GLOBUS_LOCATION/etc/dvos.credential-renewal-service/jndi-config.xml file after the installation of the Credentials Renewal Service:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| myProxyRepositoryHost || The hostname of the machine hosting the MyProxy repository service || grids02.eng.it<br />
|-<br />
| myProxyRepositoryPort || The port number of the MyProxy repository service || 7512<br />
|-<br />
| myProxyOnlineCAHost || The hostname of the machine hosting the MyProxy online CA service || grids04.eng.it<br />
|-<br />
| myProxyOnlineCAPort || The port number of the MyProxy online CA service || 7512<br />
|-<br />
| voName || The name of the VOMS VO backing the DILIGENT VO, as in the vomses file of the local machine || diligent-dev<br />
|-<br />
| groupName || The name of the VO group where the Credentials Renewal service is entitled to operate || /diligent<br />
|-<br />
| serviceCA || The DN of the online CA in the OSG format || /O=Grid/OU=GlobusTest<br />
/OU=simpleCA-gauss.eng.it<br />
/CN=Globus Simple CA (on a single line)<br />
|-<br />
| serviceDN || The DN of the Credentials Renewal Service certificate in the OSG format || /O=Grid/OU=GlobusTest<br />
/OU=simpleCA-gauss.eng.it<br />
/OU=eng.it/CN=CredentialsRenewalService (on a single line)<br />
|-<br />
| servletHost || The VOMS Servlet host name || grids15.eng.it<br />
|-<br />
| servletPort || The VOMS Servlet port name || 8094<br />
|}<br />
<br />
==== Authorization Service Post-installation Configuration ====<br />
<br />
TO BE ADDED<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=2372Core Services Installation2007-09-11T18:42:41Z<p>Andrea: /* Security Settings */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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 focusses on the entire lifecycle of software packages management ranging from the specifications and conventions they must follow to their physical deployment and relocation.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
*'''Grid Access Service''' (WSRFService) – The Grid Access Service (GAS) provides Grid storage capabilities to all services running in a DHN, allowing services to store on the Grid local files. GAS works at Running Instance level, so each service RI can store its state, or any other data that should survive besides the DHN life cicle. It manages soring, listing, and getting of its own Grid files. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node and giving access to GAS. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to store on the Grid its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed togheter with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
== DL Management ==<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
DONE!<br />
<br />
=== Security Settings ===<br />
<br />
<br />
he 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 .<br />
<br />
Setting the DLManagement Credential Renewal Task:<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass Keeper -serviceName DLManagement -proxy \<br />
<proxyFile> -delegationID diligentproject/keeperservice/dlmanagement/DLManagementFactoryService \<br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Credentials-Manager<br />
<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
<br />
DLManagement Service installation depends on the type of VO the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
In case of root VO the DLManagement Service needs static information about the root VO name and VOMap file. These parameters has to be configured<br />
through the Service JNDI file:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLMangement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
DONE!<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
The DIS-Registy and DIS-Broker 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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
Setting DIS-Registry and DIS-Broker Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass <serviceClass> -serviceName <ServiceName> -proxy \<br />
<proxyFil> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
i.e TO create a DIS-Registry Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
/home/andrea/proxy -delegationID diligentproject/informationservice/disregistry/DISRegistryFactoryService \<br />
-delegationServiceURL http://dlib19.isti.cnr.it:8084/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
and a DIS-Broker Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass InformationSystem -serviceName DIS-Broker -proxy \<br />
/home/andrea/proxy -delegationID diligentproject/informationservice/disbroker/DISBrokerService \<br />
-delegationServiceURL http://dlib19.isti.cnr.it:8084/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library providing DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - This service is in charge of periodically refresh credentials of other DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This service is part of the gLite grid middleware and can be installed following steps of [https://edms.cern.ch/file/818502/1.1/VOMS-Installation_Configuration-Guide.pdf this] document. Following settings are then required to enable the Credentials Renewal Service to properly operate:<br />
** A <code>Credentials-Manager</code> role must be created in the VOMS VO<br />
** A new identity for the Credentials Renewal Service must be added to the VOMS VO. The CA of the identity must be the one backing the MyProxy OnlineCA installation <br />
** The identity just created must be associated to the <code>VO-Admin</code> role in the root group, as the Credentials Renewal Service must be able to fully manage the VO.<br />
** The Credentials Renewal Service must also be associated to the <code>Credentials-Manager</code> role in the root group, as it must be able to delegate credentials in the DILIGENT infrastructure.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type <code>$GLOBUS_LOCATION/bin/globus-deploy-gar dvos.credential-renewal-service.gar</code> to deploy the Credentials Renewal Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Authorization Service Installation ====<br />
<br />
TO BE ADDED<br />
<br />
=== Post-installation configuration ===<br />
<br />
==== Credentials Renewal Post-installation Configuration ====<br />
<br />
Following properties must be properly set in the $GLOBUS_LOCATION/etc/dvos.credential-renewal-service/jndi-config.xml file after the installation of the Credentials Renewal Service:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| myProxyRepositoryHost || The hostname of the machine hosting the MyProxy repository service || grids02.eng.it<br />
|-<br />
| myProxyRepositoryPort || The port number of the MyProxy repository service || 7512<br />
|-<br />
| myProxyOnlineCAHost || The hostname of the machine hosting the MyProxy online CA service || grids04.eng.it<br />
|-<br />
| myProxyOnlineCAPort || The port number of the MyProxy online CA service || 7512<br />
|-<br />
| voName || The name of the VOMS VO backing the DILIGENT VO, as in the vomses file of the local machine || diligent-dev<br />
|-<br />
| groupName || The name of the VO group where the Credentials Renewal service is entitled to operate || /diligent<br />
|-<br />
| serviceCA || The DN of the online CA in the OSG format || /O=Grid/OU=GlobusTest<br />
/OU=simpleCA-gauss.eng.it<br />
/CN=Globus Simple CA (on a single line)<br />
|-<br />
| serviceDN || The DN of the Credentials Renewal Service certificate in the OSG format || /O=Grid/OU=GlobusTest<br />
/OU=simpleCA-gauss.eng.it<br />
/OU=eng.it/CN=CredentialsRenewalService (on a single line)<br />
|-<br />
| servletHost || The VOMS Servlet host name || grids15.eng.it<br />
|-<br />
| servletPort || The VOMS Servlet port name || 8094<br />
|}<br />
<br />
==== Authorization Service Post-installation Configuration ====<br />
<br />
TO BE ADDED<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andreahttps://wiki.gcube-system.org/index.php?title=Core_Services_Installation&diff=2352Core Services Installation2007-09-09T20:29:19Z<p>Andrea: /* Security Setting */</p>
<hr />
<div>== Platform Wide Dependencies ==<br />
<br />
== Environment Setup ==<br />
<br />
== Keeper ==<br />
<br />
The Keeper service 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 focusses on the entire lifecycle of software packages management ranging from the specifications and conventions they must follow to their physical deployment and relocation.<br />
The Keeper service is a logical service composed by:<br />
*'''Package Repository Service''' (WSRFService) – The Package Repository validates, stores, and manages DILIGENT 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 Protlet that is part of the VDL service, whilst accepts access requests from the DL service and the HNM service.<br />
*'''Grid Access Service''' (WSRFService) – The Grid Access Service (GAS) provides Grid storage capabilities to all services running in a DHN, allowing services to store on the Grid local files. GAS works at Running Instance level, so each service RI can store its state, or any other data that should survive besides the DHN life cicle. It manages soring, listing, and getting of its own Grid files. <br />
* '''DL Management Service''' (WSRFService) – This component coordinates the packages deployment process when a new DL is instantiated and during its lifetime. The operational context that transforms a set of distributed deployed DILIGENT resources into a single application is managed by this component by constructing a DL Map, i.e. a map containing the DL resources locations, their configuration, and the rules to access them.<br />
* '''Hosting Node Manager Service''' (WSRFService) – The Hosting Node Manager (HNM) manages the Diligent Hosting Node (DHN) by providing the context to deploy the DILIGENT packages accordingly to the DL Management instructions. In particular, when the HNM is deployed, it controls the software dependencies by using the Package Repository, and then it automatically downloads and deploys all the DHN mandatory packages. It also deploys by default the shared Node Access Library (NAL) that exposes a uniform API allowing to query the current node configuration on the node and giving access to GAS. Moreover, it creates and publishes into the DIS the profiles of all Running Instances deployed in the Java WS Core. Clearly, the HNM must be pre-deployed on each DHN of the DILIGENTinfrastructure.<br />
*'''Node Access Library''' (Library) – The Node Access Library (NAL) provides functionalities to access the local DHN configuration and allows RI to store on the Grid its own data.<br />
*'''Profile Manager Library''' (Library) – The Profile Manager library is an utility package that lets DILIGENT services manage easily DILIGENT XML Resource profiles.<br />
*'''Keeper Common Library''' (Library) – This library is composed by a set of WSDL definitions, that all the Keeper Services include in their WSDL. At compilation time (using the WSDL2Java tool), these definitions are evaluated and generate a set of Java classes that can be referred inside service code.<br />
<br />
=== Pre-installation setup ===<br />
All the Keeper Libraries and stubs are deployed togheter with the DHN installation, that contains also the Hosting Node Manager (HNM) Service.<br />
The Package Repository DHN requires a node with Apache Server installed and therefore the port Apache listens for connections has not to be behind a firewall. <br />
<br />
=== Main installation procedure ===<br />
<br />
== DL Management ==<br />
<br />
The DLManagement Service is a VO specific service that has to be deployed for each VO ( in the gCube Advanced release will be introduced the Dynamic-VO deployment and therefore also the DLManagement will be automatically deployed for each VO).<br />
As any of the Collective layer services managing the root VO, the DLManagement as to be deployed manually and properly configured.<br />
<br />
The DLManagement ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_keeperservice_dlmanagement.gar to deploy the DLManagement Service on the local container;<br />
* 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.<br />
<br />
DONE!<br />
<br />
=== Security Settings ===<br />
<br />
=== Post-installation configuration ===<br />
<br />
<br />
DLManagement Service installation depends on the type of VO the DLManagement has to manage:<br />
<br />
* "Root" VO;<br />
* Sub-VO;<br />
<br />
In case of root VO the DLManagement Service needs static information about the root VO name and VOMap file. These parameters has to be configured<br />
through the Service JNDI file:<br />
<br />
* voName : the root VO Name<br />
* voMapPath : the VOMap path relative to the DLMangement container folder.<br />
<br />
The JNDI file contains further parameter to be configured (both for VO - subVO deployment):<br />
* useBMM : if true the DLManagement will use the BMM Service to retrieve the best deployment Schema during automatic deployment<br />
* startSweeper : if true starts the DHNSweeper, that removes from the DIS RI and related DHN Profiles not more reachable.<br />
* sweeperDelay : the sweeper delay in ms.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Broker & Matchmaker (BMM) ==<br />
The BMM Service is composed by the following components: <br />
* The '''BMM Connector''' (Java Library) and the '''BMM API''' (Java Library) allow clients (e.g. the DL Management service) to send a matching request, and notify them with the response.<br />
* The '''DIS Connector''' (Java Library) is in charge of keeping up-to-date tracks of the DHN profiles received from the DIS and to query the DIS in order to gather information the service or the algorithm needs for their computations.<br />
* The '''BMM Service''' (WSRF Service) provides the core functionalities of the BMM component. By invoking the DIS Connector it queries the DIS in order to gather information about packages, then it forwards the BMM Connector request to the BMM Algorithm and, when the response is ready, it returns back the result.<br />
* The '''BMM Utils''' (Java Library) is a library shared by other components. It defines exceptions and provides the validator used to parse the request and the response, as well as other helper classes.<br />
* The '''BMM Algorithm''' (Java Library) calculates, by running a customized version of first-fit algorithm, the associations among packages and DHNs.<br />
<br />
=== Pre-installation setup ===<br />
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 (DHN) for each VO.<br />
The BMM API and the BMM Connector libraries should be deployed on the client side. The other components on the server side.<br />
<br />
=== Main installation procedure ===<br />
The BMM ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar bmm.matchMaker-service.gar to deploy the BMM Service on the local container; <br />
* copy ServiceProfile_broker_BMM.xml under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/ServicesProfiles/'' folder in order to publish the BMM Service on the Running Instance of the DHN and in order to enable the service to accept requests from its clients.<br />
DONE!<br />
<br />
=== Post-installation configuration ===<br />
None.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that may appear. Workarounds to common problems<br />
<br />
== DILIGENT Information Service (DIS) ==<br />
<br />
The following components compose the DILIGENT Information Service:<br />
*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. <br />
*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.<br />
*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.<br />
*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.<br />
*DIS-Registry (WSRFService) – This service provides registration and un-registration facilities for the DILIGENT resources profiles.<br />
*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.<br />
*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.<br />
<br />
=== Pre-installation setup ===<br />
<br />
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. <br />
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). <br />
<br />
The Installation of the root DIS requires at least 3 nodes:<br />
<br />
* the DIS-Registry DHN<br />
<br />
* the DIS-Broker DHN<br />
<br />
* the DIS-IC DHN<br />
<br />
The DIS-BDIIClient is a VO specific Services and is no needed at root VO level.<br />
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:<br />
<br />
* Deploy the DIS-Broker and the DIS-Registry on the same DHN<br />
<br />
* Deploy the DIS-IC on a separate DHN.<br />
<br />
The following installation documentation assumes that this is the target deployment schema.<br />
<br />
=== Main installation procedure ===<br />
<br />
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.<br />
<br />
==== DHN root Installation ====<br />
<br />
The "root" DHN has to be installed following the [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation Admin guide]. Once the installation has been done, the only change to standard DHN installation is on the HNM Service JNDI file:<br />
* The "rootDHN" parameter has to be set to true ( the DIS DHN is also of type Static)<br />
<br />
==== DIS-IC Installation ====<br />
<br />
TBD<br />
<br />
==== DIS-Broker Installation ====<br />
<br />
The DISBroker ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disbroker.gar to deploy the DIS-Broker Service on the local container;<br />
<br />
DONE!<br />
<br />
==== DIS-Registry Installation ====<br />
<br />
The DISRegistry ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type globus-deploy-gar org_diligentproject_informationservice_disregistry.gar to deploy the DIS-Registry Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Security Setting ====<br />
<br />
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.<br />
In case the VO has to be deployed without security just:<br />
* enter the specific container folder of DIS services (i.e for DIS-Registry : $GLOBUS_LOCATION/etc/org_diligentproject_informationservice_disregistry )<br />
* copy the content of ''deploy-server.wsdd_NOSEC'' file inside ''server-config.wsdd'' file<br />
* this will remove the link to the service security-descriptor and has to be done for all DIS services.<br />
<br />
The DIS-Registy and DIS-Broker 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.<br />
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 [http://grids17.eng.it/engrepository/ Eng repository ].<br />
<br />
Setting DIS-Registry and DIS-Broker Credential Renewal Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID <ID> \<br />
-host <CredentialHost> -port <CredentialPort> -voName <VO> -groupName <VOMS group> -serviceClass <serviceClass> -serviceName <ServiceName> -proxy \<br />
<proxyFil> -delegationID <WSRFEntryPoint> <br />
-delegationServiceURL http://<host>:<port>/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
i.e TO create a DIS-Registry Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass InformationSystem -serviceName DIS-Registry -proxy \<br />
/home/andrea/proxy -delegationID diligentproject/informationservice/disregistry/DISRegistryFactoryService \<br />
-delegationServiceURL http://dlib19.isti.cnr.it:8084/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
and a DIS-Broker Task:<br />
<br />
<pre><br />
java org.diligentproject.dvos.credentialRenewal.ui.CredentialRenewalUI -addTask -accountID b8cf9578-1bcf-4471-b982-356781cc7df5 \<br />
-host grids06.eng.it -port 8086 -voName diligent -groupName /diligent/devsec -serviceClass InformationSystem -serviceName DIS-Broker -proxy \<br />
/home/andrea/proxy -delegationID diligentproject/informationservice/disbroker/DISBrokerService \<br />
-delegationServiceURL http://dlib19.isti.cnr.it:8084/wsrf/services/diligentproject/dvos/delegation/DelegationService \<br />
-period 24 -roles Basic<br />
</pre><br />
<br />
=== Post-installation configuration ===<br />
<br />
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.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== VDL Generator ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Dynamic Virtual Organization Support (DVOS) ==<br />
The components of the Dynamic Virtual Organization Support are:<br />
* DVOS Common library - A package containing common classes used in DVOS components (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Authentication-API library - A library providing DILIGENT services with some utility method useful to manage authentication tokens (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Delegation Service - A service allowing clients to delegate proxy credentials to DILIGENT services running on a DHN (part of the Diligent Hosting Node, see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DHN_Installation here] for installation instructions)<br />
* Credentials Renewal Service - A in charge of periodically refresh credentials of DILIGENT services<br />
* Authorization service - A service allowing management of DILIGENT authorization elements, for a detailed description of DILIGENT authorization model see [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Security_Model here] <br />
<br />
=== Pre-installation setup ===<br />
The DILIGENT security model is based on some existing security components. Following services must be installed (or already present in the infrastructure) to enable security funcionalities.<br />
<br />
* MyProxy repository - This repository is required to host temporary credentials of users liable for DILIGENT RIs. These credentials are then delegated to services. To install and configure a MyProxy repository service you can follow [http://grid.ncsa.uiuc.edu/myproxy/install.html these] steps.<br />
* MyProxy OnlineCA - This service is required to create temporary credentials for users and services authenticated with the DILIGENT Simple Certification Authority. To install and configure a MyProxy online CA service you can follow [http://grid.ncsa.uiuc.edu/myproxy/ca/ these] steps.<br />
* VOMS - This component can be already installed to manage VO in your grid infrastructure or it can be installed following [[LINK_TO_BE_ADDED]] steps. A new VO for the infrastructure must also be created in the VOMS server.<br />
* VOMSServlet - the servlet required by DILIGENT services to interoperate with the VOMS administration web interface. For detailed information about how to install such a component you can refer [http://ddwiki.di.uoa.gr/mediawiki/index.php/DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet here].<br />
<br />
=== Main installation procedure ===<br />
<br />
<br />
==== Credentials Renewal Installation ====<br />
<br />
The Credentials Renewal ServiceArchive 0_3_0 can be downloaded from the [http://grids17.eng.it/engrepository/ Eng repository ]. These are the installation steps to follow:<br />
* Unpack the ServiceArchive tar.gz file;<br />
* type <code>$GLOBUS_LOCATION/bin/globus-deploy-gar dvos.credential-renewal-service.gar</code> to deploy the Credentials Renewal Service on the local container;<br />
<br />
DONE!<br />
<br />
==== Authorization Service Installation ====<br />
<br />
TO BE ADDED<br />
<br />
=== Post-installation configuration ===<br />
<br />
==== Credentials Renewal Post-installation Configuration ====<br />
<br />
Following properties must be properly set in the $GLOBUS_LOCATION/etc/dvos.credential-renewal-service/jndi-config.xml file after the installation of the Credentials Renewal Service:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! Parameter Name || Description || Example<br />
|-<br />
| myProxyRepositoryHost || The hostname of the machine hosting the MyProxy repository service || grids02.eng.it<br />
|-<br />
| myProxyRepositoryPort || The port number of the MyProxy repository service || 7512<br />
|-<br />
| myProxyOnlineCAHost || The hostname of the machine hosting the MyProxy online CA service || grids04.eng.it<br />
|-<br />
| myProxyOnlineCAPort || The port number of the MyProxy online CA service || 7512<br />
|-<br />
| voName || The name of the VOMS VO backing your infrastructure installation, as in the vomses file installed in the local machine for the VO created in the Credentials Renewal Service Pre-installation steps || diligent-dev<br />
|-<br />
| groupName || The name of the VO root group || /diligent<br />
|-<br />
| serviceCA || The DN of the online CA in the OSG format || /O=Grid/OU=GlobusTest<br />
/OU=simpleCA-gauss.eng.it<br />
/CN=Globus Simple CA (on a single line)<br />
|-<br />
| serviceDN || The DN of the Credentials Renewal Service certificate in the OSG format || /O=Grid/OU=GlobusTest<br />
/OU=simpleCA-gauss.eng.it<br />
/OU=eng.it/CN=CredentialsRenewalService (on a single line)<br />
|-<br />
| servletHost || The VOMS Servlet host name || grids15.eng.it<br />
|-<br />
| servletPort || The VOMS Servlet port name || 8094<br />
|}<br />
<br />
==== Authorization Service Post-installation Configuration ====<br />
<br />
TO BE ADDED<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems<br />
<br />
== Portals ==<br />
<br />
=== Pre-installation setup ===<br />
Actions to be performed before initiating the installation of this service.<br />
<br />
=== Main installation procedure ===<br />
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:<br />
* Package Repository<br />
* DL Management and<br />
* Hosting Node Management<br />
<br />
=== Post-installation configuration ===<br />
Configuration files that have to be edited after the installation. Scripts that have to be run that take care of post installation activities.<br />
<br />
=== Testing and verifying the installation ===<br />
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.<br />
<br />
=== Installation troubleshooting ===<br />
Things that can go wrong. Error messages that my appear. Workarounds to common problems</div>Andrea