Difference between revisions of "Administrator Guide"
Manuele.simi (Talk | contribs) (→Configuring the gHN) |
Manuele.simi (Talk | contribs) (→Configuring the gHN) |
||
| Line 129: | Line 129: | ||
|} | |} | ||
| − | For | + | For an in-depth explanation of the scope-related parameters (infrastructure and startScopes) and the meaning of scope, see the [[Scope_Management|Dealing with Scope]] section of the Developer Guide. |
=== Configuring Logging === | === Configuring Logging === | ||
Revision as of 15:15, 26 August 2008
This Guide covers the installation, configuration, and maintenance of gCore.
Prerequisites
The following software is a prerequisite for the installation of gCore:
- A platform compatible or made compatible with GT requirements.
- J2SE 1.5.08 SDK or greater. Sun's reference implementation is recommended, but versions from IBM, HP, or BEA should work equally well.
- Ant 1.6.5+ to build gCF sources or to develop services with it.
- a SVN client to install gCore from the SVN repository.
- GNU tar to install gCore from archived distributions.
- sudo to execute shell commands with controlled super-user privileges.
Running gCore in a secure infrastructure raises further prerequisites:
- A ntp server to synchronise your clock with other machines' for correct credential validation.
- A host certificate and private key (owned by the user that runs the container) respectively in:
/etc/grid-security/hostpubliccert.pem(please check that the certificate file has -rw-r--r-- permissions)/etc/grid-security/hostprivatekey.pem(please check that the private key file has -r-------- permissions).
Finally, at least static IP address (if not a DNS name) is needed for all but the simplest testing scenarios.
Installation
gCore may be installed from a SVN repository, or else from pre-packaged archives.
In the first case, installing gCore is tantamount to downloading it into a directory of choice, the gCore location. In the second case, installing gCore is simply matter of expanding the downloaded archive into the the gCore location. In either case, proceed to the installation as a a non-privileged user with read and write permissions for the gCore location.
At the end of the process, the gCore location should contain the following structure:
|-bin | |-config | |-endorsed | |-etc | |-lib | |-libexec | |-share
Some folders are of immediate interest to administrators and developers alike:
| bin | executables |
| config | gHN configuration files |
| etc | container and deployed service configuration files |
| lib | standard and deployed service libraries |
| share | build tools, standard and deployed service interfaces/schemas |
Configuration
Configuring the installation can be roughly distributed across the following steps: configuring the environment, the container, the gHN associated with a running instance of the container, and the operation of the gHN in a secure infrastructure.
Configuring the Environment
Define an environment variable GLOBUS_LOCATION and point it to the gCore location. Assuming a bash shell:
export GLOBUS_LOCATION = ...absolute path to your gCore location...
Adding $GLOBUS_LOCATION/bin to your PATH environment variable is also highly recommended:
export PATH = $PATH:$GLOBUS_LOCATION/bin
Finally, building gCF form sources requires to set an environment variable BUILD_LOCATION to the location from which ant will be invoked and where temporary build structures and artefacts will be located:
export BUILD_LOCATION = ...absolute path to your build location...
Configuring the Container
Specify the hostname of your machine as the value of logicalHost parameter in the container's configuration file $GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd:
<parameter name="logicalHost" value="..yourhostname..."/>
Configuring the gHN
In the gHN's configuration file $GLOBUS_LOCATION/config/GHNConfig.xml, override wherever appropriate the default values of the following properties:
| securityenabled | true if the gHN can operate in a secure infrastructure, false otherwise. |
| mode | in a STANDALONE mode, the gHN does not publish profiles (its own and those of the deployed Running Instances) or state (WS-Resources) in the infrastructure. In a CONNECTED mode, it does. |
| infrastructure | the name of infrastructure of the gHN. (e.g. gcube, d4science,...). |
| startScopes | a comma-separated list of VOs that the gHN joins. |
| labels | the name of the file that includes custom labels to characterize the gHN. These are added to the ones automatically computed by gCore and published in the gHN profile. The filename must be relative to the /config folder. |
| GHNtype | when configured as STATIC, the gHN is not used as target for dynamic deployment operations. If configured as DYNAMIC, the gHN can be dynamically enriched with new services when needed. |
| localProxy | if the gHN has no delegated credentials it tries to use the ones specified here. The filename must be relative to the /config folder. |
| coordinates | a pair of comma-separated values for the latitude and longitude of the gHN. Coordinates for some popular locations are available here. |
| country | a double-char code of the Country where the gHN is located |
| location | the name of the location |
| updateInterval | how often the gHN must has to refresh its profile on the IS (in seconds) |
For an in-depth explanation of the scope-related parameters (infrastructure and startScopes) and the meaning of scope, see the Dealing with Scope section of the Developer Guide.
Configuring Logging
A running gCore container will produce extensive logs in accordance with the log4j configuration directives container in $GLOBUS_LOCATION/container-log4j.properties. By default, the container logs in a file container.log and with a DEBUG level for all the gCore code components. container.log is created in the location from which the container is started.
Configure container security
Set Global security descriptor of Java-WS-Core container in file $GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml.
See global_security_descriptor.xml example.
Please be sure to properly set the <context-timer-interval value="300000"/> tag to ease the effect of the GSISecureConversation memory leak problem in the Java-WS-Core (see example above).
Modify the $GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd file adding following lines inside the <globalConfiguration> tag:
<parameter name="containerSecDesc" value="etc/globus_wsrf_core/global_security_descriptor.xml"/>
(of course you have to replace yourHostName and yourDomain properties with correct values, E.g: grids10.gcore.org)
Configure VOMS credentials
VOMS credentials must be installed in the local system to verify VOMS assertions. To do this first of all copy in the /etc/grid-security/vomsdir directory certificates of trusted VOMS servers (please check that certificate files have -rw-r--r-- permissions).
You also need to create vomses files in /opt/glite/etc/vomses. These files should follows this naming convention:
<name of the VO>-<hostname of the VOMS service>
(E.g: grids01.gcore.core)
The content of each file must be as follows (on one single line):
"<name of the VO>" "<hostname of the VOMS service>" "<port of the VOMS service>" "<Distinguished Name of the VOMS certificate>" "<local name of the VO>"
E.g: "gCore" "grids01.gcore.org" "15001" "/C=IT/O=INFN/OU=Host/L=GCORE/CN=grids01.gcore.org" "gCore"
Please notice that the VO name 'gCore' should be associated to the VOMS service running on grids01.gcore.org, this will assure to properly validate assertions contained in proxy credentials
Optional: Install voms-proxy-init command for local testing
Download from BSCW required rpm and configuration file.
Install rpm in the order they appear in the BSCW.
Copy the configuration file to the directory /etc/glite/profile.d/
Modify the configuration file to set the right JAVA_HOME and GLOBUS_LOCATION.
Verify the Installation
To verify the installation, start the container with the script $GLOBUS_LOCATION/bin/gcore-start-container. Assuming PATH is set as recommended above:
gcore-start-container
will suffice. Any instance of the container which is already running should be automatically kill-ed and the new instance should log the list of deployed services in nohup.out and detailed information about the startup of local services in container.log. Both files will be created in location from which the container was started, Lack of visible errors in both files indicates a successful gCore installation.
