Novell Documentation: ZENworks Linux Management

Managing Software

This section covers software management with ZENworks Linux Management, including control of channels, packages, and package sets.

Channels

Channels are groups of software packages that you want to ship together. Channels are used to organize and control access to packages, usually according to operating system, software type, or some other common attribute.

Packages

A package is an individual software package, usually an RPM, that you want to make available to client machines.

Every package or patch you distribute must be in a channel.

Most software packages include a license file, and some set a specific license display flag. When that flag is set, installation tools will ask the user to agree to the terms of license before installation. The license flag is set at build time and not by ZENworks Linux Management. To learn about building packages with license flags, see the man page for the rpm command.

The ZENworks Linux Management server will detect kernel packages and handle them properly: they are marked for parallel installation rather than upgrade, and the necessary scripts to update the bootloader are run by the daemon.

Be aware that although ZENworks Linux Management will let you ship a package for many platforms, you are responsible for determining whether it will actually work on those platforms.

One particularly tricky issue is that a small number of very low-level packages actually require sub-architectures. For example, glibc-2.2.5-43-i686.rpm will not install properly on a Transmeta-based computer, even though Transmeta is an x86 architecture.

Package shipped in ZENworks Linux Management have three pieces of descriptive information:

Package Summary: Short description of the package contents provided by the software packager. For example, the package summary for the Evolution package is "Ximian Evolution integrates email, calendaring, meeting scheduling, contact management, and task lists, in one powerful, fast, and easy-to-use application." This information is displayed in the detailed package information page in the Web interface, as the output of the command rug info packagename, and in the GUI client application.
Package Description: A more detailed description of the package contents, provided by the software packager. For example, the description of the httpd package is "Apache is a powerful, full-featured, efficient, and freely-available Web server. Apache is also the most popular Web server on the Internet." This information is displayed in the detailed package information page in the Web interface, as the output of the command rug info packagename, and in the GUI client application.
Update Description: Additional comments provided by the ZENworks Linux Management administrator, usually describing the reasons for shipping the package. This information appears in the Basic package information tab, and is not displayed to clients.

SUSE 9 Patches

ZENworks Linux Management 6.6.2 includes the ability to manage and deploy SUSE patch files to SUSE Linux Enterprise Server 9, and SUSE Linux 9.1.

SUSE patch files enable you to update a software package with a newer version without reinstalling the entire package. Patch files are created and distributed by SUSE directly, relieving you of the burden of tracking and managing updates to your SUSE machines.

SUSE patch files are managed and deployed similar to packages. However, ZENworks Linux Management distinguishes between packages and patches, enabling you to manage them separately.

Package Sets

A package set is a virtual group of packages that are treated like a single package, and have similar attributes to packages.

For example, you might create a package set called JavaTools, containing all the tools your engineering team needs to develop Java software. A package set provides functionality, just like a package does, and has the same sorts of conflicts and dependencies that a package does. It is, essentially, a convenient handle for a number of packages you always or nearly always manipulate at once.

In many ways, package sets behave like individual packages:

A package set must be in a channel.
Package sets have version numbers. Any change to a package set require a change in the version number.
Package sets can be installed or updated as though they were packages.

However, package sets are not packages, and they have a number of important differences from packages and from the channels in which they exist:

Since package sets are created by the server administrator, it is the server administrator, rather than the software vendor, who must change the version number for a package set.
Package set versions are always integers, although you may designate epochs as you would with a package.
The packages in a package set may be spread across multiple channels, but this is not recommended. If a package set includes packages from two channels, clients must have access to both of them to be able to install the package set.
Packages within a package set may not conflict with each other, although packages within a channel may.
If a package is part of a package set it cannot be deleted unless it is removed from the package set or the package set itself is deleted.
Package sets override package versions: If you install a package set with xsane 9.0 on a system, and xsane 9.1 becomes available in the channel, it will not be installed, even if a scheduled transaction would otherwise install it. To have the update performed, you must add a new version of the package to the package set, increase the package set's version number, and ship the new package set as an update. Therefore, be careful adding a package to a package set if you might later want to update that package alone.

Once you have created the package set, it appears in the channel like an ordinary package. If you click on it in the package list, you can update it. The update process is identical to the creation process.

Package sets do not have requires dependencies like normal packages do. Packages you require are simply the packages in the package set.

When you change a package set you must increase the version number, or client machines will not update it.

Examples of Using Package Sets

Consider package set P, packages A, B, and C, and the client machines system1 and system2. All three packages are already installed on system1, but system2 has only package A.

We start by creating package set P so that it contains packages A and B. If we ship the package set to both clients, it needs to be as a new install. System1 may already have all the required packages, but it does not yet have package set P. After the transaction, system1 will have package set P and packages A, B, and C, and system2 will have package set P and packages A and B.

Suppose there is now a new version of package A, which we'll call A-1.1. If we add A-1.1 to our distribution channel and tell the clients to update, they will not upgrade, because that would break package set P. To get them to upgrade, we need to create package set P-1.1, containing packages A-1.1 and B. When we ship that as an update, then the clients will install.

What if we add package C to the package set? To do so, we need to increase our version number again, to P-1.2. Then, we ship the package set as an update. System1 already has package C, so the only difference on that client is the package set version number. Note that System2 will also install package C, even if the transaction is not specifically an install transaction. It installs the new package because that is required by the upgrade. This is similar to the way that an upgrade from Evolution 1.4 to Evolution 2.0 will pull in junk-mail filtering software required by the new version.

In contrast, packages removed from package sets are not necessarily removed from the client machines. For example, we might change our package set again: P-1.3 contains packages A-1.1 and C, but not B. When the client machines upgrade to P-1.3, they are given no instructions about package B: it is no longer mentioned. Similarly, if you remove Evolution 2.0, the junk-mail filtering software it required is not removed. On the other hand, a new system installing P-1.3 would not install package B, again because package B is simply not mentioned.

To force the removal of package B from systems upgrading from P-1.2 to P-1.3, we would need to create an explicit conflict in the package set. Then, upgrading to P-1.3 would require the removal of package B. Remember, though, that unless removals are explicitly permitted, they will cause transaction failures, so if you want packages removed, you must not only create the conflict, but also indicate that package removals are permissible for this transaction.

Shipping a Package Set

Shipping a package set is identical to shipping a package, with one exception: channels. A package set may span multiple channels. If a client machine cannot access one of those channels, then the package set installation will fail for that client. If you spread package set contents across multiple channels, be sure that all the relevant client machines can reach all the right packages.