= 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.

=== 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.