LCG Generic Installation and Configuration

Document identifier:	LCG-GIS-MI
Date:	4 March 2005
Author:	Guillermo Diez-Andino, Laurence Field, Oliver Keeble, Antonio Retico, Alessandro Usai
Version:	v2.3.1-1

Abstract: LCG Generic Installation Guide

Contents

• Introduction to Manual Installation and Configuration
• OS Installation
• Node Synchronization
  • NTP Software Installation
  • NTP Configuration
  
  
• Configuration Tool: YAIM
• Site Configuration File
  • Specification of the Site Configuration File
  
  
• RPM Installation Tool:APT-GET
• Middleware Installation
  • meta-packages-RH7.3
  • meta-packages-SL3
  
  
• Certification Authorities
• Host Certificates
• Middleware Configuration
  • Available Configuration Scripts
  • Installing multiple node types on one machine
  
  
• Node-specific extra configuration steps
  • CE-torque
  • The relocatable distribution
  
  
• Firewalls
• Contacts
• Bibliography
• Change History
• About this document ...

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.

• Scientific Linux 3.0
• Linux Red Hat 7.3

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 manually¹.

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:

• Worker Node (Torque)
• User Interface
• Computing Element (Torque)
• Classical Storage Element
• Resource Broker
• LCG-BDII
• Proxy Server
• Mon Box

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

The ``deprecated'' node types are:

• Worker Node (PBS)
• Computing Element (PBS)

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:

• ntp
• libcap
• libcap-devel

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-4.1.1-1

  http://grid-deployment.web.cern.ch/grid-deployment/download/RpmDir/release/ntp-4.1.1-1.i386.rpm
  

• libcap-devel-1.10-8

   
  http://grid-deployment.web.cern.ch/grid-deployment/download/RpmDir/release/libcap-devel-1.10-8.i386.rpm
  

• libcap-1.10-8

   
  http://grid-deployment.web.cern.ch/grid-deployment/download/RpmDir/release/libcap-1.10-8.i386.rpm
  

NTP Configuration

• Configure the file /etc/ntp.conf by adding the lines dealing with your time server configuration such as, for instance:

   restrict <time_server_IP_address> mask 255.255.255.255 nomodify notrap noquery
   server <time_server_name>
  

  Additional time servers can be added for better performance results. For each server, the hostname and IP address are required. Then, for each time-server you are using, add a couple of lines similar to the ones shown above into the file /etc/ntp.conf.

• Edit the file /etc/ntp/step-tickers adding a list of your time server(s) hostname(s), as in the following example:

  137.138.16.69
  137.138.17.69
  

• If you are running a kernel firewall, you will have to allow inbound communication on the NTP port.
  If you are using ipchains, you can do this by adding the following to /etc/sysconfig/ipchains

  -A input -s <NTP-serverIP-1> -d 0/0 123 -p udp -j ACCEPT
  -A input -s <NTP-serverIP-2> -d 0/0 123 -p udp -j ACCEPT
  

  If you are using iptables, you can add the following to /etc/sysconfig/iptables

  -A INPUT -s <NTP-serverIP-1> -p udp --dport 123 -j ACCEPT 
  -A INPUT -s <NTP-serverIP-2> udp --dport 123 -j ACCEPT
  

  Remember that, in the provided examples, rules are parsed in order, so ensure that there are no matching REJECT lines preceding those that you add. You can then reload the firewall

  > /etc/init.d/ipchains restart
  

• Activate the ntpd service with the following commands:

  > ntpdate <your ntp server name>
  > service ntpd start
  > chkconfig ntpd on
  

• You can check ntpd's status by running the following command

  > ntpq -p
  

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:

• Log to target node as 'root'
• Install yaim
  • find the latest version at http://www.cern.ch/grid-deployment/gis/yaim/
  • download it using wget

    > wget http://www.cern.ch/grid-deployment/gis/yaim/lcg-yaim-x.x.x-x.noarch.rpm
    

  • install using

    > rpm -ivh lcg-yaim-x.x.x-x.noarch.rpm
    

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 follows²:

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

• Download the apt tool (If it is not already installed) ³
  • apt rpm for Scientific Linux

    > wget ftp://ftp.scientificlinux.org/linux/scientific/303/i386/SL/RPMS/apt-0.5.15cnc6-4.SL.i386.rpm
    

  • apt rpm for RH7.3

    > wget -nc http://ftp.freshrpms.net/pub/freshrpms/redhat/7.3/apt/apt-0.5.5cnc5-fr0.rh73.2.i386.rpm
    

• Install apt
  • Scientific Linux

    > rpm -ivh apt-0.5.15cnc6-4.SL.i386.rpm
    

  • Red Hat

    > rpm -ivh apt-0.5.5cnc5-fr0.rh73.2.i386.rpm
    

    Please note that for the dependencies of the middleware to be met, you'll have to make sure that apt can find and download your OS rpms. This typically means you'll have to install an rpm called 'apt-sourceslist', or else create an appropriate file in your /etc/apt/sources.list.d directory.

• Configure apt
  In order to perform the Middleware and CA installation with the methods described in this guide, you just need to configure in the Site Configuration File (see 5.1.) the variable
  • LCG_REPOSITORY
  • CA_REPOSITORY
  as follows:
  

  RH7.3:

  LCG_REPOSITORY="rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG-2_3_1/en/i386 lcg_rh73"
  

  SL3:

  LCG_REPOSITORY="rpm http://grid-deployment.web.cern.ch/grid-deployment/gis apt/LCG-2_3_1/en/i386 lcg_sl3"
  

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

• hostcert.pem
  containing the machine public key and a file
• hostkey.pem
  containing the machine private key

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_1-rh73.tar.gz

http://grid-deployment.web.cern.ch/grid-deployment/download/relocatable/LCG-2_3_1-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_1-userdeps-rh73.tar.gz

http://grid-deployment.web.cern.ch/grid-deployment/download/relocatable/LCG-2_3_1-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.
v2.3.1-1	03/Mar/05	LCG-2_3_1 locations

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-04

Footnotes

... manually¹

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]

... follows²

If you are running only a SE just stick to the definition in the example for the CE_CLOSE_CE variable

... installed)³

The apt tool could be already installed according to the distribution of OS in use at your site