Upgrade notes

Before upgrading a Rudder server, you should make a backup by following the backup procedure.

Upgrade from Rudder 5.0

Migration from any 5.0 are supported from 5.0.16+ bugfix version and should be upgraded to at least 6.0.3 release (see below for migration from older versions).

Rudder 6.0 comes with a new reporting protocol using HTTPS instead of syslog. It is enabled by default on new installations, but upgraded instances will stay on the syslog protocol for compatibility.

You can switch between reporting protocols at any time. You have three reporting options:

  • syslog: default on upgrades, same as before 6.0.

  • HTTPS with syslog compatibility: keeps compatibility with pre-6.0 agents by using HTTPS reporting for 6.0 agents but still allowing syslog reporting

  • HTTPS: default for new installs, switches to HTTPS only, and disables syslog report forwarding, removing all Rudder-specific log configuration from nodes and servers. This should only be done once all agents are upgraded to 6.0. This allows enforcing report signature and transport through HTTPS.

For now, if you are using the Change only report mode, you cannot use HTTPS reporting yet, and have to stick to syslog for now. This will be made compatible in a future 6.0 release.

You can read more about reporting in the dedicated section.

The Rudder packages ncf, ncf-api-virtualenv, rudder-inventory-endpoint, rudder-inventory-ldap, rudder-jetty and rudder-techniques have been merged into rudder-webapp. This means that on a server upgrade from Rudder 5.0 those packages will all be removed.

This is normal!

The technique tools folder (in /var/rudder/tools), that was previously used to synchronize tools used by the system techniques is not used anymore. All tools have been migrated into the technique that used them.

The folder is left in place, but not automatically shared anymore.

If you relied on the tools copy mechanism to share files, you can replace it by a standard recursive copy from the shared files.

Rudder generic method condition from command will change its behaviour in audit policy mode starting 6.0.

Before the 6.0 Rudder version, when in audit policy mode, the method was not executing the command passed in parameters and would always report an error.

In order to limit the compliance drift when switching policy mode we chose to make the method behave in the exact same way in audit mode than in enforce mode because:

  • Audit and enforce policy mode should do the same check on the node, and differ on the remediation part

  • The method is mainly used to bypass missing components in the current generic methods library and so, not applying it in audit restrain Rudder from complex use cases

  • The command passed as parameter should always be system impact free, and so, it can be executed without impacting the overall configuration state of the node

Rudder 5.0.9 changes the default log level for the configuration server in Rudder.

This allows easier debugging and tracability of policy updates, so we enabled it by default, but will produce more logs. If you want to revert to the previous behavior (which only logs errors):

  • On systemd systems

    • Create a /etc/systemd/system/rudder-cf-serverd.service.d/override.conf file containing:

[Service]
Environment=VERBOSITY_OPTION=

  • Run systemctl daemon-reload then systemctl restart rudder-cf-serverd

    • On systems using the init script

  • Edit the /etc/default/rudder-agent file:

# You need to uncomment and let empty
CFENGINE_COMMUNITY_PARAMS_1=""

  • Restart the service with service rudder-agent restart

Verbosity options can be:

  • empty for only errors

  • --inform for basic messages

  • --verbose for very detailed logs

  • --debug for unreasonnably detailed logs

The executable /opt/rudder/bin/rudder-pkg can now be used with the command rudder package, and can now list, search and install plugins and their licenses directly from a repository.

Upgrading from versions older 5.0.16 leads to problems when removing rudder-jetty package causing the upgrade command to fail and leave rudder-jetty package in a non functionnal state.

However your Rudder 6.0 should be working, but we recommend to upgrade at least to 5.0.16 before upgrading to 6.0.

Upgrading to versions before 6.0.3 leads to several errors (service not started, ldap conf not updated to new format …​), all these bugs are fixed in 6.0.3 and you consider upgrading at least to 6.0.3.

Upgrading to 6.0.3 disables all plugins you may have installed because compatibility of previous 6.0 plugins are not compatible with 6.0.3, please reinstall your plugins to their latest versions.

Direct upgrades from 4.3.x and older are no longer supported on 6.0. If you are still running one of those, either on servers or nodes, please first upgrade to one of the supported versions, and then upgrade to 6.0.

Compatibility between Rudder agent 6.0 and older server versions

5.0 servers

There was a bug in 6.0 agents before 6.0.3 that made their inventories not fully parseable by 5.0 servers, which leads to connection errors once the node is accepted.

In this case you can either upgrade the server first or use 6.0.3+ agents.

Rudder agents 6.0 are compatible with 5.0 Rudder servers.

Older servers

Rudder agents 6.0 are not compatible with Rudder servers older than 5.0. You need to upgrade your server to a compatible version before the agents.

Compatibility between Rudder server 6.0 and older agent versions

4.3 and 5.0 agents

There was a bug in 5.0 agents before 5.0.16 that prevented them from connecting to a 6.0.1+ server.

In this case, you can either upgrade the agent to 5.0.16+ or the server to 6.0.3+.

Rudder agent 4.3 and 5.0 are fully compatible with Rudder server 6.0. It is therefore not strictly necessary to update all your agents to 6.0.

Older agents

These agents are not compatible with Rudder 6.0, and you have to upgrade them. Be careful to follow the upgrade path explained above.


← on SLES on Debian/Ubuntu →