OS Errata Management and Deployment

Table of Contents

1. Downloading RPM Errata
2. Generating Templates for OS Errata
3. Deploying OS Errata
   1. Kernel errata

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