Layout and Customization of gLite Templates

Table of Contents

1. Layout Description
2. Template Customization
   1. Allocation of Service Accounts
   2. Accepted CAs
   3. DPM Configuration
   4. LFC Configuration

This page contains a description of the layout of templates for gLite provided by QWG and how the site customization should be integrated. See page on template framework for more details on template framework structure and site customization.

Layout Description

Layout of gLite templates is based on PAN namespaces. This PAN feature brings an improved manageability. Among advantages, it allows :

• More structured layout
• Easier guess of where a template is located as its relative path is part of its name
• Support for nodes running different versions of the gLite in the same cluster (not yet implemented)

A part of the effort to ease management of templates, templates names are now organized based on a per service view. That means that there is one directory for each service, with all the templates needed to configure the service contained in this directory (RPMs list, configuration information...). Inside each service directory, template names are now quite standardized. Main templates, available in every service where it is relevant, are :

• rpms.tpl : contains all the RPMs required to run the service
• service.tpl : contains all middleware components that need to be configured to run a specific service. This is mainly used for high level services, like CE, WN, BDII... This doesn't include any OS related information.
• config.tpl : contains all the configuration information required to configure the service (but not the included services)

Some services are made of several sub-components using different configuration information but providing no specific RPMs (e.g. gridice). In this case, config.tpl is replaced by one template for each sub-component, named after the sub-component name. If the sub-component requires some RPMs, a sub-directory is created (e.g. nfs/client and nfs/server) and if they share common configuration information, the template for this is placed in the parent directory (e.g. nfs) and the template is generally named base.tpl.

gLite services templates are organized in 3 main hierarchies :

• glite : one directory per gLite high-level service
• lcg : one directory per LCG high-level service (in fact LCG CE and LCG RB) that are still part of gLite.
• common : one directory per lower-level service used to configure high-level service.

In the common area, currently almost everything is coming from LCG configuration and is maintained manually. There is one exception, common/glite : this directory contains templates generated (by script) from XML files provided in gLite config RPMs. The generated templates conform to the service oriented layout, with 3 templates per service :

• config.tpl : the entry point
• schema.tpl : defines all the supported PAN resources/properties for this component
• defaults.tpl : defines a sensible default value for each property, according to the content of XML file for the service.

There are a few exception to the service oriented layout of templates :

• users : to improve consistency in account IDs allocation, all the account related templates (user/group creation) arenow in one directory, common/users, and is no longer part of service information. There is one template per user/group and the name of this template is generally the name of the user created. Some of them are empty : they are just placeholders to allow a site to define this accout.
• common/security : this directory contains all the templates related to security configuration, mainly GSI (host certificates checking, accepted CAs, CRL management...)

In addition, gLite templates include the following hierarchies, very close to what existed in LCG2 templates :

• machine-types : one template per machine type. Intended to be included in a machine profile.
• vo : all the VO related information (not yet based on namespaces).
• standard : version of some critical standard templates.
• components : description of NCM components related to gLite services used in other gLite templates (doesn't include OS related components)
• defaults : templates providing sensible default values, mainly `site.tpl' for default site parameter values.
• repository : template defining RPM repositories where gLite RPMs are located. Need to be edited to match site repository names..

Template Customization

Despite the change in template layout, LCG2 template customization is still valid for gLite3. Refer to this description, except for components with an explicit description provided here.

Allocation of Service Accounts

Some services allow to define a specific account to be used to run the service. In this case, there is one template for each of these accounts in common/users. The name of the template generally matches the user account created or, when the template is empty, the name of the service.

A site can redefine account names or characteristics (uid, home directory...). To do this, you should not edit directly the standard templates as the changes will be lost in the next version of the template (or you will have to redo them by hand). You should create a users directory somewhere in your site or cluster hierarchy (e.g. under the site directory, not directly at the same level else it will not work without adjusting cluster.build.properties) and put your customized version of the template here.

Note : don't change the name of the template, even if you change the name of the account used (else you'll need to modify standard templates needing this user).

Accepted CAs

There is one template defining all the accepted CAs. We generally produced a new one each time there is a new release of the list of CAs officially accepted by EGEE. If you need to adjust it, create a site or cluster specific copy of common/security/cas.tpl in a directory common/security.

DPM Configuration

LFC Configuration

LFC related standard templates require a site template to describe the service site configuration. The variable LFC_CONFIG_SITE must contain the name of this template.

Normally the only thing really required in this site specific template is the password for LFC user (by default lfc) and the MySQL administrator (by default root). There a no default value provided for these password. Look at standard LFC templates/trunk/glite-3.0.0/glite/lfc/config configuration template for the syntax.

If you want to use Oracle version of LFC server define the following variable in your machine profile :

variable LFC_SERVER_MYSQL = false;

LFC templates allow a LFC server to act as a central LFC server (registered in BDII) for somes VOS and as a local LFC server for the others. This are 2 variables controlling what is registered in the BDII :

• LFC_CENTRAL_VOS : list of VOs for which the LFC server must be registered in BDII as a central server. Default is an empty list.
• LFC_LOCAL_VOS : list all VOs for which the server must be registered in BDII as a local server. Default to all supported VOs (VOSvariable). If a VO is in both lists, it is removed from LFC_LOCAL_VOS. If you don't want this server to be registered as a local server for any VO, even if configured on this node (present in VOS list), you must define this variable as an empty list :

  variable LFC_LOCAL_VOS = list();
  

VOs listed in both lists must be present in VOS variable. These 2 variables have no impact on GSI (security) configuration and don't control access to the server.