Changes between Version 169 and Version 170 of Doc/gLite/TemplateCustomization


Ignore:
Timestamp:
May 7, 2010, 5:24:43 PM (15 years ago)
Author:
/C=UK/O=eScience/OU=CLRC/L=RAL/CN=richard hellier
Comment:

Minor typos and consistency changes

Legend:

Unmodified
Added
Removed
Modified

  • Doc/gLite/TemplateCustomization

    v169 v170  
    4444In this example, {{{CE_CONFIG_SITE}}} specify the name of a template defining the Torque configuration.
    4545
    46 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}}}.
     46All 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}}}.
    4747
    4848The 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].
    … …  
    135135
    136136
    137 === Site Specific Defaults for VO Parameters === #VODefaultParams
     137=== Site-Specific Defaults for VO Parameters === #VODefaultParams
    138138
    139139It 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.
    … …  
    157157=== Overriding default VO Parameters === #VOSpecificParams
    158158
    159 In addition to define [#VODefaultParams default values] for VO parameters, it is possible to override default VO parameters, as specified in templates located in [source:trunk/grid/glite-3.2/vo/params vo/params], with site specific values. This is possible to do it on a per-VO basis or for all VOs configured on a machine. This is done using the same variable (nlist) as for [#VODefaultParams default parameters], `VOS_SITE_PARAMS`. To override default parameters for one specific VO, the key must be the VO name, as used in `VOS` variable. To override default parameters for all configured VOs, use special entry `LOCAL`.
     159In addition to define [#VODefaultParams default values] for VO parameters, it is possible to override default VO parameters, as specified in templates located in [source:trunk/grid/glite-3.2/vo/params vo/params], with site-specific values. This is possible to do it on a per-VO basis or for all VOs configured on a machine. This is done using the same variable (nlist) as for [#VODefaultParams default parameters], `VOS_SITE_PARAMS`. To override default parameters for one specific VO, the key must be the VO name, as used in `VOS` variable. To override default parameters for all configured VOs, use special entry `LOCAL`.
    160160
    161161''Note: if a template `vo/site/VONAME` can be located, it'll be loaded even though there is no explicit entry for the VO into variable `VOS_SITE_PARAMS`.''
    … …  
    165165'Note: some properties are invalid in the context of the `LOCAL` entry (as with `DEFAULT`), in particular: `account_prefix`, `base_uid`, `gid`, `name`, `voms_servers`, `voms_roles`.''
    166166
    167 For example, to define a site specific WMS for VO Alice, create a template `vo/site/alice.tpl` in your site directory like :
     167For example, to define a site-specific WMS for VO Alice, create a template `vo/site/alice.tpl` in your site directory like :
    168168{{{
    169169structure template vo/site/alice;
    … …  
    221221'''Note: the procedure to create a new VO definition here is for very specific cases. The normal procedure is to register it properly on [http://www.gridops.org CIC Portal] and generate the configuration information from the portal with `ant update.vo.config` (when using SCDB).'''
    222222
    223 Adding a new VO involved the creation of a template defining VO parameters. This template name must be the name you use to refer to the VO in rest of the configuration but is not required to be the real VO name (can be an alias used in the configuration). This template must be located in directory `vo/params`, in one of your cluster or site specific hierarchy of templates or in gLite templates.
     223Adding a new VO involved the creation of a template defining VO parameters. This template name must be the name you use to refer to the VO in rest of the configuration but is not required to be the real VO name (can be an alias used in the configuration). This template must be located in directory `vo/params`, in one of your cluster- or site-specific hierarchy of templates or in gLite templates.
    224224
    225225''Note : if you create a template for a new VO, be sure to commit it to the QWG repository if you have write access to it, or to send it to QWG developpers. There is normally no reason for a VO definition not to be generally available.''
    … …  
    252252=== Default Services for a VO ===
    253253
    254 Location of standard services to use with a specific VO can be defined either in the VO parameters or in the site specific parameters for a VO. Services that can be configured are :
     254Location of standard services to use with a specific VO can be defined either in the VO parameters or in the site-specific parameters for a VO. Services that can be configured are :
    255255
    256256 * `proxy` : name of the proxy server used by the VO. No default, optional.
    … …  
    266266 * `wms_proxies` : endpoint URI of WMProxy used by the VO. Can be a list or a single value. No default.
    267267
    268 === VO Specific Areas ===
    269 
    270 There are a couple of variables available to customize VO specific areas (software area, VO accounts home directories...) :
     268=== VO-Specific Areas ===
     269
     270There are a couple of variables available to customize VO-specific areas (software area, VO accounts home directories...) :
    271271
    272272 * `VO_SW_AREAS` : a nlist with one entry per VO (key is the VO name as used in `VOS` variable). The value is a directory to use for the VO software area. Be sure to list this directory or its parent in `WN_SHARED_AREAS` if you want to use a shared filesystem for this area (this is highly recommended). Directories listed in this variable will be created with the appropriate permissions (`0755` for VO group). In addition to per VO entries, entry `DEFAULT` may be used to create one SW area for each configured VO on the current node : in this case the value is the parent directory for SW areas and the per VO directory name is the VO name (default) or the SW manager userid if variable `VO_SW_AREAS_USE_SWMGR` is defined to `true`.
    … …  
    286286
    287287In addition you can execute actions specific to the local machine by defining the following variable (mainly used to define a VO list specific to a node by assigning a non default value to `VOS` variable) :
    288  * `NODE_VO_CONFIG` (string) : site specific template that must be included before actually doing VO intialization. Allow for specific VO modification to default VO configuration. Default : none.
     288 * `NODE_VO_CONFIG` (string) : site-specific template that must be included before actually doing VO intialization. Allow for specific VO modification to default VO configuration. Default : none.
    289289
    290290'''Note : before modifying default VO configuration for a specific machine, be sure what you want to do is valid. Misconfiguring VO can have dramatic effects on service availability.'''
    … …  
    313313== Accepted CAs ==
    314314
    315 There is one template defining all the accepted CAs. This template is produced by people in charge of producing new releases 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`.
     315There is one template defining all the accepted CAs. This template is produced by people in charge of producing new releases 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`.
    316316
    317317If you need to update this template, refer to the standard [wiki:Development/Templates/Generated#TrustedCAsTemplate procedure] to do it.
    … …  
    349349== Shared File Systems ==
    350350
    351 It is recommended to use a shared file system mounted (at least) on CE and WNs for VO software areas. It is also sometimes convenient to use a shared file system for VO pool accounts (this is more or less a requirement to run MPI jobs). Currently, QWG templates support the use of NFS or non-NFS shared file systems but only the NFS service is configured by the templates. For other distributed file system (AFS, LUSTRE, GPFS...), you must add the necessary configuration to the site specific configuration.
     351It is recommended to use a shared file system mounted (at least) on CE and WNs for VO software areas. It is also sometimes convenient to use a shared file system for VO pool accounts (this is more or less a requirement to run MPI jobs). Currently, QWG templates support the use of NFS or non-NFS shared file systems but only the NFS service is configured by the templates. For other distributed file system (AFS, LUSTRE, GPFS...), you must add the necessary configuration to the site-specific configuration.
    352352
    353353Configuration is done by the following variables :
    … …  
    461461`glite_repos_prefix` can be customized without editing the standard template, defining `REPOSITORY_GLITE_PREFIX` variable. If not explicitly defined, it defaults to `glite_3_0_0` for gLite 3.0 and `glite_3_1` for gLite 3.1.
    462462
    463 All required repositories must have an associated template whose name is the same as the repository, in site or cluster specific templates. Optional repository is ignored if its associated template is not present. Each template describe the content of the repositories. When using [wiki:Doc/SCDB/SWRepositories SCDB], these templates are maintained with command `ant update.rep.templates`.
     463All required repositories must have an associated template whose name is the same as the repository, in site- or cluster-specific templates. Optional repository is ignored if its associated template is not present. Each template describe the content of the repositories. When using [wiki:Doc/SCDB/SWRepositories SCDB], these templates are maintained with command `ant update.rep.templates`.
    464464
    465465''Note : it is not required to use this structure and you can edit this template to match your local conventions, if different. When upgrading QWG templates, be sure to revert changes to this template.''
    … …  
    554554 * `VO_HOMES`: a nlist defining parent of home directories for all the VO accounts. For each entry, the key is the VO name as defined in variable `VOS` (it may be a VO alias name) and the value is the parent directory for the corresponding accounts (pool accounts and other accounts associated with roles). A special entry, `DEFAULT` may be used to define home directory parent for all the VOs without an explicit entry.
    555555
    556 Wen supporting multiple VOs, the number of accounts can be very large (several thousands). This may lead to performance problems if they all share a common parent. In the value defining the parent directory, it is possible to use the following keywords to create a per-VO parent under a common root (in a common file system):
     556When supporting multiple VOs, the number of accounts can be very large (several thousands). This may lead to performance problems if they all share a common parent. In the value defining the parent directory, it is possible to use the following keywords to create a per-VO parent under a common root (in a common file system):
    557557 * `@VONAME@` : will be expanded to the VO full name
    558558 * `@VOALIAS@` : will be expanded to the VO alias name locally defined. When possible, it is better to use the VO full name which is unique and will not change.
    … …  
    577577 * `CE_LOCAL_QUEUES` : a list of Torque queue to define that will not be available for grid usage (accessible only with standard Torque commands). This list has a format very similar to `CE_QUEUES`, except that key containing queue name is called `names` instead of `vos` and that its value is useless.
    578578
    579 ''Note: in previous version of the templates, customization of queue list was done by defining `CE_QUEUES` variable in site parameters. In this case the creation of the queue for each VO had to be done in site templates. This has been changed and sites must now use `CE_QUEUES_SITE` to define site specific queues or redefine attributes of standard queues.''
     579''Note: in previous version of the templates, customization of queue list was done by defining `CE_QUEUES` variable in site parameters. In this case the creation of the queue for each VO had to be done in site templates. This has been changed and sites must now use `CE_QUEUES_SITE` to define site-specific queues or redefine attributes of standard queues.''
    580580
    581581
    … …  
    589589 * `TORQUE_TMPDIR` : normally defined to refer to the working area created by Torque for each job, on a local filesystem. Define as `null` if you don't want job current directory to be redefined to this directory.
    590590 * `TORQUE_SERVER_ATTRS` : nlist allowing to customize all server-related Torque parameters. For the complete list of supported parameters and default values, look at [source:templates/trunk/grid/glite-3.1/common/torque2/server/config.tpl common/torque2/server/config.tpl]. To undefine an attribute defined by default, define it to `undef`.
    591  * `WN_ATTRS` : this variable is a nlist with one entry per worker node (key is the node fullname). Each value is a nlist consisting in a set of PBS/Torque attribute to set on the node. Values are any `key=value` supported by `qmgr set server` command. One useful value is `state=offline` to cause a specific node to drain or `state=online` to reenable the node (suppressing `state=offline` is not enough to reenable the node). One specific entry in `WN_ATTRS` is `DEFAULT` : this entry is applied to any node that doesn't have a specific entry. If you want to avoïd re-enabling a node explicitely, you can have the `DEFAULT` entry be defined with the `state=free` arguments. For instance, you could define :
     591 * `WN_ATTRS` : this variable is a nlist with one entry per worker node (key is the node fullname). Each value is a nlist consisting in a set of PBS/Torque attribute to set on the node. Values are any `key=value` supported by `qmgr set server` command. One useful value is `state=offline` to cause a specific node to drain or `state=online` to reenable the node (suppressing `state=offline` is not enough to reenable the node). One specific entry in `WN_ATTRS` is `DEFAULT` : this entry is applied to any node that doesn't have a specific entry. If you want to avoïd re-enabling a node explicitly, you can have the `DEFAULT` entry be defined with the `state=free` arguments. For instance, you could define :
    592592{{{
    593593variable WN_ATTRS ?= nlist(
    … …  
    632632
    633633If this doesn't fit your needs, you can explicitly control RSH and SSH configuration with the following variables :
    634  * `CE_USE_SSH` : if `undef` (default), configuration is based on use of a shared filesystem for home directories. Else it explicitly set wether to configure SSH host-based authentication (`true`) or not (`false`).
     634 * `CE_USE_SSH` : if `undef` (default), configuration is based on use of a shared filesystem for home directories. Else it explicitly set whether to configure SSH host-based authentication (`true`) or not (`false`).
    635635 * `SSH_HOSTBASED_AUTH_LOCAL` : when this variable is true and `CE_USE_SSH` is false, configure SSH host-based authentication on each WN restricted to the current WN (ability to use SSH without entering a password only for ssh to the current WN). This is sometimes required by some specific software.
    636636 * `RSH_HOSTS_EQUIV` : If true, `/etc/hosts.equiv` is created with an entry for the CE and each WN. If false an empty `/etc/hosts.equiv` is created. If `undef`, nothing is done. Default is `undef`.
    … …  
    690690}}}
    691691
    692 ''Note: if `CE_RUNTIMEENV` is defined in the site configuration template, this value will be used and must supply all the standard tags in addition to site specific ones.''
     692''Note: if `CE_RUNTIMEENV` is defined in the site configuration template, this value will be used and must supply all the standard tags in addition to site-specific ones.''
    693693
    694694
    … …  
    765765Supported parameters for each SE are :
    766766 * `type` : define SE implementation. Must be `SE_Classic`, `SE_dCache` or `SE_DPM`. This parameter is required and has no default. Note that SE Classic is deprecated.
    767  * `accessPoint` : define the root path of any VO specific area on the SE.  This parameter is required with Classic SE and dCache. It is optional with DPM where it defaults to `/dpm/dom.ain.name/homes`.
     767 * `accessPoint` : define the root path of any VO-specific area on the SE.  This parameter is required with Classic SE and dCache. It is optional with DPM where it defaults to `/dpm/dom.ain.name/homes`.
    768768 * `arch` : used to define `GlueSEArchitecture` for the SE. This parameter is optional and defaults to `multidisk` that should be appropriate for standard configurations.
    769769
    … …  
    852852=== LFC site parameters ===
    853853
    854 Normally the only thing really required in this site specific template is the password for LFC user (by default `lfc`) and the DB accounts. Look at standard LFC [source:templates/trunk/glite-3.0.0/glite/lfc/config] configuration template for the syntax.
     854Normally the only thing really required in this site-specific template is the password for LFC user (by default `lfc`) and the DB accounts. Look at standard LFC [source:templates/trunk/glite-3.0.0/glite/lfc/config] configuration template for the syntax.
    855855
    856856Starting with QWG Templates release gLite-3.0.2-9, there is no default password value provided for account used by DPM daemons and for the DB accounts used to access the DPM database. You '''MUST''' provide one in your site configuration. If you forget to do it, you'll get a not very explicit panc error :
    … …  
    926926 * Resource BDII : used in replacement of Globus MDS to publish resource information into BDII.
    927927
    928 When configuring BDII on a machine, the following variables can be used (in the machine profile or in a site specific template) to tune the configuration :
     928When configuring BDII on a machine, the following variables can be used (in the machine profile or in a site-specific template) to tune the configuration :
    929929 * `BDII_TYPE` : can be `resource`, `site`, `top`. `top` is the default, except if deprecated variable `SITE_BDII` is true.
    930930 * `BDII_SUBSITE` : name of the BDII sub-site. Ignored on any BDII type except `site`. Must be empty for the main site BDII (default) or defined to the sub-site name if this is a subsite BDII.
    … …  
    939939=== Configuring BDII URLs on a site BDII === #siteBDII
    940940
    941 A site BDII aggretates information published by several other BDIIs, typically resource BDIIs or subsite BDIIs. List of resources to aggregate are specicified by variable `BDII_URLS`. This variable is typically defined in site parameters, [source:templates/trunk/sites/example/site/site/glite/config.tpl site/glite/config.tpl], and is ignored on all nodes except a site (or combined) BDII.
     941A site BDII aggretates information published by several other BDIIs, typically resource BDIIs or subsite BDIIs. List of resources to aggregate are specified by the variable `BDII_URLS`. This variable is typically defined in site parameters, [source:templates/trunk/sites/example/site/site/glite/config.tpl site/glite/config.tpl], and is ignored on all nodes except a site (or combined) BDII.
    942942
    943943Variable `BDII_URLS` is a nlist of URLs corresponding to the resource BDII endpoints (urls) aggregated on the site BDII. The key is an arbitrary name (like `CE`, `DPM1`...) but must be unique and the value is the endpoint. See [source:templates/trunk/sites/example/site/site/glite/config.tpl site configuration] example.
    … …  
    10261026__Base template__ : `machine-types/px`.
    10271027
    1028 MyProxy server configuration consists of defining policies for access to proxies stored on the server and their renewal. There are 2 sets of policiies : explictly authorized policies and default policies. For each set a separate policy can be defined for:
     1028MyProxy server configuration consists of defining policies for access to proxies stored on the server and their renewal. There are 2 sets of policiies : explicitly authorized policies and default policies. For each set a separate policy can be defined for:
    10291029 * renewers : list of clients able to renew a proxy. The variables to use are `MYPROXY_AUTHORIZED_RENEWERS` and `MYPROXY_DEFAULT_RENEWERS`.
    10301030 * retrievers : list of clients able to retrieve a proxy it they have valid credentials and provide the same username/password as the one used at proxy creation. The variables to use are `MYPROXY_AUTHORIZED_RETRIEVERS` and `MYPROXY_DEFAULT_RETRIEVERS`.
    … …  
    10871087This is critical for the security to restrict the number of people allowed access to the VOBOX. By default, only people with the VO SW manager role can log into the VO box. To change this configuration, refer to section on [#MappingofVOMSgroupsrolesintogrid-mapfile VOMS groups/roles mapping], but be sure you really need to allow other roles as it can give unwanted users access to privilege services.
    10881088
    1089 The configuration templates for the VOBOX enforce there is only one VO configured for acess to VOBOX specific services. This VO must be declared using the `VOS` variable, as for other machine types. If you want to give other VOs access to the VOBOX for the management and operation of the VOBOX, you need to explicitly allow them using the variable `VOBOX_OPERATION_VOS`. This variable is a list of VOs considered as operation VOs. By default, this list is only VO `ops`. If the VOs listed in this variable are not listed in  `VOS`, they are automatically added.
     1089The configuration templates for the VOBOX enforce there is only one VO configured for acess to VOBOX-specific services. This VO must be declared using the `VOS` variable, as for other machine types. If you want to give other VOs access to the VOBOX for the management and operation of the VOBOX, you need to explicitly allow them using the variable `VOBOX_OPERATION_VOS`. This variable is a list of VOs considered as operation VOs. By default, this list is only VO `ops`. If the VOs listed in this variable are not listed in  `VOS`, they are automatically added.
    10901090
    10911091Only the enabled VO has a `gsissh` access to the VOBOX by default. If you want the operation VOs to also be enabled for `gsissh` access to the VOBOX, you need to define variable `VOBOX_OPERATION_VOS_GSISSH` to `true` in the VOBOX profile. Only the FQAN enabled by [#MappingofVOMSgroupsrolesintogrid-mapfile VO_VOMS_FQAN_FILTER] will be enabled for each VO (default: SW manager).