Changes between Version 96 and Version 97 of Doc/gLite/TemplateCustomization


Ignore:
Timestamp:
Oct 29, 2008, 6:22:24 PM (17 years ago)
Author:
/O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=Michel Jouvin
Comment:

General review (in progress)

Legend:

Unmodified
Added
Removed
Modified

  • Doc/gLite/TemplateCustomization

    v96 v97  
    44[[TOC(inline)]]
    55
    6 Site customization to QWGtemplates is done through a small set of templates used to define variables used as input by QWG templates. This doesn't cover OS basic configurationt that is decribed in the page about [wiki:Doc/TemplateCustom template framework].
    7 
    8 All site parameters related to QWG middleware are supposed to be declared in template `site/glite/config.tpl`. To start a new site, import the site paramater 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'''.
     6Site customization to QWGtemplates is done through a small set of templates used to define variables used as input by QWG templates. This doesn't cover OS basic configuration that is described in the page about [wiki:Doc/TemplateCustom template framework].
     7
     8All site parameters related to QWG middleware are supposed to be declared in template `site/glite/config.tpl`. 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'''.
    99
    1010''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.''
    … …  
    7070== VO Configuration ==
    7171
    72 List of VOs to configure on a specific node is defined in variable `VOS`. Generally a site-wide default value is defined in `site/glite/config.tpl` (defined with operator `?=`). This value can be overidden on a specific machine by defining `VOS` variable in the machine profile, before including the machine type profile.
     72List of VOs to configure on a specific node is defined in variable `VOS`. Generally a site-wide default value is defined in `site/glite/config.tpl` (defined with operator `?=`). This value can be overridden on a specific machine by defining `VOS` variable in the machine profile, before including the machine type profile.
    7373
    7474An example of VOS definition is :
    … …  
    159159
    160160=== Adding a New VO ===
     161
     162'''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).'''
    161163
    162164Adding 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.
    … …  
    244246A 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.
    245247
    246 '''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).
     248'''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 requiring this user).
    247249
    248250== Accepted CAs ==
    249251
    250 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`.
     252There 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`.
    251253
    252254If you need to update this template, refer to the standard [wiki:Development/Templates/Generated#TrustedCAsTemplate procedure] to do it.
    … …  
    275277=== Defining NFS exports ===
    276278
    277 On each NFS server or in cluster or site parameters, NFS exports can be defined using a set of variables. By default only CE and worker nodes are given access to NFS server.
     279NFS exports can be defined using a set of variables. By default only CE and worker nodes are given access to NFS server. This variables can be redefined either in NFS server profile, in the cluster the NFS server belongs to or in the gLite site parameters used by NFS server.
    278280
    279281''Note : the following variables don't configure filesystem mounting. For this see [wiki:Doc/gLite/TemplateCustomization#SharedFileSystems Configuring shared filesystems].''
    … …  
    284286 * `NFS_LOCAL_CLIENTS` : list of other local hosts requiring access to NFS server
    285287
    286 These variables can be a string, a list or a nlist. A string value is interpreted as a list with one element. When specified as a list or string, the value must be regexp matching name of nodes that must be given access to NFS server. In this case, the access rights (export options) is based on variable `NFS_DEFAULT_RIGHTS`. When specified as a nlist, the key must be an '''escaped''' regexp matching node names (in exports format, only `*` and `?` wilcards permitted) and the value is the export options between `()`.
    287 
    288 ''Note : when possible, this is recommended to replace default value for NFS_WN_HOSTS (list of all WNs) by one or several regexps matching WN names.''
    289 
    290 `NFS_DEFAULT_RIGHTS` is a nlist which must contain a `DEFAULT` entry used for any file system without an explicit entry and optionally one entry per file system (key is the escaped file system path) when defaults are not appropriate. Default is `rw` with root squashing enabled for all file systems (`DEFAULT` entry), except `/home` where root squashing is disabled.
    291 
    292 Antoher variable, `NFS_CLIENT_HOSTS` allows to define per file system the clients allowed to access the file system. There is a default entry (`DEFAULT`) used for any file system without an explicit entry. The default value for default entry is all the hosts specified by `NFS_CE_HOSTS`, `NFS_WN_HOSTS` and `NFS_LOCAL_CLIENTS`. Key specifying a file system path must be escaped. Host list of allowed clients may be specified using regexps in export format.
     288These variables can be a string, a list or a nlist. A string value is interpreted as a list with one element. When specified as a list or string, the value must be a regexp matching name of nodes that must be given access to NFS server. In this case, the access rights (export options) is the string specified in variable `NFS_DEFAULT_RIGHTS`. When specified as a nlist, the key must be an '''escaped''' regexp matching node names (in exports format (only `*` and `?` wilcards permitted) and the value is the export options between `()`.
     289
     290''Note : when possible, this is recommended to replace default value for NFS_WN_HOSTS (list of all WNs) by one or several regexps matching WN names to reduce the number of hosts on the export line.''
     291
     292`NFS_DEFAULT_RIGHTS` is a nlist which must contain a `DEFAULT` entry used for any file system without an explicit entry and optionally one entry per file system (key is the escaped file system path) when defaults are not appropriate. If not defined, default is `rw` with root squashing enabled for all file systems (`DEFAULT` entry), except `/home` where root squashing is disabled.
     293
     294Antoher variable, `NFS_CLIENT_HOSTS`, allows to define the clients allowed to access the file system on a per file system basis. There is a default entry (`DEFAULT`) used for any file system without an explicit entry. The default value for default entry is all the hosts specified by `NFS_CE_HOSTS`, `NFS_WN_HOSTS` and `NFS_LOCAL_CLIENTS`. Keys specifying file systems must be the '''escaped''' file system mount point. Host list of allowed clients may be specified using regexps in export format.
    293295
    294296''Note: currently `NFS_CLIENT_HOSTS` is used to build the list of hosts in `exports` file but has no impact on the mounting of file systems on clients.''
    … …  
    298300__Base template__ : `machine-types/nfs`.
    299301
    300 With QWG templates, it is possible to configure a machine as a dedicated NFS server whose configuration is shared with grid machines for file system configuration and accounts.
     302When using this template, it is possible to configure a machine as a dedicated NFS server whose configuration is shared with grid machines for file system configuration and accounts. But in QWG templates, any gLite machine type will be configured as a NFS server as soon as the machine is listed as the NFS server for one of the file systems in `WN_SHARED_AREAS`.
     303
    301304
    302305== LCG CE Configuration ==
    … …  
    304307__Base template__ : `machine-types/ce`.
    305308
    306 QWG templates handle configuration of the LCG CE and the selected batch system (LRMS). To select the LRMS you want to use, you have to define variable `CE_BATCH_NAME`. '''There is no default'''. If you want to use Torque/MAUI, recommended version is `torque2`.
    307 
    308 The value of `CE_BATCH_NAME` must match a directory in `common` directory of gLite3 templates.
    309 
    310 ''Note : as of gLite 3.0.2, LRMS supported are Torque v1 (`torque1`) and Torque v2 (`torque2`), with MAUI scheduler.'' 
    311 Previous versions of QWG templates used to require definition of `CE_BATCH_SYS`. This is deprecated : this variable is now computed from `CE_BATCH_NAME`.
     309QWG templates handle configuration of the LCG CE and the selected batch system (LRMS). To select the LRMS you want to use, you have to define variable `CE_BATCH_NAME`. '''There is no default'''. If you want to use Torque/MAUI, `CE_BATCH_NAME` value must be `torque2` (Torque v1 is no longer supported).
     310
     311The value of `CE_BATCH_NAME` must match a directory in `common` directory of gLite templates. Currently supported LRMS in QWG templates (Octobre 2008) are Torque/MAUI and Condor.
     312
     313''Note: previous versions of QWG templates used to require definition of `CE_BATCH_SYS`. This is deprecated : this variable is now computed from `CE_BATCH_NAME`.''
    312314
    313315=== PBS/Torque ===
    … …  
    322324 * `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.
    323325 * `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]
    324  * `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. Just 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 :
     326 * `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 :
    325327{{{
    326328variable WN_ATTRS ?= nlist(
    … …  
    335337For more details about all of these variables, their format and their default values, look at template defining [source:templates/trunk/grid/glite-3.1/defaults/glite/config.tpl default values] for gLite related variables.
    336338
    337 ''Note: the standard name for a queue is the VO name. With some VO names, this results in a name longer than the maximum allowed by Torque. A workaround is to define a VO alias and use it in your configuration. See section about VO configuration.
     339''Note: the standard name for a queue is the VO name. With some VO names, this results in a name longer than the maximum allowed by Torque. A workaround is to define a VO alias and use it in your configuration. See section about VO configuration.''
    338340
    339341=== MAUI ===
    … …  
    362364=== RSH and SSH Configuration ===
    363365
    364 By default Quattor doesn't configure any RSH or SSH trust relationship between CE and WNs if home directories are on a shared filesystem declared in variable `WN_SHARED_AREAS`. Else it configures SSH with host-based authentication. By default RSH is always configured with an empth `hosts.equiv` file.
     366By default Quattor doesn't configure any RSH or SSH trust relationship between CE and WNs if home directories are on a shared filesystem declared in variable `WN_SHARED_AREAS`. Else it configures SSH with host-based authentication. By default RSH is always configured with an empty `hosts.equiv` file.
    365367
    366368If this doesn't fit your needs, you can explicitly control RSH and SSH configuration with the following variables :
    … …  
    402404}}}
    403405
    404 This change is backward compatible : if `CE_RUNTIMEENV` is defined in the site configuration template, this value will be used.
     406''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.''
    405407
    406408