by kishi on June 29, 2007 03:44pm
Level-Set – Patch Management: Patch Management and Maintenance focuses on those solutions available to deploy and install software update on Linux systems, with a primary focus on Novell based Linux systems. This is going to be a very short blog because the only open source tool that I could find, which is used in a widespread manner, is YaST. I know there are tons of solutions out there, some proprietary like RHN and some custom built. YaST was the only common thread we could recognize. A deeper look at YaST and its online update abilities follows:
YAST Online Update Utility
Probably the most common and important modules in YaST are those related to software management (adding and removing software) and patch management. Software and updates for a typical SUSE system are obtained from software repositories, which can be local or remote software inventories from which new software or updates may be obtained. At a deeper level, the SLES9 package management system utilizes the common rpm utility to install, remove, and update packages and manage the package and dependency database. Although this subsystem is similar to RedHat’s, Novell has chosen a very different approach to distributing its patches, choosing to utilize what are called patch RPMs. With many RPM-based distributions, when a package needs to be updated for one reason or another the distributor will modify or patch the original source tree and recompile/repackage the software to produce a new RPM for that particular package. Therefore in these cases the new RPM will simply be an updated version of the original RPM.
Novell has taken a slightly different approach with patching via RPMs. Instead of updating and repacking the entire package, Novell updates the original source tree, recompiles, and then produces a delta (or a diff) between the original binaries in the package and the newly patched/recompiled binaries. The delta is a binary file that contains information about the differences between two binary files. The deltas will then be packaged within an RPM and distributed to clients. The patch RPM can then be manually or automatically installed in the same way a standard RPM would be installed. An advantage to this technique is that patches are often smaller in size – typically anywhere between 5KB and 8MB depending on the size of the package and the changes being applied. This often allows the update process to progress far faster than it would otherwise when using full RPMs – especially for large applications.
Major updates to the stable SLES9 branch are released as an installable “service pack”. Novell typically recommends installing the service pack files via YaST2, from either a CDROM or network location that contains the service pack files. One may also simply utilize the Online Update module of YaST2 to update the system manually or automatically. In this case, the service pack will be distributed as a large number of individual packages, similar to how RedHat distributes major updates (i.e. RHEL4 U4). Aside from a log file, SLES9 does not currently have an email mechanism to inform the administrator when a patch is automatically downloaded and installed (as RedHat does). However, a log file that contains information about each automatic update is maintained in /var/lib/YaST2/you/youlog. This log is generally very easy for an administrator to read and discover when, or if, a patch RPM was downloaded and installed.
There are other ways to find information about installed patches, however. By default, SLES9 archives each patch RPM that is downloaded and installed. Full RPMs will also be archived if they were installed via YaST2 after the original system installation. This functionality can be disabled with YaST2, of course, although it can sometimes be useful to maintain the archive if a patch ever needs to be reinstalled.
1. YaST Software/Update Repositories
Software repositories are typically added manually via the Installation Source module in YaST or can be scanned using SLP (Service Location Protocol). From this module, one may add references to locations from which to receive updates. These references typically take the form of a URI or a directory path. YaST supports the following software repository references:
- CD or DVD
- Local Directory
Using this methodology it is also quite common for an administrator to install a centralized repository for software and updates. Updates may then be obtained from Novell by a single server, and other servers on the LAN may then pull patches from the central patch server using one of the above protocols.
2. YaST Security
Although software repositories for SLES and SLED distributions are typically operated by Novell, it is quite possible to add third-party repositories to obtain software not offered by Novell, or even different versions of the same software packages. Novell warns against this, however, since adding repositories not controlled by Novell can result in the installation of untested or possibly malicious software, which ultimately could compromise security, but more likely may result in software instability and RPM package conflicts.
All official software and patches obtained by Novell are cryptographically signed, which can be verified with Novell’s public key. The public keys used to verify these signatures are typically obtained via the official SLES/SLED CDs or DVDs, but may also be obtained via Novell’s website. Once these public keys are accepted and imported, any software package or update obtained with an invalid signature will produce a warning and may not install without user intervention.
3. YaST Automatic Updates
Automatic updates can be configured via YaST’s Online Update Setup module, which allows a user to schedule updates to occur at a particular time either daily or weekly. On the backend, this module simply installs a new cron entry, a task scheduling application, which periodically runs another program to check for and install updates pushed out by Novell.
In earlier SUSE-based systems, YOU (YaST Online Update) had been used to automate the installation of updates packages. The cron utility would execute a shell script called /usr/bin/online_update which would automate the patch installation process. Newer versions of SUSE, including SLED10, utilize a similar process but instead of a shell script a utility called rug is used. The rug utility is the command-line interface to the ZENworks management agent that is present on new SUSE systems.
If you are running any open source based tools or applications in your environment to push patches and manage online update scenarios, we would REALLY like to hear what you have to say. As always THANK YOU for tuning into Port25