Mastering package holds
Landscape’s new release brings to full circle the changes that began a few months ago, beginning with the deprecating of support for Smart package locks: with full APT integration in the client, we are now exposing dpkg holds as first class citizens.
Package holds exist to stop a package from being updated, the most typical case being the commonplace sudo apt-get upgrade mass-upgrade command. We could use package holds to instruct the update stack not to modify my system’s currently installed version of Python:
echo "python2.7 hold" | sudo dpkg --set-selections
and good old dpkg would oblige. What we have done here is changing the dpkg policy for this package’s upgrades from the default install to hold, the system does the rest, and stops offering us updates for this package. Similarly, I can set a hold on a package from Landscape, and on a broader selection of our datacenter assets. in this case, let’s select the venerable AWK:
All I had to do was click the package icon on the right and applying the change – in Landscape, doing this for a lone machine or a fleet of thousands takes the same time and effort. In a minute, Landscape confirms successful execution:
What’s more, the very same hold Landscape configured is now visible at the shell level on the client system, in a seamless display of integration between dpkg and Landscape – here is the shell view before and after the command was issued:
Once a hold is in place for a package, regular system upgrades will not change the installed version, even when a newer version becomes available in the configured repositories – regardless of where the update command was issued from, Apt or Landscape. This provides administrators with a convenient way to protect themselves from accidental mistakes: when a workload is known to be dependent on a specific package version, holds make the system track and enforce this requirement for you – a more reliable and stress-free approach than post-it notes, spreadsheets, or the shared oral culture of your IT team.
A fairly common scenario exposing additional nuances is holding the kernel version. If a kernel update is made available, two scenarios are possible. In the simplest case, a new build of the kernel is available, with changes that do not impact the kernel ABI, and the installed package name would remain the same – for example, linux-image-3.2.0-23-generic-pae, with version going from 3.2.0-23.35 to 3.2.0-23.36 for the new build. Holding this package name will block minor kernel updates that remain ABI-compatible.
The second scenario is more interesting. When the kernel upgrade involves an ABI change, Ubuntu’s Kernel team will introduce a new package, with a different name, like linux-image-3.2.0-24-generic-pae, and as this is a differently named package, the hold on the previous version will not block this new install. The key to restricting kernel upgrades involving an ABI change is in holding the kernel metapackage upgrade, which is triggering the new install through its dependencies.
On my system, I use the linux-generic-pae kernel flavour. Holding the corresponding metapackage does the trick:
echo "linux-generic-pae hold" | sudo dpkg --set-selections
Holding the metapackage upgrade restrains the system from upgrading to the latest kernel with the new ABI — but will allow ABI-compatible upgrades if any become available. This is reflected both in upgrade selections managed by apt-get upgrade, and remotely by Landscape, as you can see graphically in Landscape’s interface:
To complete our hold master class, we should point out that holds are designed to block package updates, not new installs. If you instruct dpkg, apt-get or Landscape to specifically install a given package, your instructions shall be obeyed. The system is designed with the assumption that you know what you are doing, and holds are used to manage the update system’s behaviour, not to stand in the way of the admin.
We want the user experience of Landscape’s centralized console to reflect the interaction an administrator has with the terminal of a single Ubuntu system: following a Principle of Least Surprise philosophy in our design, we leverage your existing Ubuntu architectural knowledge as much as possible. This way, we can reflect the user’s expectation of Ubuntu’s behaviour, and flatten Landscape’s learning curve. To accomplish this, we rely as much as possible on Ubuntu’s built-in default interfaces to the system’ state, like lshw or dpkg, as data sources and management interfaces for the Landscape client.
And those are package holds. Now just one click away in Landscape.
Cross-posted to the Landscape Blog.