Rudder 3.2, starting from 3.2.8, offers a new package management implementation. It is new, and not as tested as the previous one, but already usable. This article explains the reason for this change, and will give an overview of the features and their usage.
Why?
As you may have noticed, the current package management implementation has some limitations, particularly in terms of managing software updates. For example the installation and upgrade was not doable in the same step in techniques, and required some workarounds.
The new method is faster and consume less resources, while providing a more reliable reporting and handling of package upgrades. They also provide a simple and more user-friendly user interface.
How?
It should be useable as of now, but is mainly a technical preview for now. Here, we will cover basic usage for it.
General overview
There is only one mandatory parameter, which is the name of the package to manage. When it should be installed from a local package, you need to specify the full path to the package as name.
The version parameter allows to specify the version you want installed. It should be the complete versions string as used by the package manager, or one of the two following special value:
- ‘Any’ version which will ignore the version criteria
- ‘Latest’ version which will constantly ensure the latest available version is installed
The architecture parameter can be left as default, to use the local default architecture on the node, or be specified. In this case, it needs to be the precise string used in the package manager for the architecture.
The last parameter is the provider, i.e. the package manager to use. By default, the default package manager of the platform will be automatically used, but it allows to select a specific package manager, and override the default value. This can be useful when using a non-standard package manager. A provider may not be mapped to a single tool but to an environment, for example the yum provider will use both yum and rpm tools.
Using the Rudder technique
A new Rudder technique called “Package Management” has been added. It uses the new implementation, and can be used for all environments (contrary to previous package techniques). The right package manager will be automatically selected depending on the system.
Like other package management Techniques, it provides a post-change command to run after each changes made on the state of the package. The directive form is:
And the reports look like the previous package management techniques:
Using the ncf generic methods
ncf now includes package_present, package_absent and the general package_state (called by the other ones) generic methods. The defined classes have the following prefix :
package_${state}_${canonified_package_name}
which does not allow reporting for multiple actions on the same package. The documentation for these methods is available in the Rudder manual (http://www.rudder-project.org/doc-3.2/package.html#package_state).
Compatibility
The new package configuration is available using a Rudder root server 3.2.7+ or 4.0.0+, with a 3.2.0+ agent. Older agents will fail with an error report if using the technique, and policy syntax validation will fail on the node if using the generic method.
Current limitations
Like everything based on ncf, the limitation on reporting for different actions on the same package stays the same. The cache duration for installed package lists and available updates is hardcoded in ncf for each package manager (in 20_cfe_basics/package_lib.cf) to one hour for installed packages and four hours for available updates (which is the most expensive call, as it generally requires updates from remote repositories).
Migration
There is currently no automated way to migrate existing configuration to these new methods, especially because the parameters are not exactly the same. For now, you need to manually create the new configuration to use this implementation.
Keep in mind you can perfectly use both methods at the same time on the same host; the only drawback will be the overhead of maintaining double caches for package information.
Under the hood
Rudder, starting from 3.2, uses CFEngine 3.7 as configuration agent, which provides a new package management implementation (https://docs.cfengine.com/docs/3.7/reference-promise-types-packages.html for more details), different from the one present in older releases. We decided to make this available in Rudder to provide a better package management option.
This implementation has been used since the release of CFEngine 3.7, and is now the default since 3.9, and old package promises are deprecated in 3.9 too. The legacy implementation stays actively maintained in CFEngine 3.7 LTS and in Rudder.
Conclusion
In the future, we will continue to improve this new feature:
- provide a way to configure the cache expiration delays for package managers on the nodes
- new implementation will continue to be polished and documented
- add new package providers, like dpkg/rpm-only providers (for cases like rpm on AIX)
Although it is still considered as a bit experimental, this will very likely become the prefered way of managing packages with Rudder, in parallel to the legacy implementation.
We would really appreciate any feedback about these features, for example with an email on the rudder-users mailing list, or an issue (https://www.rudder-project.org/redmine/projects/rudder/issues/new) if you find bugs or see a possible improvement.
