Forensic analysis of patchlevel in a supportconfig

Update – June 2017 : SUSE Linux Enterprise Server 12 SP1 is now LTSS, bug fixes.

Do you ever get exposed to supportconfig files from servers that do not have access to update repositories ? Or do you find it difficult to relate to patch numbers of updates (not) installed in updates.txt of a supportconfig?

If so, how do you easily find out if there are pending updates available from SUSE to be installed on the system to make it up to date?
Exactly – you don’t.

Until now…

Install the oscc (for Offline SupportConfig Checker) package on a system with access to a local mirror on e.g. a Subscription Management Tool (SMT) server.

This package contains a digested cache of the update repositories for the main SUSE Linux Enterprise (SLE) products along with a plain shell script.

When executed against a supportconfig archive, oscc

• detects the SLE products installed
• sets up and updates the “cache” for the applicable repositories
• examines the SLE package versions installed on the system
• checks if each of the packages is up to date
• displays the results to the user

In the config file the URL to the update repositories needs to be defined. It is assumed to be a directory structure provided by an SMT server and accessible via http, https, nfs or local storage.

Currently the script supports the x86_64 and i586 architectures of:

• SUSE Linux Enterprise Server 12 SP{0,1,2}, 11 SP{1,2,3,4} and 10 SP{1,2,3,4}
• The following SUSE Linux Enterprise 12 modules :
  • Advanced Systems Management Module
  • Containers Module
  • Public Cloud Module
  • Legacy Module
  • Toolchain Module
  • Web and Scripting Module
• SUSE Linux Enterprise Workstation Extension 12 SP {0,1,2}
• SUSE Linux Enterprise High Availability Extension 12 SP {0,1,2} and 11 SP{1,2,3,4}
• SUSE Enterprise Storage 3 and 4
• SUSE OpenStack Cloud 6 and 7
• SUSE Linux Enterprise Software Development Kit 12 SP{0,1,2}, 11 SP{1,2,3,4} and 10 SP4
• Subscription Management Tool 11 SP{1,2,3}

SLE 11 without service packs is not supported, since it is not available under the Long Term Service Pack Support (LTSS) program. See the Long Term Service Pack Support page for details on that.

Below is an example of how an execution of the script looks.

After determining products installed on the system and setting up the repositories, it cycles through each package:

The tool checks for available updates for the repositories applicable to the supportconfig, it is executed against.

In the example above, new versions of some packages have become available since the update “database” was last updated.

When the analysis is completed, a summary like this is displayed:

Download the RPM and try it out.

Since version string comparison turned out to be a somewhat complicated matter, the script is rather long and may seem chaotic. But it does the job.

And if it does not, please feel free to leave a comment here.

Feedback is welcome.