LCG Generic Installation and Configuration



Document identifier: LCG-GIS-MI
Date: 2 March 2005
Author: Guillermo Diez-Andino, Laurence Field, Oliver Keeble, Antonio Retico, Alessandro Usai
Version: v2.3.0-6
Abstract: LCG Generic Installation Guide

Contents

Introduction to Manual Installation and Configuration

This document is addressed to Site Administrators in charge of LCG middleware installation and configuration.
It is a generic guide to manual installation and configuration for any supported LCG node types.
It provides a fast method to install and configure the LCG middleware on the various LCG node types (WN, UI, CE, SE ...) on the top of the following Linux distributions. The proposed installation and configuration method is based on the Debian apt-get tool and on a set of shell scripts built within the yaim framework [2].
The provided scripts can be used by Site Administrators with no need for in-depth knowledge of specific middleware configuration details.
Site Administrators are only requested to insert local site-specific data in a single configuration file, according to provided examples.
The resulting configuration is a default site configuration. Local customizations and tuning of the middleware, if needed, can then be done manually1.

New versions of this document will be distributed synchronously with the LCG middleware releases and they will contain the current ``state-of-art'' of the installation and configuration procedures.
A dual document with the upgrade procedures to manually update the configuration of the nodes from the previous LCG version to the current one is also part of the release.

Since the release LCG-2_3_0, the manual installation and configuration of LCG nodes is supported by a set of scripts.
Nevertheless, the automatic configuration for some particular node types has been intentionally left not covered. This mostly happens when a particular possible configuration is not recommended or obsolete within the LCG-2 production environment (e.g. Computing Element with Open-PBS).
Two list of ``supported'' and ``not recommended'' node configurations follows.

The ``supported'' node types are:

For the node types above listed both installation and configuration scripts are provided.

The ``deprecated'' node types are: For the node types above listed only the installation script is provided. Sites Administrators who, for any reasons, choose to go for a not recommended node type can perform the configuration according to the guidelines provided in the generic technical configuration reference [1].

In the following sections the simple steps needed to have a site installed are described.

OS Installation

The current version of the LCG Middleware runs on Ret Hat 7.3 (RH7.3) and Scientific Linux 3 (SL3).
We strongly recommend all the LCG production sites to switch as soon as possible at least their service nodes to the SL3 operating system.
In that order we give here a link to the web page with all the needed information is the following:

https://plone.fnal.gov/Plone/Scientific%20Linux/sl.download/

The site where the sources, and the images (iso) to create the CDs can be found is

ftp://ftp.scientificlinux.org/linux/scientific/301/iso/


Node Synchronization

A general requirement for the LCG nodes is that they were synchronized. This requirement may be fulfilled in several ways. If your nodes run under AFS most likely they are already synchronized. Otherwise, you can use the NTP protocol with a time server.

Instructions and examples for a NTP client configuration are provided in this section. If you are not planning to use a time server on your machine you can just skip it.

NTP Software Installation

In order to install the NTP client, you need the following rpms to be installed: The following versions of the above said rpms have been proven to work on our OS configuration (the list includes the corresponding links to download sites):

NTP Configuration

Configuration Tool: YAIM

From now on we will refer to the node to be installed as the target node
In order to work with the yaim installation and configuration tool yaim must be installed on the target node.
In order to download yaim: You now have the directory /opt/lcg/yaim created and the yaim tool installed.
If yaim was already installed, make sure you have the latest version using
> apt-get install lcg-yaim

Site Configuration File

All the configuration values relevant to sites have to be configured in a site configuration file using key-value pairs.
The site configuration file is shared among all the different node types. So we suggest to edit it once and keep it in a safe place in order not to have to edit it again for each installation.
Modifications possibly occurring in the specification of the site configuration file will be published with this document.
An up-to-date example of site configuration file is anyway provided in the file /opt/lcg/yaim/examples/site-info.def


Specification of the Site Configuration File

The general syntax of the file is a sequence of bash-like assignments of variables ($<$variable$>$=$<$value$>$).
"Comment" characters "#" can be used within the file.

WARNING: The Site Configuration File is sourced by the configuration scripts. Therefore there must be no spaces around the equal sign.

Example of wrong configuration:

SITE_NAME = my-site
Example of correct configuration:
SITE_NAME=my-site
A good syntax test for your Site Configuration file (e.g. my-site-info.def) is to try and source it manually, running the command
> source my-site-info.def
and checking that no error messages are produced.

