| 4 | | [[TOC(inline)]] |
| 5 | | |
| 6 | | This pages describes the use of QWG templates configuring the OS. These templates are not related to the middleware and can be used in other contexts. They are in charge of installing the required RPMs, based on feature groups requested, and do the base machine configuration (network, ...). They are used by middleware templates configuring a specific middleware machine type to do the base configuration of the machine. |
| 7 | | |
| 8 | | == Layout of OS Templates == |
| 9 | | |
| 10 | | Starting with SL 3.07 and SL 4.3, OS templates use namespaces for easier locate of templates and to support multiple version/architecture in the same cluster. |
| 11 | | |
| 12 | | OS templates provides both RPM lists for each standard feature group and a few other templates to do the basic configuration and configure some OS related components (e.g. Quattor client that has dependencies over the OS architecture). |
| 13 | | |
| 14 | | Main namespaces (directories) used in OS templates are : |
| 15 | | |
| 16 | | * `rpmlist` : contains one template per feature group. These templates are completly generated from `comps.xml` provided with the OS distribution and reflect standard feature groups as selected from the standard installer. |
| 17 | | * `os` : contains a set of templates to define base machine configuration for a specific category of machine. To configure a gLite3 machine, the template to use is `pro_os_glite_base.tpl` (this is done by gLite3 templates). You can add your own machine category, defining a template for it, for other uses. Normally, templates in this namespace are the only templates that should be used in other templates. |
| 18 | | * `repository` : contains templates defining RPM repositories associated with OS. You may need to edit these templates to reflect your local configuration, if you are not using the suggested layout and names for RPM repositories. |
| 19 | | |
| 20 | | === Selecting OS version === |
| 21 | | |
| 22 | | There are 2 possibilities to select the OS version used by a cluster or a specific node : |
| 23 | | |
| 24 | | * Define the OS version at the cluster level : this is done by adding the appropriate path in {{{cluster.build.properties}}}. Look at the example above, in section [[wiki:Doc/TemplateCustom#ClustersandTemplateHierarchies Clusters and Template Hierarchies]]. Using this method, all the machines in the cluster MUST run the same OS version/architecture. This is the only method available for SL versions before SL 3.07 or SL 4.2. Using this method allows to define a default OS version for the cluster. |
| 25 | | * Define the OS version at the machine level : this is done by creating a template pointed by variable NODE_OS_VERSION_DB in your site or cluster hierarchy. In this template, variable `OS_VERSION` must contain one entry for each machine that is not using the default OS version defined for the cluster. The value is the directory containing templates for the OS version. This method allows to have different version/architecture combination into the same cluster. This second method requires OS template path in {{{cluster.build.properties}}} to be defined as {{{os}}} instead of the hierarchy used in first method. |
| 26 | | |
| 27 | | An [browser:templates/trunk/sites/example/site/pro_os_version_lcg_db.tpl example] of such a template can be found in the site example provided with QWG templates. To use this ability to define OS version/architecture per machine, you '''MUST''' define variable NODE_OS_VERSION_DB in cluster `pro_site_cluster_info.tpl` template or in site `pro_site_global_variables.tpl` template. Look at [browser/templates/trunk/clusters/example/site/pro_site_cluster_info.tpl examples] provided with QWG template releases. You can provide a separate template for each cluster or share this template between several clusters. |
| 28 | | |
| 29 | | Both methods can also be combined by specifying OS template path as follow in {{{cluster.build.properties}}} : |
| 30 | | {{{ |
| 31 | | os os/sl307-i386 |
| 32 | | }}} |
| 33 | | |
| 34 | | With these entries, the cluster will use SL 3.07 i386 as the default OS version for the cluster but this is possible to override this in any machine templates, using the second method. This is the only possibility to have both SL3 and SL4 in the same cluster, as SL3 templates don't support the second method. |
| 35 | | |
| 36 | | |
| 37 | | == Configuring OS templates == |
| 38 | | |
| 39 | | === Selecting Kernel Version === |
| 40 | | |
| 41 | | Normally, standard templates provide an appropriate definition of the kernel number and variant (smp, hugemem...) according to hardware present (as declared in templates). If you want to override this default (used in particular to configure Grub), you can use the following variables : |
| 42 | | |
| 43 | | * `KERNEL_VERSION_NUM` : this must contain the kernel version, as it is in the RPM name, without the architecture. |
| 44 | | * `KERNEL_VARIANT` : `smp`, `hugemem`, `largesmp`... or nothing (empty string) for non smp kernel. |
| 45 | | |
| 46 | | |
| 47 | | === Selecting Kernel Architecture === |
| 48 | | |
| 49 | | Normally, an attempt is made to guess the OS architecture from the CPU model. But this doesn't fit all situations, in particular with processors that can be installed as 32-bit or 64-bit. You can force the architecture you want to use on a specific machine by défining variable `CPU_ARCH` to the architecture name, using standard architecture names used in RPMs (e.g. i386, x86_64...). |
| | 4 | [[redirect(wiki:Doc/OS/Customization)]] |
