= OS Errata Management and Deployment =
[[TracNav]]

[[TOC(inline)]]

Quattor can greatly help with OS errata deployment. QWG templates has a few specific features and tools to help managing them.

== Downloading RPM Errata ==

RPM errata should normally be downloaded from the official public servers for the distribution you use. With Scientitific Linux it is possible to use `rsync` to syncrhonize a local directory with the official repository. The rsync official URL prefix is:
 * For SL4:
{{{
rsync://rsync.scientificlinux.org/scientific/VERSION/ARCH/errata/SL/RPMS/
}}}
 * For SL5:
{{{
rsync://rsync.scientificlinux.org/scientific/VERSION/ARCH/updates/security
}}}

GRIF tends to have a rather up-to-date mirror of these repositories that you can access with http at:
{{{
http://quattorsrv.lal.in2p3.fr/packages/os/VERSION/errata
}}}

These are just suggestions, there are many way to synchronize with a reference repository, including YUM and a script provided by SCDB, [source:SCDB/trunk/utils/misc/sync-os-errata utils/misc/sync-os-errata], to do it in a cron job using `rsync` or `wget`.



== Generating Templates for OS Errata ==

After downloading the RPM errata, it is necessary to generate a template that will be used for deploying them. This is done with SCDB script [source:SCDB/trunk/utils/misc/rpmErrata.pl utils/misc/rpmErrata.pl]. This script accept one argument which is the name of the local directory containing the errata and configured as a SCDB RPM repository. It will produce on stdout a template with a `pkg_ronly` entry for the last version of all RPMs found in the directory passed to the script. The output must be redirected to a template.

For example, assuming your RPM errata for SL 4.7 x86_64 are located in directory `/www/htdocs/packages/os/sl470-x86_64/errata`, the command would be:
{{{
utils/misc/rpmErrata.pl /www/htdocs/packages/os/sl470-x86_64/errata/ > cfg/os/sl470-x84_64/rpms/errata.tpl
}}}

''Note: `rpmErrata.pl` is very verbose. All the information messages are sent to stderr and can be redirected separatly.

`In the resulting template, due to the specificities of upgrading kernels, kernel entries are are not added. See later for kernel upgrade specificities.

As the template use `pkg_ronly()` SPMA function, the errata will be included in the configuration only if another version of the same package and architecture is already part of the configuration.

''Note: normally, the template generated can be used as it is without any manual edition. Because `pkg_ronly` only replaces a RPM already part of the configuration, this may not work in the very rare cases where a RPM is renamed. In this case, you need to manually update the template to replace `pkg_ronly` by `pkg_repl` (same arguments) and add a line for the old package name (only argument) with `pkg_del` to remove the old package. This is also necessary for kernel modules where the kernel version is part of the RPM name for the module.''


== Deploying OS Errata ==

Errata deployment is controlled through variable `PKG_DEPLOY_OS_ERRATA`. By default, to avoid any problem at a site, errata deployment is disabled. But sites are '''strongly''' encouraged to define this variable to `true` to enable errata deployment. The most usual places to define this variables are `source:templates/trunk/clusters/example-3.1/site/cluster-info.tpl site/cluster-info.tpl] to control it at a cluster level or in [source:templates/trunk/sites/example/site/config.tpl site/config.tpl]  in your site-specific templates to control it at the site level. It is recommended to define a default value (using operator `?= `) to allow further redefinition in a node profile.

When enabled, OS errata deployment will use a template `rpms/errata.tpl` in the templates for the OS version used on a specific node. This default name can be changed using variable `PKG_OS_ERRATA_TEMPLATE` to define the template to use. It is '''strongly recommended''' to use a non default name to avoid any clash with the `errata.tpl` provided by the standard templates. This also allows to produce a different template for a different version of the errata (using the date in the template name for example) with a finer control over what is deployed when on which machine.

It sometimes happens that one errata RPM causes conflicts or have dependencies difficult to solve in the site context. If this RPM is not used or not critical for the site/node, it is possible to remove it by adding to the errata template something like:
{{{
'/software/packages' = pkg_del('myconflictingrpm');
}}}

''Note: never try to remove the RPM from the base templates used to configure the OS. First it may break some things when the errata are not deployed. Also one specific RPM is often added by several templates. But the main reason is that these templates are entirely [/wiki/Development/Templates/Generated#OSTemplates generated] from distribution official list. You obtain the same result with the line described above, except its effect is only in the context of these errata.''

=== Kernel errata ===

Handling of kernel errata is a bit specific due to some restrictions in the current version of SPMA and because an improper upgrade may lead to a machine not restartable.

With the current version of SPMA it is not possible to tell SPMA to never uninstall a kernel, even if it is no longer part of the configuration. As a result if you just replace the kernel, the one actually used will be removed at the same time the new one is installed and in case of a problem you may not be able to reboot. For this reason it is necessary to add new kernels with `pkg_add` and option `multi`.

With the kernel itself, you also need to ensure you have an entry for each of the kernel modules you use. For kernel modules, `pkg_add` must be used (same syntax as `pkg_ronly`) as the RPM name for the kernel module contains the kernel version as part of its name (and not of its version). There is no need for the `multi` option in this case as there is one unique package name based on the kernel version and clearly you can install only one version of a kernel module for given version of the kernel.