The complete specification of the configurable variables follows.
We strongly recommend that, if you have not clear the meaning of a configuration variable, you just report to us and try and stick to values provided in the examples.
Maybe instead, though you understand the meaning, you are in doubts about the values to be configured into some of the variables above listed.
This may happen, for instance, if you are running a very small site and you are not configuring the whole set of nodes, and therefore you have to refer to some ``public'' service (e.g. RB, BDII ...).
In this case, if you have a reference site, please ask them for indications. Otherwise, send a message to the "LCG-ROLLOUT@cclrclsv.RL.AC.UK" mailing list.
For each variable described below, an application context is outlined. The 'use context' of a variable is the lists of those node types that actually need that particular variable to be set up in order to be correctly configured.

CE_HOST :
Computing Element Hostname. Context: BDII,CE,classic_SE, MON,PX, RB, TAR, UI, WN, torque_client
SE_HOST :
Storage Element Hostname. Context: CE, classic_SE, RB, TAR, UI, WN, torque_client
RB_HOST :
Resource Broker Hostname. Context: CE, BDII, TAR, WN, torque_client
PX_HOST :
Proxy Hostname. Context: CE, BDII, TAR, WN, UI
BDII_HOST :
BDII Hostname. Context: CE, RB, TAR, WN, UI
MON_HOST :
MON Box Hostname. Context: CE, classic_SE, MON, RB, TAR, UI, WN
REG_HOST :
RGMA Registry hostname. Context: CE,classic_SE,MON,RB,TAR,UI,WN
GRID_TRUSTED_BROKERS :
List of the DNs of the Resource Brokers host certificates which are trusted by the Proxy node (ex: /O=Grid/O=CERN/OU=cern.ch/CN=host/testbed013.cern.ch). Context: PX
WN_LIST :
Path to the list of Worker Nodes. The list of Worker Nodes is a file to be created by the Site Administrator, which contains a plain list of the batch nodes. An example of this configuration file is given in /opt/lcg/yaim/examples/wn-list.conf. Context: CE_torque
USERS_CONF :
Path to the list of Linux users (pool accounts) to be created. The list of users is a file to be created by the Site Administrator, which contains a plain list of the users and IDs. An example of this configuration file is given in /opt/lcg/yaim/examples/users.conf. Context: CE, classic_SE, PX, RB, WN
LCG_REPOSITORY :
APT repository with LCG middleware (use the one in the example). Context: All nodes
CA_REPOSITORY :
APT repository with Certification Authorities (use the one in the example). Context: all nodes
CA_WGET :
URL of the repository of the Certification Authorities. The configuration of this value is needed only if the installation is being done without root privileges (e.g. installing a re-locatable distribution in user space). Context: TAR
MYSQL_PASSWORD :
mysql password for the accounting info collector. Context: MON
GRIDICE_SERVER_HOST :
GridIce server host name (monitoring) Usually it is run on the SE node. Context: CE, classic_SE, MON, RB
SITE_EMAIL :
The e-mail address as published by the information system. Context: CE, PX, RB
SITE_NAME :
Your GIIS Context: BDII,CE,classic_SE, MON, PX, RB, UI, WN
SITE_VERSION :
Site middleware version. Context: CE
INSTALL_DATE :
Site installation date (format = YYYYMMDDhhmmssZ) . Context: CE
CE_BATCH_SYS :
. Implementation of site batch system. Available values are ``torque'', ``lsf'', ``pbs'', etc. Context: CE
CE_CPU_MODEL :
Model of the CPU used by the WN (WN specification). This parameter is a string whose domain is not defined yet in the GLUE Schema. The value used for Pentium III is "PIII". Context: CE
CE_CPU_VENDOR :
Vendor of the CPU. used by the WN (WN specification). This parameter is a string whose domain is not defined yet in the GLUE Schema. The value used for Intel is ``intel''. Context: CE
CE_CPU_SPEED :
Clock frequency in Mhz (WN specification). Context: CE
CE_OS :
Operating System name (WN specification). Context: CE
CE_OS_RELEASE :
Operating System release (WN specification). Context: CE
CE_MINPHYSMEM :
RAM size in kblocks (WN specification). Context: CE
CE_MINVIRTMEM :
Virtual Memory size in kblocks (WN specification). Context: CE
CE_SMPSIZE :
Number of cpus in an SMP box (WN specification). Context: CE
CE_SI00 :
Performance index of your fabric in SpecInt 2000 (WN specification). For some examples of Spec values see http://www.specbench.org/osg/cpu2000/results/cint2000.html. Context: CE
CE_SF00 :
Performance index of your fabric in SpecFloat 2000 (WN specification). For some examples of Spec values see http://www.specbench.org/osg/cpu2000/results/cint2000.html. Context: CE
CE_OUTBOUNDIP :
TRUE if outbound connectivity is enabled at your site, FALSE otherwise (WN specification). Context: CE
CE_INBOUNDIP :
TRUE if inbound connectivity is enabled at your site, FALSE otherwise (WN specification). Context: CE
CE_RUNTIMEENV :
List of software tags supported by the site. The list can include VO-specific software tags. In order to assure backward compatibility it should include the entry 'LCG-2', the current middleware version and the list of previous middleware tags. Context: CE
CE_CLOSE_SE :
Here a label-name to identify a SE is defined. Context: CE

