Updates and Upgrades

As described in the introduction, the first step with an update is the installation of the desired new version of Checkmk. This is achieved in exactly the same way as with the initial installation — it will however proceed somewhat more quickly since most of the dependent packages have already been installed. In the following example we are installing the package for Ubuntu 20.04 (Focal Fossa):

A list of your installed Checkmk-versions can be displayed at any time with the omd versions command:

One of these listed versions is marked with (default). This default version will be used automatically when creating new sites, as long as no other version is specified with omd -V myversion create mysite. When working with existing sites this is irrelevant. The current default version can be queried with omd version, and it can be altered with omd setversion:

The default version plays no role when updating or managing existing instances. The omd command always starts itself automatically in the version appropriate to the instance.

A listing of the current instances and the versions they use is provided by the omd sites command:

Once the desired new version has been installed, the instance can be updated. No root-permissions are required for this. The best way to do this is as an instance user:

Ensure that the instance has been stopped:

The update – in effect switching to a different version – can now simply be performed with the omd update command:

If more than one target version is available, a selection list will open:

When updating from a Raw Edition to the Checkmk Enterprise Standard Edition you will be alerted to that fact:

An important part of an update is the refreshing of the originally provided configuration files. Here changes that had possibly been made to these files by the user will not simply be discarded, rather they will be merged. This functions very much like version control systems which attempt to amalgamate changes made to a single file simultaneously by multiple developers.

Occasionally — when the changes affect the same location in the file — that won’t function, and a conflict occurs. How you can solve such conflicts will be explained later below.

The update provides a listing of all modified files and directories:

Once everything has been successfully processed, the instance can be switched to the new version…​

Software development of course consists of changes. Because we are always actively working to keep Checkmk modern, sometimes cutting dead weight and making changes that turn out to be incompatible is unavoidable. That means that when updating it may possibly be necessary to adapt your configuration, or you should at least check it.

A typical example of such a situation is with new check plug-ins which replace existing plug-ins. If you use one of the affected plug-ins, a fresh service discovery will be required on the affected host.

An overview of all changes in Checkmk, including a search function, can be found online in our Werks. Even more practical however is the built-in search function in the version release notes. This is accessed by clicking on the version number at the top-left of the side bar:

Checkmk tracks new changes automatically, and issues appropriate warnings if they are incompatible:

You can then inspect these ‘Werks’ (‘works’), and approve them with a mouse click. You can also find a listing covering the complete history of the changes, including a search function:

Are you curious about what exactly is happening ‘under the hood’ of an update? Or have data conflicts appeared when omd update is running? If so, here is some further reading.

Three actions take place during omd update:

Would you like to automate Checkmk’s software updates? You may at first have difficulties with the interactive responses from omd update. There is a simple solution for this scenario: the command has options that have been especially conceived for use in scripts:

Possible values for --conflict= are:

Below is an example of the complete command for an automated update to version 1.6.0p13 of the mysite instance:

Through the && before omd start a restarting of the instance will be prevented if the omd update is aborted by an error. Replace the && with a semicolon (;) if a start should definitely be attempted even in such a situation.

If you are certain that only a single Checkmk-instance is running on the server, the name to be used in a shell script can simply be trapped in a variable:

This enables the above line to be independent of the instance’s name. For example, a small shell script could look like this:

You can also upgrade a demo appliance to a full version with one of the Enterprise Editions without data loss:

An upgrade of the Checkmk Raw Edition to the Enterprise Editions is also possible. Here as well, the procedure is the same as before: install the desired pacakge, and upgrade the instances with omd update.

Since a number of modules and features of the Enterprise Editions are not available in the Raw Edition, following a changeover there are a couple of points to be aware of. The key point is that when creating new instances of Raw Edition or Enterprise Editions different default settings are set.

Since the CRE only supports Nagios as its core, this is preinstalled in instances created by the CRE. This is retained when an upgrade to the CEE is made. That means that after an upgrade, processing will initially continue with a Nagios core. A migration to the CMC is performed with omd config, and this precedure will be described in its own article.

The CEE supports an alternative format for saving historic performance data, one which requires significantly less hard drive-I/O. This is preinstalled in new CEE-instances. CRE-instances will not be changed over automatically by an upgrade. How the migration can be performed is described in its own chapter in the article covering Performance data and graphing.

The CRE has no notification spooler. Thus following the changover to the CEE it is not active at first. How to activate it can be learned here.

The uninstallation of no longer required Checkmk versions is performed using the operating system’s package manager. To do this, enter the installed package’s name – NOT the file name of the original RPM/DEB file. Important: Only delete Checkmk versions that are no longer being used by any instance!

Checkmk instances that are no longer required can simply be removed with omd rm (thereby deleting all data as well!):

Here is how to identify which Checkmk packages are being used in RPM-based systems:

The deletion is performed with rpm -e:

Use the below to identify which packets are installed:

The uninstallation is performed with dpkg --purge: