Maintenance Howto

Duncan Mac-Vicar P.

Introduction

Overview

Usually a system will have at least two repositories registered. One containing the installation media for the product, and one repository which delivers the maintenance updates for the product.

Metadata

As the dependency information is contained in the rpm package files, it is necessary to extract that information to separate metadata to allow local applications to calculate dependencies of remote repositories without needed to download the full package first.

In the picture you can see the different metadata components:

package information, which contains package dependencies and attributes
update information, included in update repositories which describes a maintenance update, which can include various packages and extra information like links to the issue tracker.
delta information, if the repository contains delta packages in addition to normal packages, extra information is needed for the client to figure out which of the installed packages can be updated downloading only the delta package instead of the whole file.

For Code11 SUSE systems, the metadata is implemented using the rpm metadata standard, used by tools like yum. Each of the components of the repository is called "resource".

The standard defines some resources like "primary" which is where the package information goes. The patch information is implemented using an updateinfo file, which is the same the Fedora distribution uses. The delta information is implemented using the same format the yum-presto plugin uses, which provides delta package support to yum.

With the specific rpm-md implementation, the picture now look like this:

The repomd.xml component acts as an index to the other resources plus adds extra information like timestamps and checksums used to verify all resources. For more information about how the metadata is secured, see the general model in Zypp metadata signature and and how it applies to the rpm-md implementation.

Tools

In order to generate metadata from rpm packages. You can use the createrepo tool.

dmacvicar@piscola:/repo> ls
zip-2.31-58.i586.rpm
zip-debuginfo-2.31-58.i586.rpm
ziptool-1.4.0-167.i586.rpm
ziptool-debuginfo-1.4.0-167.i586.rpm

dmacvicar@piscola:/repo> createrepo .
4/4 - ziptool-debuginfo-1.4.0-167.i586.rpm
Saving Primary metadata
Saving file lists metadata
Saving other metadata

Now there should be a repodata/ directory in the repository containing all the repository metadata.

dmacvicar@piscola:/repo> ls repodata/
ls repodata/
filelists.xml.gz  other.xml.gz  primary.xml.gz  repomd.xml

To inject extra information, like delta or patch information into your own repos, you have two options:

generate it yourself and then use the "modifyrepo" command to add it to the repomd.xml index. (yum-presto comes with tools to generate delta information files).
use tools which generate the information like Bodhi.

For just consuming SUSE updates, you don't have to worry. The metadata is generated automatically from our autobuild system.

Patches

In order to perform maintenance of a SUSE Linux system (openSUSE or SLE), you may want to be familiar with patch management and the rationale behind patches.

The objective of patches is to provide a maintenance point of view over the updated packages (as multiple packages could be involved in one issue).

Let's examine one single patch contained in updateinfo.xml:

<update status="stable" from="maint-coord@suse.de" type="security" version="36">
  <id>xorg-x11-Xvnc</id>
  <title>Multiple Xorg vulnerabilities reported by iDefense</title>
  <release>openSUSE 11.0</release>
  <issued date="1213630432"/>

The first part states who is the issuer of the patch. This has to be universally unique, so a URI or an email address will do it. The id also has to be unique (like a package name).

  <references>
    <reference href="https://bugzilla.novell.com/show_bug.cgi?id=374318" id="374318" title="bug number 374318" type="bugzilla"/>

  </references>

The references section allows to embed machine readable metainformation about the issues.

  <description>This update fixes multiple vulnerabilities  reported by
iDefense:
- CVE-2008-2360 - RENDER Extension heap buffer overflow
- CVE-2008-2361 - RENDER Extension crash
- CVE-2008-2362 - RENDER Extension memory corruption 
- CVE-2008-1379 - MIT-SHM arbitrary memory read
- CVE-2008-1377 - RECORD and Security extensions  memory
  corruption
</description>

The description of the patch. In this case it is incorrect, as the relations to the advisories should be listed in the references section.

  <pkglist>
    <collection>
        <package name="xorg-x11-Xvnc" arch="i586" version="7.3" release="110.2">
          <filename>xorg-x11-Xvnc-7.3-110.2.i586.rpm</filename>
        </package>
        <package name="xorg-x11-Xvnc" arch="ppc" version="7.3" release="110.2">

          <filename>xorg-x11-Xvnc-7.3-110.2.ppc.rpm</filename>
        </package>
        <package name="xorg-x11-Xvnc" arch="x86_64" version="7.3" release="110.2">
          <filename>xorg-x11-Xvnc-7.3-110.2.x86_64.rpm</filename>
        </package>
        <package name="xorg-x11-server" arch="i586" version="7.3" release="110.2">
          <filename>xorg-x11-server-7.3-110.2.i586.rpm</filename>

        </package>
        <package name="xorg-x11-server" arch="ppc" version="7.3" release="110.2">
          <filename>xorg-x11-server-7.3-110.2.ppc.rpm</filename>
        </package>
        <package name="xorg-x11-server" arch="x86_64" version="7.3" release="110.2">
          <filename>xorg-x11-server-7.3-110.2.x86_64.rpm</filename>
        </package>
        <package name="xorg-x11-server-extra" arch="i586" version="7.3" release="110.2">

          <filename>xorg-x11-server-extra-7.3-110.2.i586.rpm</filename>
        </package>
        <package name="xorg-x11-server-extra" arch="ppc" version="7.3" release="110.2">
          <filename>xorg-x11-server-extra-7.3-110.2.ppc.rpm</filename>
        </package>
        <package name="xorg-x11-server-extra" arch="x86_64" version="7.3" release="110.2">
          <filename>xorg-x11-server-extra-7.3-110.2.x86_64.rpm</filename>

        </package>
        <package name="xorg-x11-server-sdk" arch="i586" version="7.3" release="110.2">
          <filename>xorg-x11-server-sdk-7.3-110.2.i586.rpm</filename>
        </package>
        <package name="xorg-x11-server-sdk" arch="ppc" version="7.3" release="110.2">
          <filename>xorg-x11-server-sdk-7.3-110.2.ppc.rpm</filename>
        </package>
        <package name="xorg-x11-server-sdk" arch="x86_64" version="7.3" release="110.2">

          <filename>xorg-x11-server-sdk-7.3-110.2.x86_64.rpm</filename>
        </package>
    </collection>
  </pkglist>

The content (or related packages) is used to associate the patch with their packages (especially for the user interface). However, they are not used for dependency resolving.

</update>

Resolving patches

When the patch information is read, for every package, the patch object gets a conflicts with a previous version of the package. Therefore, in order to install the patch and get over the conflict, the solver needs to update the packages. In the other way around, if you downgrade the packages, it will conflict with the patch.

In Code10 the approach was a little bit different. Related packages where inserted as "requires" in the patch.

Licenses

Warning: This section is unfinished. Need to confirm support of rpm-md for EULAs.

Displaying messages

Pre transaction messages

Messages to be shown before the transaction can be achieved by adding the following tag in a patch:

<message>This update ...</message>

( at the same level where the description, issued tags are )

Right now messages only have a "Ok" confirmation. We would like to extend them to support different types of "Continue"/"Abort" or "Agree"/"Disagree" combinations and may be deprecate the explicit license tags. Your feedback is welcome.

Post transaction messages

For post transaction messages, they should be packaged in the updated rpm like scripts. See the documentation for details.

Running scripts

Since Code11, scripts are no longer part of the patch specification but part of the rpm files. Depending on your usecase, you have two options:

In transaction rpm scripts

rpm %pre scripts
rpm %post scripts

See %pre and %post sections in rpm documentation

Out of transaction scripts

These kinds of scripts should be used only when you need to run them out of commit. If this is not the case, use normal rpm %pre and %post scripts.

If you need to run a script that can't be run when rpm is executing (for example rebuilding the rpm database), then you may need to run after the rpm is installed. ZYpp will look in /var/adm/update-scripts for it and run it.

Scripts must be idempotent - running them multiple times must not have side effects.

For specific information on how to package the scrip with your updated package see the script specification.

Patches that require reboot

If one or more of the packages listed in the content section of the patch, has a reboot_suggested tag, then the applications will suggest to reboot the machine after the update:

<reboot_suggested>1</reboot_suggested>

See updateinfo description for an example.

This is an attribute of the packages appearing in the content part of the patch. It is not an attribute of the patch itself or the package itself.

Patches that update the package management stack

restart_suggested is not yet implemented in 3rd party tools.

If one of the packages listed in the content section of the patch, has a restart_suggested tag, then the applications will present one of these patches first and then restart the package management stack, until there are no more patches flagged with restart_suggested.

<restart_suggested>1</restart_suggested>