For each label-name listed in the CE_CLOSE_SE variable you need to create a set of new variables as follows2:

CE_CLOSE_$<$LABEL-NAME$>$_HOST :
Hostname of the SE . Context: CE
CE_CLOSE_$<$LABEL-NAME$>$_ACCESS_POINT :
mount point of the data partition on the SE. Context: CE
BDII_HTTP_URL :
URL pointing to the BDII configuration file. Context: BDII
BDII_REGIONS :
List of nodes types publishing information on the bdii. Context: CE For each node type listed in the BDII_REGIONS variable you need to create a a new variable as follows:
BDII_$<$REGION$>$_URL :
URL of the information producer. Context: CE.
Examples:
BDII_CE_URL : URL of the CE information producer.
BDII_SE_URL : URL of the SE information producer.

VOS :
List of supported VOs. Context: CE,classic_SE,PX,RB,TAR,torque,UI,WN For each vo listed in the VOS variable you need to create a set of new variables as follows:
VO_$<$VO-NAME$>$_SW_DIR :
Area on the WN for the installation of the experiment software. If on the WNs a predefined shared area has been mounted where VO managers can pre-install software, then these variable should point to this area. If instead there is not a shared area and each job must install the software, then this variables should contain a dot ( . ).Anyway the mounting of shared areas, as well as the local installation of VO software is not managed by yaim and should be handled locally by Site Administrators. Context: CE,UI, WN, TAR
VO_$<$VO-NAME$>$_DEFAULT_SE :
Default SE used by the VO. Context: CE,UI, WN, TAR
VO_$<$VO-NAME$>$_SGM :
ldap directory with VO software managers list. Context: CE,classic_SE,PX, RB
VO_$<$VO-NAME$>$_USERS :
ldap directory with VO users list. Context: CE,classic_SE,PX, RB
VO_$<$VO-NAME$>$_STORAGE_DIR :
Mount point on the Storage Element for the VO. Context: classic_SE
WARNING: VO names must be in capital cases

OUTPUT_STORAGE :
Default Output directory for the jobs. Context: TAR,UI

INSTALL_ROOT :
Installation home of the re-locatable distribution. Context: TAR
JAVA_LOCATION :
Path to Java VM installation. It can be used in order to run a different version of java installed locally

RPM Installation Tool:APT-GET


Middleware Installation

In order to install the node with the desired middleware packages run the command

> /opt/lcg/yaim/scripts/install_node <site-configuration-file> <meta-package>

The complete list of the available meta-packages available with this release is provided in 7.2. (RH7.3) and 7.2.(SL3)

For example, in order to install a CE with Torque, after the configuration of the site-info.def file is done, you have to run:

> /opt/lcg/yaim/scripts/install_node /opt/lcg/yaim/examples/site-info.def lcg-CE-torque

WARNING: The ``bare-middleware'' versions of the WN and CE meta-packages are provided in case you are running a not covered LRMS system.
Consider that if you have chosen to go for the ``bare-middleware'' installation, for instance, of the CE, then you will need to run

> /opt/lcg/yaim/scripts/install_node /opt/lcg/yaim/examples/site-info.def lcg-torque
on the machine, in order to get the installation completed with Torque.

