Context Navigation

TemplateCustomization

Timestamp:: May 18, 2010, 1:10:20 PM (15 years ago)
Author:: /C=UK/O=eScience/OU=CLRC/L=RAL/CN=richard hellier
Comment:: Minor typos/changes

Legend:

: Unmodified
: Added
: Removed
: Modified

Doc/gLite/TemplateCustomization

-              v172
+              v173
 All site parameters related to QWG middleware are supposed to be declared in one template `site/glite/config.tpl` (or any other site-specific templates it may include). To start a new site, import the site parameter template [source:templates/trunk/sites/example/site/site/glite/config.tpl example]. The list of all available variables with their description and their default value can be consulted in template source:templates/trunk/grid/glite-3.1/defaults/glite.tpl. '''This template is a critical part of standard templates and should not be modified or duplicated'''.
 ''Note : Information in this page may document features or configuration options not present in the current release. These information are related to changes and improvement that will be available in next release and are already present in the [source:templates/branches/gLite-3.1 current development branch]. If you are urgently requiring these features, [wiki:Download/QWGTemplates use content] of this branch.''
 Documentation in this page is based on [source:templates/trunk/grid/glite-3.1 QWG templates for gLite 3.1]. Most of the documentation also applies to deprecated [source:templates/trunk/grid/glite-3.0.0 QWG templates for gLite 3.0], except when explicitly stated or for features supported only by 3.1 serie.
+''Note : Information in this page may document features or configuration options not present in the current release. These information are related to changes and improvement that will be available in next release and are already present in the [source:templates/branches/gLite-3.1 current development branch]. If you urgently require these features, [wiki:Download/QWGTemplates use content] of this branch.''
+Documentation in this page is based on [source:templates/trunk/grid/glite-3.1 QWG templates for gLite 3.1]. Most of the documentation also applies to deprecated [source:templates/trunk/grid/glite-3.0.0 QWG templates for gLite 3.0], except when explicitly stated or for features supported only by 3.1 series.
 ''Note: this documentation often makes reference to a template called `site/glite/config.tpl`. This template used to be called `pro_lcg2_config_site.tpl` in the past. Both names are valid and taken into account by current templates, even though the namespaced name is the recommended one.''
 …
 To configure a specific machine with gLite middleware, you just need to include the appropriate machine type template into the machine profile, after specifying a template containing the specific configuration for this particular machine with the variable {{{xxx_CONFIG_SITE}}} (look in the template for the exact name of the variable).
 Here an example for configuring a Torque based CE :
