Changes between Version 118 and Version 119 of Doc/gLite/TemplateCustomization

Timestamp:

Mar 6, 2009, 4:50:37 PM (17 years ago)

Author:

/C=IE/O=Grid-Ireland/OU=cs.tcd.ie/L=RA-TCD/CN=Stephen O. Childs

Comment:

--

Doc/gLite/TemplateCustomization

@@ -77 +77 @@
 == VO Configuration ==
 
-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 overridden on a specific machine by defining `VOS` variable in the machine profile, before including the machine type profile.
-
-An example of VOS definition is :
+The list of VOs to configure on a specific node is defined in the 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.
+
+An example VOS definition is :
 {{{
 variable VOS ?= list('alice',
@@ -96 +96 @@
 }}}
 
-''Note : `dteam` and `ops` are mandatory VOs.''
-
-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 the VOs with parameters available in the configuration (normally all the VOs registered on [http://www.gridops.org CIC portal]) are configured. This specific value should normally be restricted to UIs where there is no VO accounts created. It's 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.
-
-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 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 collapse with another alias or full name. They must be used mainly to maintain backward compatibility in existing configuration where a name other than the VO full name was used. The use of VO alias is '''strongly''' discouraged for new configuration or new VO added to an existing configuration.''
+''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.
+
+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.''
  
 
@@ -168 +168 @@
 
 In addition to `VOS_SITE_PARAMS`, '''which is the recommended method''' to specify site-specific parameters for VO configuration, it is also possible for some specific purposes to execute a site-specific template before doing the configuration related to VOs. Use variable `NODE_VO_CONFIG` to specify the name of the template.
+
+=== Site-specific parameters for VOMS role accounts ===
+VOs often define roles in VOMS for specific purposes. For example, the ATLAS VO defines the role `production` which can only be used by users allowed to run production jobs. The roles defined for a VO are automatically retrieved by the `update.vo.config` and task. By default, a single account with an arbitrary suffix is automatically generated for each role found. For example, the following is an extract of the accounts generated for roles in the ATLAS VO:
+
+{{{
+"voms_roles" ?= list(
+     nlist("description", "SW manager",
+       "fqan", "lcgadmin",
+       "suffix", "s"),
+     nlist("description", "production",
+       "fqan", "production",
+       "suffix", "p"),
+     nlist("description", "pilot",
+       "fqan", "pilot",
+       "suffix", "hs"),
+...
+}}}
+
+A particular site may wish to define its own parameters for a particular VOMS role. You can do this by defining entries in the nlist variable VOMS_ROLE_CONFIG_SITE. In this example, the parameters are set for the role `production` in the ATLAS VO:
+{{{
+variable
+  VOMS_ROLE_CONFIG_SITE =
+   nlist("atlas",                            # VO
+     nlist(escape("production"),             # role FQAN
+        nlist(  "description","production",  # role params
+        "fqan", "production",
+        "name", "production",
+        "pool_size", 20,
+        "base_uid", 35800,
+        "pool_digits", 3,
+        "pool_start", 1,
+        "gid", 35080,
+        "suffix", "prd") ));
+}}}
 
 === Adding a New VO ===