On a recent call with a former ZENworks Linux Management customer that has since updated to ZENworks Configuration Management the other day I was reminded that things changed significantly between the two. The customer couldn’t figure out what we’d done with the functionality of a ZLM Catalog, and apparently it’s not very well documented, so thought I’d take a quick minute a review the two types of bundles for deploying software in a Linux environment as well as other package management concepts.
Linux bundles are the typical bundle you will use when you want to deploy and configure a piece of software, configuration files, and other actions in an ordered fashion. With a Linux bundle you have the standard action sets common to all bundles : Distribute, Install, Launch and Uninstall as shown in the screen show below:
As with Windows bundles you can create ordered sets of actions that will be processed when the bundle is executed. Linux bundles can be assigned to devices, device groups and folders. When a Linux bundle is assigned to a device, the metadata of any RPMs in any Install RPM action is cached to the workstation on refresh so that if other bundle installs or package installs require packages that are a part of this bundle they can be automatically installed during dependency resolution. However, as with Windows bundles the actions in the Install and/or Launch action sets are not transacted until the user either uses the zac bundle-install command or the ZENworks Window to execute the bundle. When the bundle is executed all of the content associated with the bundle is cached and all of the actions in the bundle executed.
Linux bundles are ideal when you want to perform software installs as an atomic unit of work, such as installing a web server. A Linux bundle for this task might first install the relevant Apache2 web server packages, modify the web server configuration files, deploy a set of web content to the data folder and then flag the service to start in runlevels 3 and 5. Linux bundles are also typically used to drive the update of SUSE Linux Service Packs.
Linux Dependency Bundle
A Linux Dependency Bundle is similar in function to the ZENworks Linux Management catalog object. When you create a Linux Dependency Bundle you don’t add Actions, you typically add packages directly and the system adds Distribute RPM actions which ensure that the metadata is distributed to the devices. There is not an ordered set of actions in a Linux Dependency bundle, rather there is an action for each OS target platform that the bundle has packages assigned to. The purpose of a Linux Dependency Bundle is to provide a set of packages that can either be used for dependency resolution, or which can be used to manually install or update packages using the ‘zac install’, ‘zac up’ or ‘zac dup’ commands. The properties of a Linux Dependency Bundle are shown below:
When creating a Linux Dependency Bundle you can choose to have the packages published or not. If you choose to publish the packages then these will show up in package searches and can be manually installed or upgraded using the appropriate commands. If you choose not to publish them, then the packages are only ever used for dependency resolution. It is typical to have the core operating system bundles be Linux Dependency Bundles that contain all of the bundles from a particular distribution. You can then assign that bundle to devices running that distribution and they will have access to all of the base packages for dependency resolution.
When the agent on the managed device refreshes the RPM content metadata from all of the packages that are part of the Linux Dependency Bundle are cached to the device, but the actual content files (rpms) are not. Instead the RPMs stay on the server until the user requires that RPM.
External Services Policy
The ZENworks agent is capable of using packages from ZENworks bundles (Linux and LDB), RPM-MD Repositories (YUM), and YaST/ZYPP type libraries (SUSE) for dependency resolution. If you already have the base distro packages on a Kickstart or and AutoYaST server you may want to use an External Services Policy to deploy the repository to the device instead of using a Linux Dependency Bundle. The main advantage is that you can have a single source for the operating system bundles. The properties of an External Service Policy is shown below:
From this policy you can assign one or more repositories to be automatically registered with both ZENworks and the native packaging tools on the machine. This policy can then be assigned to devices, device groups or folders so that the repositories specified are automatically added to the machine on the next refresh.
Bundle / Bundle Group YUM Repository
ZENworks provides the ability to have the packages in a Linux Bundle or Linux Dependency Bundle exposed as a YUM repository. The advantage of doing this is that devices that are not being managed by ZENworks can have access to the same packages that managed devices. There is a current limitation that there is no GPG key automatically added to the YUM repository, so you would need to either manually add one OR have your unmanaged Linux device skip the GPG key check. To create a bundle YUM repository use the following property in the bundle:
Subscription Impacts of Bundle Types
ZENworks Configuration Management provides a subscription framework that allows you to subscribe to ZYPP/YAST, Novell Customer Center, YUM and with ZENworks 11SP3 even other ZENworks zones. When subscribing to Linux package sources, you can configure what kind of bundles are created, as shown below:
When configuring the subscription to create a Linux Dependency Bundle you can choose to automatically have the packages published. The other important difference between creating Linux Bundles and Linux Dependency Bundles via subscription is that when the subscription creates an Linux Dependency Bundle it will mirror all of the available versions of the packages from the source, instead of the most recent version as happens when mirroring to a Linux Bundle. This allows for the broadest possible dependency resolution from the subscription.
ZENworks Configuration Management offers a variety of features that help to ensure applications and patches can be installed. It is important to understand each type, what it does, and how you should use it. Let me know if you have any other questions about these different types.