WARNING: There is a known installation conflict between the 'torque-clients' rpm and the 'postfix' mail client (Savannah. bug #5509).
In order to workaround the problem you can either uninstall postfix or remove the file /usr/share/man/man8/qmgr.8.gz from the target node.

meta-packages-RH7.3

In the following table the list of SL3 meta-packages is provided.


Table 1: meta-packages available for RH7.3
Node Type meta-package Name meta-package Description
Worker Node (middleware only) lcg-WN It does not include any LRMS
Worker Node (with Torque client) lcg-WN-torque It includes the 'Torque' LRMS
Computing Element (middleware only) lcg-CE It does not include any LRMS
Computing Element (with Torque) lcg-CE-torque It includes the 'Torque' LRMS
User Interface lcg-UI User Interface
LCG-BDII lcg-LCG-BDII LCG-BDII
MON-Box lcg-MON RGMA-based monitoring system collector server
Proxy lcg-PX Proxy Server
Resource Broker lcg-RB Resource Broker
Classic Storage Element lcg-SECLASSIC Storage Element on local disk
Re-locatable distribution lcg-TAR It can be used to set up a Worker node or a UI
Torque LRMS lcg-torque Torque client and server to be used in combination with the 'bare middleware' version of CE and WN packages



meta-packages-SL3

In the following table the list of SL3 meta-packages is provided.

Table 2: meta-packages available for SL3
Node Type meta-package Name meta-package Description
Worker Node (middleware only) lcg-WN It does not include any LRMS
Worker Node (with Torque client) lcg-WN-torque It includes the 'Torque' LRMS
Computing Element (middleware only) lcg-CE It does not include any LRMS
Computing Element (with Torque) lcg-CE-torque It includes the 'Torque' LRMS
User Interface lcg-UI User Interface
LCG-BDII lcg-LCG-BDII LCG-BDII
MON-Box lcg-MON RGMA-based monitoring system collector server
Proxy lcg-PX Proxy Server
Resource Broker lcg-RB Resource Broker
Classic Storage Element lcg-SECLASSIC Storage Element on local disk
Re-locatable distribution lcg-TAR can be used to set up a Worker node or a UI
Torque LRMS lcg-torque Torque client and server to be used in combination with the 'bare middleware' version of CE and WN packages


Certification Authorities

The installation of the up-to-date version of the Certification Authorities (CA) is automatically done by the Middleware Installation described in 7.
Anyway, as the list and structure of Certification Authorities (CA) accepted by the LCG project can change independently of the middleware releases, the rpm list related to the CAs certificates and URLs has been decoupled from the standard LCG release procedure. You should consult the page

http://markusw.home.cern.ch/markusw/lcg2CAlist.html

in order to ascertain what the version number of the latest set of CA rpms is. In order to upgrade the CA list of your node to the latest version, you can simply run on the node the command:
> apt-get update && apt-get -y install lcg-CA

In order to keep the CA configuration up-to-date on your node we strongly recommend Site Administrators to program a periodic upgrade procedure of the CA on the installed node (e.g. running the above command via a daily cron job).

Host Certificates

CE, SE, PROXY, RB nodes require the host certificate/key files before you start their installation.
Contact your national Certification Authority (CA) to understand how to obtain a host certificate if you do not have one already.
Instruction to obtain a CA list can be found in
http://markusw.home.cern.ch/markusw/lcg2CAlist.html

From the CA list so obtained you should choose a CA close to you.

Once you have obtained a valid certificate, i.e. a file

make sure to place the two files in the target node into the directory

/etc/grid-security

Middleware Configuration

The general procedure to configure the middleware packages that have been installed on the node via the procedure described in 7., is to run the command:

> /opt/lcg/yaim/scripts/<configuration-script> <site-configuration-file>
The complete list of the configuration scripts available with this release is provided in 10.1..

For example, in order to configure the WN with Torque you had installed before, after the configuration of the site-info.def file is done, you have to run:

> /opt/lcg/yaim/scripts/configure_WN_torque /opt/lcg/yaim/examples/site-info.def

In the following paragraph a reference to all the available configuration scripts is given.
There are items in the list marked with an asterisk (*). For these node types there are some particularities in the configuration procedure or extra configuration details to be considered, which are described in a following dedicated section.
For all the unmarked node types, the general configuration procedure is the one above described.


Available Configuration Scripts



Table 3: Available Configuration Scripts
Node Type Script Name Script Description
Worker Node (middleware only) configure_WN It does not configure any LRMS
Worker Node (with Torque client) configure_WN_torque It configures also the 'Torque' LRMS client
Computing Element (middleware only) configure_CE It does not configure any LRMS
Computing Element (with Torque) * configure_CE_torque It configures also the 'Torque' LRMS client and server
User Interface configure_UI User Interface
LCG-BDII configure_BDII LCG-BDII
MON-Box configure_MON RGMA-based monitoring system collector server
Proxy configure_PX Proxy Server
Resource Broker configure_RB Resource Broker
Classic Storage Element configure_classic_SE Storage Element on local disk
Re-locatable distribution * configure_TAR It can be used to set up a Worker Node or a UI (see 11.2. for details)


Installing multiple node types on one machine

You can use yaim to install more than one node type on a single machine. In this case, you should install all the relevant software first, and then run the configure scripts. For example, to install a combined RB and BDII, you should do the following;

> /opt/lcg/yaim/scripts/install_node /opt/lcg/yaim/examples/site-info.def lcg-RB
> /opt/lcg/yaim/scripts/install_node /opt/lcg/yaim/examples/site-info.def lcg-LCG-BDII
> /opt/lcg/yaim/scripts/configure_RB /opt/lcg/yaim/examples/site-info.def
> /opt/lcg/yaim/scripts/configure_BDII /opt/lcg/yaim/examples/site-info.def

Note that one combination known not to work is the CE/RB, due to a conflict between the GridFTP servers.

Node-specific extra configuration steps

In this section we list configuration steps actually needed to complete the configuration of the desired node but not supported by the automatic configuration scripts.
If a given node does not appear in that section it means that its configuration is complete


CE-torque

WARNING: in the CE configuration context (and also in the 'torque' LRMS one), a file with a a list of managed nodes needs to be compiled. An example of this configuration file is given in /opt/lcg/yaim/examples/wn-list.conf
Then the file path needs to be pointed by the variable WN_LIST in the Site Configuration File (see 5.1.).

The Maui scheduler configuration provided with the script is currently very basic.
More advanced configuration examples, to be implemented manually by Site Administrators can be found in [5]


The relocatable distribution

Introduction

We are now supplying a tarred distribution of the middleware which can be used to install a UI or a WN. You can untar the distribution somewhere on a local disk, or replicate it across a number of nodes via a network share. You can also use this distribution to install a UI without root privileges.

Once you have the middleware directory available, you must edit the site-info.def file as usual, putting the location of the middleware into the variable INSTALL_ROOT.

If you are sharing the distribution to a number of nodes, commonly WNs, then they should all mount the tree at INSTALL_ROOT. You should configure the middleware on one node (remember you'll need to mount with appropriate privileges) and then it should work for all the others if you set up your batch system and the CA certificates in the usual way. If you'd rather have the CAs on your share, the yaim function install_certs_userland may be of interest. You may want to mount your share ro after the configuration has been done.

What happens next depends on whether you are root or not...

To install a UI or WN as root

Next you must install the dependency software, and run the config_TAR script, adding the type of node as an argument;

> /opt/lcg/yaim/scripts/install_node <site-configuration-file> lcg-TAR

> /opt/lcg/yaim/scripts/configure_TAR /opt/lcg/yaim/examples/site-info.def WN|UI

Note that the script will not configure any LRMS. If you're configuring torque for the first time, you may find the config_users and config_torque_client yaim functions useful.

To install a UI as a non-root user

NOTE - at time of writing, this is not supported in the distributed yaim rpm. You'll have to check out the latest version from CERN's deployment CVS - http://lcgdeploy.cvs.cern.ch/cgi-bin/lcgdeploy.cgi/lcg-scripts/yaim/.

The relocatable tarball has some dependencies which would normally be installed as rpms by root. We've made this software available as a second tar file which you must download and untar under $EDG_LOCATION. This means that if you untarred the main distribution under /home/user/UI, you must untar the supplementary files under /home/user/UI/edg.

The middleware also requires java. If this is not available on your machine, download it from sun (1.4.2 is recommended - http://java.sun.com/j2se/1.4.2/download.html) and make sure you set the JAVA_LOCATION variable in your site-info.def. You'll probably want to alter the OUTPUT_STORAGE variable there too, as it's set to /tmp/jobOutput by default and it may be better pointing at your home directory somewhere.

Once the software is all installed, you should run

> /opt/lcg/yaim/scripts/configure_TAR /opt/lcg/yaim/examples/site-info.def UI
to configure it.

Finally, you'll have to set up some way of sourcing the environment necessary to run the grid software. A script will be available under $INSTALL_ROOT/etc/profile.d for this purpose. Source grid_env.sh or grid_env.csh depending upon your choice of shell.

Installing a UI this way puts all the CA certificates under $INSTALL_ROOT/etc/grid-security and adds a user cron job to download the crls. However, please note that you'll need to keep the CA certificates up to date yourself.

Further information

In [3] there is more information on using this form of the distribution, including a description of what the configure script does. You should check this reference if you'd like to customise the relocatable distribution.

This distribution is used at CERN to make its lxplus system available as a UI. You can take a look at the docs for this too [4].

Getting the software

You can download the tar file for each operating system from

http://grid-deployment.web.cern.ch/grid-deployment/download/relocatable/LCG-2_3_0-rh73.tar.gz

http://grid-deployment.web.cern.ch/grid-deployment/download/relocatable/LCG-2_3_0-sl3.tar.gz

You can download supplementary tar files for the userland installation from

http://grid-deployment.web.cern.ch/grid-deployment/download/relocatable/LCG-2_3_0-userdeps-rh73.tar.gz

http://grid-deployment.web.cern.ch/grid-deployment/download/relocatable/LCG-2_3_0-userdeps-sl3.tar.gz

Firewalls

No automatic firewall configuration is provided by this version of the configuration scripts.
If your LCG nodes are behind a firewall, you will have to ask your network manager to open a few "holes" to allow external access to some LCG service nodes.
A complete map of which port has to be accessible for each service node can be found at the URL
http://lcgdeploy.cvs.cern.ch/cgi-bin/lcgdeploy.cgi/lcg2/docs/lcg-port-table.pdf .

The mentioned reference is strongly ``component-oriented'' and it might result difficult to apply for Site Administrator not very confident with which particular sub-systems are actually running on a given node type.
For further information about firewall configuration mapped on the different node types see the dedicated guide in [1]

Contacts

For questions and suggestions dealing with this document please contact the address
$<$support-lcg-manual-install@cern.ch$>$

Bibliography

1
G. Diez-Andino, K. Oliver, A. Retico, and A. Usai.
Lcg configuration reference, 2004.
../../../../../../gis/lcg-GCR/index.html.

2
L. Field and L. Poncet.
The new manual install, 2004.
http://agenda.cern.ch/askArchive.php?base=agenda&categ=a044377&id=a044377s11t3/transparencies
Presentation given at the LCG Workshop on Operational Issues, Cern, Nov 2.

3
O. Keeble.
Lcg 2 tar distribution, 2004.
http://grid-deployment.web.cern.ch/grid-deployment/documentation/Tar-Dist-Use/.

4
O. Keeble.
Using lxplus as a ui, 2004.
http://www.cern.ch/grid-deployment/documentation/UI-lxplus/.

5
S. Lemaitre and S. Traylen.
Maui-cookbook, 2004.
http://grid-deployment.web.cern.ch/grid-deployment/documentation/Maui-Cookbook/.


Change History



Table 4: Change History
version date description
v2.3.0-2 10/Jan/05 5.1.: CA_WGET variable added in site configuration file.
v2.3.0-3 2/Feb/05 Bibliography: Link to Generic Configuration Reference changed.
`` `` 11.1., 5.1.: Details added on WN and users lists.
`` `` 10.1.: script ``configure_torque''. no more available: removed from the list.
v2.3.0-4 16/Feb/05 Configure apt to find your OS rpms.
v2.3.0-5 22/Feb/05 Remove apt prefs stuff, mention multiple nodes on one box.
v2.3.0-6 03/Mar/05 Better lcg-CA update advice.


About this document ...

LCG Generic Installation & Configuration Guide

This document was generated using the LaTeX2HTML translator Version 2002 (1.62)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split 0 -html_version 4.0 -no_navigation -address 'GRID deployment' LCG2-Manual-Install.drv_html

The translation was initiated by Oliver KEEBLE on 2005-03-02


Footnotes

... manually1
A technical reference of the configuration actions done by the yaim scripts, suitable to be used to learn more about LCG configuration can be found in [1]
... follows2
If you are running only a SE just stick to the definition in the example for the CE_CLOSE_CE variable
... installed)3
The apt tool could be already installed according to the distribution of OS in use at your site


GRID deployment