Stanford Linear Accelerator Center

Linux Updates

SLAC Computing
UNIX at SLAC
Linux at SLAC
Updated: 28 Mar 2013

Vendor Errata Policies

Red Hat classifies its errata as security fixes, bug fixes or enhancements. As described in their Enterprise Linux Errata Support Policy, during the first three years of a major release they usually collect bug fix and enhancement errata and publish them together about once a quarter as an errata update (or just update). Enhancement errata are issued mostly to support new hardware and are strongly constrained against making incompatible changes. Security errata are published as soon as possible independently of the quarterly updates and throughout the full seven year lifetime of a major release. (In practice, Red Hat does occasionally publish critical bug fix or enhancement errata between updates; recent examples included fixes for the 2007 daylight savings time changes.)

SCCS Linux OS Update Policy

Security Errata
SCCS requires that all Linux systems on the main SLAC network (134.79.x.x, 172.x.x.x) should install all security errata as soon as possible, usually within a few days of their release. For "taylored" (i.e., centrally-managed) systems, this will be done automatically, but the system administrators of other Linux machines are also expected to keep up to date with security errata. Note that taylor installs most security errata without advance notice; however, kernel and glibc errata generally require a reboot and so we announce these with some lead time to allow users to schedule the reboot at a convenient time.
Enhancement and Bug Fix Errata Updates

SCCS recommends that most taylored Linux systems should install the quarterly updates within a few weeks of their general availability. Our experience with RHEL updates is that they have been well tested by the vendors and have caused very few problems when introduced at SLAC. Nevertheless, we recognize that some users will want to retain control of when an update is installed on mission critical machines; while others may want to test an update as soon as it's available at SLAC.

To accommodate these different approaches, we have defined a taylor option, os_updates, with three possible values (note that this option only affects enhancement and bug fix errata; security errata are applied promptly to all taylored machines).

os_updates=recommended
Taylor will install a new errata update after it's been available for testing at SLAC for at least two weeks. (This is the default.)
os_updates=required
Taylor will only install security errata and critical bug fixes. System administrators for such machines are encouraged to manually update their machines from time to time to the latest "recommended" level. See Manual Updates, below, for help in doing so.
os_updates=immediate
Taylor will install a new errata update as soon as it's available at SLAC.

To request an option other than the default ("recommended"), add the one of the above lines to the file, /etc/taylor.opts.

Special Handling for kernel and glibc Errata

Kernel and glibc errata require special handling since they involve a reboot.

  • kernel errata. A new Linux kernel can be installed side-by-side with the current one but has no effect until it is loaded at the next system reboot. Moreover, as long as the old kernel remains installed, it is possible to intervene during the boot process and select an older kernel if there are problems with the new one.

    When a new kernel errata becomes available, SCCS ensures that an AFS kernel module is available for it, installs it on a few test machines, and reboots those machines to make sure there are no serious problems. We then configure taylor to install it as the default kernel to be loaded at the next reboot. If the new kernel is classified as a security errata, a mandatory reboot is scheduled, typically about a week later (but possibly earlier if there is an active exploit of the security vulnerability).

  • glibc errata. SCCS recommends that systems should be rebooted immediately after installing a new glibc. Thus, we do not normally schedule installation of a new glibc via the nightly taylor run. Instead, we use a different feature of taylor to arrange for a new glibc to be installed as the system is going down at the next reboot or shutdown. This mechanism is used, in conjunction with a scheduled mandatory reboot, for installing new glibc security errata. The same mechanism will be used, without a mandatory reboot, for installing other glibc errata for systems with os_update=recommended and os_update=immediate. See Manual Updates for help installing glibc errata on machines with os_update=required.
Manual Updates

To check the available updates, issue the command,

 
   sudo yum check-update
Then you can decide which updates you would like to apply.

To install the latest set of errata, including new kernels and glibcs, issue the command,
   sudo yum upgrade
You should plan on rebooting the system immediately afterward.


Len Moss