+Here is an example for configuring a Torque-based CE :
 {{{
 …
 In this example, {{{CE_CONFIG_SITE}}} specify the name of a template defining the Torque configuration.
 All the machine types share a common basic configuration, described in template `machine-types/base.tpl`. This template allows to add site-specific configuration to this common base configuration (e.g. configuration of a monitoring agent). This is done by defining variable {{{GLITE_BASE_CONFIG_SITE}}} to a template containing the site-specific configuration to be added to the common configuration (at the end of the common configuration). This variable can be defined, for example, in template {{{pro_site_cluster_info.tpl}}}.
+All the machine types share a common basic configuration, described in template `machine-types/base.tpl`. This template allows you to add site-specific configuration to this common base configuration (e.g. configuration of a monitoring agent). This is done by defining the variable {{{GLITE_BASE_CONFIG_SITE}}} to a template containing the site-specific configuration to be added to the common configuration (at the end of the common configuration). This variable can be defined, for example, in the template {{{pro_site_cluster_info.tpl}}}.
 The following sections describe specific variables that can be used with each machine type. The machine type template to include is specified at the beginning of the section as ''Base template''. In addition, to get more details, you can look at [source:templates/clusters/example-3.1/profiles examples].
 …
 === Creating a New Machine Type ===
 All gLite machines types use a common base configuration, described in [source:templates/trunk/grid/glite-3.1/machine-types/base.tpl machine-types/base.tpl]. This templates is responsible in particular to do the base OS configuration, VO configuration and NFS configuration.
 When creating a new machine type derived from this gLite base machine types, it is necessary, at '''the very end''' of the new machine type, to include the gLite update and postconfig templates, using the following PAN statement:
+All gLite machines types use a common base configuration, described in [source:templates/trunk/grid/glite-3.1/machine-types/base.tpl machine-types/base.tpl]. This template is responsible in particular to do the base OS configuration, VO configuration and NFS configuration.
+When creating a new machine type derived from this gLite base machine type, it is necessary, at '''the very end''' of the new machine type, to include the gLite update and postconfig templates, using the following PAN statement:
 {{{
 # gLite updates
 …
 ''Note : `dteam` and `ops` are mandatory VOs for EGEE sites.''
 As an alternative to listing explicitly all the VOs supported on a node, it is possible to define variable `VOS` as the string `ALL` (instead of a list). In this case, all VOs with parameters available in the configuration (normally all the VOs registered in the [http://www.gridops.org CIC portal]) are configured. This specific value should normally be restricted to UIs where there are no VO accounts created. Its main usage is to let user on a UI act as a member of any VO they may be registered in. On a gsissh-enabled UI, it is advisable to restrict the VOs allowed to connect to the UI with `gsissh` to a limited number of VOs when `VOS='ALL'`. See section on UI configuration for more details.
+As an alternative to listing explicitly all the VOs supported on a node, it is possible to define variable `VOS` as the string `ALL` (instead of a list). In this case, all VOs with parameters available in the configuration (normally all the VOs registered in the [http://www.gridops.org CIC portal]) are configured. This specific value should normally be restricted to UIs where there are no VO accounts created. Its main usage is to let a user on a UI act as a member of any VO they may be registered in. On a gsissh-enabled UI, it is advisable to restrict the VOs allowed to connect to the UI with `gsissh` to a limited number of VOs when `VOS='ALL'`. See the section on UI configuration for more details.
 For each VO listed in `VOS`, there must be a template defining the VO parameters in `vo/params` or an entry in `vo/site/aliases`. The template name in `vo/params` must be the VO full name even though a VO alias name is used in `VOS`. If the VO to be added has no template to define its parameters, refer to the next section about adding a new VO.
 ''Note: VO alias names are alternative names for VOs locally defined. Unlike, VO names which are guaranteed to be unique, VO aliases may clash with another alias or full name. They must be used mainly to maintain backward compatibility in existing configurations where a name other than the VO full name was used. The use of VO alias is '''strongly''' discouraged for a new configuration or new VOs added to an existing configuration.''
+''Note: VO alias names are alternative names for VOs locally defined. Unlike VO names which are guaranteed to be unique, VO aliases may clash with another alias or full name. They must be used mainly to maintain backward compatibility in existing configurations where a name other than the VO full name was used. The use of VO alias is '''strongly''' discouraged for a new configuration or new VOs added to an existing configuration.''
 For some specific purposes, it is possible to execute a site-specific template just before starting the VO configuration, after the site paramaters have been read and the OS configuration has been done. Use variable `NODE_VO_CONFIG` to specify the name of the template.
+For some specific purposes, it is possible to execute a site-specific template just before starting the VO configuration, after the site parameters have been read and the OS configuration has been done. Use variable `NODE_VO_CONFIG` to specify the name of the template.
 …
 Templates related to VO configuration handle everything related to VO configuration on a specific node, including creation of VO accounts (pool accounts, SW manager...). See below for the parameters related to account creation.
 By default, the VO accounts are created locked to prevent their interactive use. There is one exception : if variable `GSISSH_SERVER_ENABLED` equals `true`, these accounts are automatically unlocked. This happens mainly on [wiki:Doc/gLite/TemplateCustomization#UI UI] and [wiki:Doc/gLite/TemplateCustomization#VOBOX VOBOX].
+By default, the VO accounts are created locked to prevent their interactive use. There is one exception: if the variable `GSISSH_SERVER_ENABLED` equals `true`, these accounts are automatically unlocked. This happens mainly on [wiki:Doc/gLite/TemplateCustomization#UI UI] and [wiki:Doc/gLite/TemplateCustomization#VOBOX VOBOX].
 …
 === Site-Specific Defaults for VO Parameters === #VODefaultParams
 It is possible to define site-specific defaults for VOs that override standard default. This must be done by defining entry `DEFAULT` in  nlist variable `VOS_SITE_PARAMS`. This entry is used to define paramaters that will apply to all VOs if they are not defined explicitly in VO parameters.
+It is possible to define site-specific defaults for VOs that override standard default. This must be done by defining entry `DEFAULT` in  nlist variable `VOS_SITE_PARAMS`. This entry is used to define parameters that will apply to all VOs if they are not defined explicitly in VO parameters.
 Each entry value must be the name of a structure template or a nlist defining any of these properties :
 …
  * `VOMS_CRON_EMAIL`: user to notify in case of problems during cron jobs. Default: `root@localhost`.
 In addition to configuring the previous variable, it is generally necessary to install the certificate of the initial administrator of the VO. This certificate is passed in paramater `adminCert` in VO parameters (`VOMS_VOS`). This is typically done with Quattor configuration module `filecopy` in the site-specific configuration of the VOMS server. A typical sequence to do this is:
+In addition to configuring the previous variable, it is generally necessary to install the certificate of the initial administrator of the VO. This certificate is passed in parameter `adminCert` in VO parameters (`VOMS_VOS`). This is typically done with Quattor configuration module `filecopy` in the site-specific configuration of the VOMS server. A typical sequence to do this is:
 {{{
 include { 'components/filecopy/config' };