Check mk windows agent

Monitoring agents

On this page

Related articles

Most read articles

Search in the manual

1. Introduction

For a monitoring system to receive more information from an endpoint other than that it is accessible, help is required from the target system. For example – how else can Checkmk know how full a server’s storage volume is without that system somehow providing the information? The component that provides this information is always an active piece of software – namely an agent.

There are situations where one does not need to install an additional agent – since one that can be used is already present. The best example here is SNMP. All manageable network devices and appliances have a built-in SNMP agent.

As always, there is an exception: the monitoring of network services. For example – by its nature a web application can be accessed via HTTP and be monitored over the same connection. But even in this case there is usually an additional agent in use which provides further server data to the monitoring.

The following table shows the four different ways that Checkmk can access services to be monitored:

Method Description Prerequisite SNMP Checkmk accesses the target device’s existing SNMP-agent. With active queries (GET) it collects details on the system’s condition. SNMP-Agent enabled Checkmk-Agent Checkmk has its own agents for servers and workstations. Eleven different operating systems are supported – from the commonplace like Windows and Linux to exotics such as OpenVMS. The agents are passive and connect to TCP Port 6556. Only on receiving a Checkmk server query will they be activated and respond with the required data. Checkmk-Agent installed Special Agent Some systems allow neither an agent installation, nor do they support SNMP in a usable form. Instead of these they offer Management-APIs based on TELNET, SSH or HTTP/XML. Checkmk queries these interfaces via special agents that run on the Checkmk-Server Create an API account for Checkmk Active Checks Network-based services such as HTTP, SMTP or IMAP can by their very nature be queried via the network. For this Checkmk sometimes uses its own, sometimes existing plug-ins originally developed for Nagios. For example, check_http is very popular for querying websites. These are described as Active Checks. None

1.1. Monitoring by events

Until now we have only discussed active monitoring – Checkmk’s showpiece discipline. There is also the reverse method: namely that by which the target system itself sends messages to the monitoring, e.g., via syslog or SNMP traps. For this entire subject Checkmk has the Event console which is described in its own article.

2. The Checkmk agent

2.1. Download and installation

As described, you require a Checkmk agent in order to monitor servers and workstations. Agents for eleven different operating system families are currently maintained in the Checkmk-Project. All of these agents are components in Checkmk, and are available for downloading via the Checkmk-Server’s Web-GUI. Additionally, in the Enterprise Editions there is the Agent Bakery. This enables you to ‘bake’ your own agents containing a personalised configuration and collection of plug-ins. This can even be done individually and differently for each host.

2.2. Installation via the download page

The agents are accessed via the WATO-module Monitoring agents. In the Enterprise Editions, you will be brought to the Agent bakery. From there the Agent files button then takes you to the download page for the agents and their plug-ins. The Raw Edition takes you directly to the download page:

The packeting agents for Windows (check_mk_agent.msi) and Linux (.deb or .rpmu files) are found right in the first section. After installing these packages the agent is basically ready to run, and you can begin monitoring. All further configuration is achieved via configurations data, and plug-ins are installed by downloading them from the same page and copying them into the appropriate folder.

2.3. Details of agents for specific operating systems

The agents’ structure, configuration and capabilities vary depending on the operating system. For this reason details for specific agents can be found in their own articles:

• Monitoring Linux

• Monitoring Windows

• Monitoring UNIX

3. Installation via the Agent Bakery

3.1. Introduction

While it is true that the Checkmk agent can function ‘naked’ immediately – without needing configuration, and without plug-ins – nonetheless in some cases the agent does need to be set up. Some examples:

• Restriction of access to specific IP-Addresses
• Monitoring of ORACLE data bases (plug-in and configuration are required)
• Monitoring of text log files (plug-in, data names and text-pattern required)
• Utilization of the Checkmk inventory system (plug-in required)

If you have one of the Enterprise Editions you can package personalised agents with the Agent Bakery. In this way, alongside the existing agents, you can also create agent packages that contain configurations and extra plug-ins. These packages are ideal for automatic-distribution, however, they can also be installed manually. You can even create personalized agents for specific groups of hosts. This allows great flexibility through the use of the automated agent deployment.

The bakery is accessed via WATO вћі Monitoring agents:

If you have not yet made settings for specific hosts, there is only a single default agent configuration. With the Bakery Checkmk version 1.6.0 supports the Windows, Linux, Solaris and AIX operating systems. For Linux you have a choice between the packet formats RPM (SUSE, RedHat, CentOS), and DEB (Debian, Ubuntu), as well as a tarball that is simply unpacked as root under /. Likewise, a tarball is available for AIX, however this does not include automatic integration into the inetd. The integration must be performed manually as a one-off action. For Solaris there is again the tarball and a PKG package.

Every agent configuration has an explicit ID: its hash. A hash’s first eight characters are displayed in the GUI. This hash will be a part of the package version and embedded in its file name. Whenever you change something in a package’s configuration or update Checkmk, the package’s hash will also be changed. In this way the operating system’s package manager recognizes that it is an update. Checkmk’s version number would not suffice in such a case.

3.2. Configuration via Rules

The agent’s configuration can be altered – as is so often the case in Checkmk – via rules. These offer you the possibility of equipping different hosts with differing settings or plug-ins. Via the Rules button you can access a page which lists all rule sets that affect the agents:

Let’s take the following example: you wish to limit the list of IP Adresses that are permitted to access the agent. For this you select the Generic Options ➳ Allowed agent access via IP address rules set. Enter one or more IP adresses as the rule’s value:

After saving with , return to the Agent Bakery. The button ensures that the agent will be freshly baked. The result – you now have two configurations:

In the Hosts column you will find a list of hosts associated with the relevant configuration. For space reasons the full list is abbreviated here. The VANILLA and GENERIC names have a special role. These two pseudo-hosts are always present and have the following functions:

VANILLA A virtual host whose agent contains only the default configuration, to which therefore none of the agent rules apply. GENERIC A virtual host to which ALL rules with no defined additional conditions apply. The GENERIC entry is especially useful for installing agents on hosts that have not yet been incorporated in the monitoring.

The more host-specific rules you deploy, the more different versions of agents will be built. The bakery makes sure that only such combinations of configurations are built that will be used by at least one of the available hosts.

By the way, in WATO you can also easily access a host’s agent packages via the host’s Details and the Monitoring Agent button:

Why are packages for all operating systems offered for every host? The answer is very simple: if no agent is installed on a system Checkmk naturally cannot recognise the operating system! In any case, once automatic agent updates are activated you don’t need to do anything more.

3.3. Plug-ins

Many rules are concerned with the installation of various plug-ins. These extend the agents for the monitoring of quite specific components. Most of these are special applications such as data bases, for example. Alongside the rule that activates a plug-in you will also find the settings for configuring the plug-in. Here, for example, is the rule for monitoring MySQL:

3.4. Customising agents manually

Please note that on the target-system you do not manually modify the configuration files of an agent that was created by the Bakery. This will work at first, but the next update of the agent will cause the the changes to be lost. However it is possible to install additional plug-ins without problems.

4. When should an agent be updated?

Regardless of whether you monitor only a handful – or even thousands of hosts – management of the Checkmk agents on all hosts is always a larger operation. The automatic update of the agents in the Enterprise Editions is however a big help. Nonetheless, you should really only update the agents when:

• the update solves a problem affecting you, or
• the update includes required new functions.

In order for this to be possible a general rule applies in Checkmk: newer Checkmk-versions can fundamentally handle the output of older agents.

Note: the reverse is not necessarily true. If an agent’s Checkmk version is newer than that of the monitoring server it is possible that the output of the target agent’s existing check plug-ins cannot be properly interpreted. In such a case the affected services go into an UNKNOWN (please do not send a Crash-report in such a situation):

5. Error diagnosis

5.1. Testing agents via the command line

Although the agents for the various operating systems were independently developed, from Checkmk’s point of view they all behave in the same way by opening the TCP port 6556 for queries from the monitoring server. The query protocol is absolutely simple: the server connects to the port and the data flows in a readable text format from the agent. As soon as the data transfer is completed the agent disconnects itself from the port. The agent basically reads no data from the network!

A correctly-installed agent can be very easily queried from the command line. The best way is directly from the Checkmk instance that is also actively monitoring the agent. In this way you can be certain that the server’s IP address will be accepted by agents. A suitable command is e.g. telnet:

With nc or netcat the data is returned ‘naked’. This is useful for example, if you wish to use a script to process the data:

The output always begins with the line >>. Lines included in >> are called Section Headers. These divide the agent output into sections. Each section contains related information and is usually simply the output from a diagnosis command. The check_mk section plays a special role. It contains general information about the agent such as e.g., its version number.

If the host is already being monitored you can also fetch the data with the cmk -d command. This uses the IP address configured via WATO, allows for a possibly reconfigured port number, and also the case of a special agent:

If monitoring is already running regularly for the host in question a current copy of the output can always be found in the tmp/check_mk/cache directory:

5.2. Diagnosis via the GUI

You can also conduct a diagnosis of the agents via the GUI. This takes all settings into consideration and also supports SNMP devices and those queried using special agents. In effect, Checkmk simply attempts to always query via TCP-Port 6556 and SNMP simultaneously. You can access the details of a host’s diagnosis with the Diagnostic button in WATO:

Источник

Automatic Agent Updates

On this page

Related articles

Most read articles

Search in the manual

Checkmk can update its agent on Linux, Windows and Solaris automatically. With it you can not only easily update the agents in the case of new Checkmk versions, even a changed configuration of the agents can be applied in this way. In this way you can take advantage of the Agent Bakery function to apply individual configurations to hosts.

1. Setting up automatic updates

The automatic deployment of agents is globally disabled by default. So before you take care of the configuration itself, enable the Activation of automatic agent updates option under WATO вћі Global Settings вћі Automatic Agent Updates.

To set up the updates, follow these steps: First select the Monitoring Agents WATO module, and then click on the Automatic updates button.

See Prerequisites for a list of prerequisites that have to be met for the automatic updates to work. These you can just tick off in turn. Please do not forget that there is also an online help for all sites, where all points are explained in more detail. Clicking on takes you directly to the section in WATO where the appropriate configurations must be performed. In detail, the following elements must be configured:

1.1. Creating a signature key

The system is so designed that the agents can download updates via HTTP or HTTPS from their central monitoring server. Because agents contain executable code it is especially important to guard against the possibility of falsified agents coming from an attacker. Signature keys are used for this purpose. These keys consist of a pair of public and private keys (the public-key method).

You can create as many signature keys as you like. Each of these is secured with a passphrase, which you will subsequently need to enter each time you sign. This prevents, for example, an attacker gaining access to a backup of the Monitoring server which agents could sign.

Create a signature key here and record the passphrase. This passphrase can later neither be changed nor restored. If the key is lost, it can mean that all agents need to be updated manually once again!

1.2. Configuring the Update Plug-in

The actual update is performed by an agent plug-in named cmk-update-agent. This is done by the agent in a definable cycle (e.g. once per hour). At this time the agent asks the deployment server (your central monitoring system) if there is a new package available for this host, and if so it will then perform an update.

The plug-in must of course be present and correctly configured in the agent. To do this, extend the agents using the Agent updater (Linux, Windows) rule set around this plug-in. Please note that the rule set here follows the ‘First rule per parameter wins’ principle. This allows you to define basic settings in general so that they do not have to be reset again and again in the more specific rules. In addition, of course, the online help provides more information about each item as soon as you activate it.

Below are a few explanations of the individual points:

Activation

This setting must be enabled (Deploy plugin . ) to allow the plug-in to be added to the agent. Here, for example, rule inheritance can be used to set a default in a higher-level WATO folder and override this for individual hosts/folders as needed.

Interval for update check

Here you specify the interval in which the agent updater queries the configured monitoring server whether any updates are available. As long as the specified interval has not expired, a cached call is returned, so as to burden the network load as little as possible. It usually makes sense to use an interval of not less than 10 minutes, otherwise there is the very great danger that your network will be very heavily burdoned. If you do not set a value here a default value of 60 minutes will apply.

DNS name or IP address of update server

Here you enter the DNS name under which the Checkmk server is accessible. It is important here that the host to be monitored can resolve this name and that it is configured as a host in Checkmk. Take care when using HTTPS that the name of the certificate matches the name of the Checkmk server as known to the host.

Important: If you have a distributed WATO enter here the server on which the master instance of Checkmk can be reached. See also the section on Deployment in a distributed WATO.

Name of Checkmk site of update server

Here you enter – with a few exceptions – the name of the instance on which you are currently configuring this rule. An exception to this approach would be if the affected hosts should be ‘moved’ to another Checkmk instance. In this case, for one time only, enter a different site here. See also below under Application Scenarios.

Encrypted communication for updates

If – as we recommend – you use HTTPS you also need to specify a root certificate at the same time. With this the agent updater can verify the Checkmk server’s certificate chain, since it cannot access the locally-installed root certificates.

Important: Depending on the configuration of the server, it may be that HTTPS (including forwarding from HTTP to HTTPS) will be forced. If in such a situation HTTP is nonetheless configured, the Agent Updater will actually try to build an unverified connection and will not accept a connection via HTTPS. See also here under The connection via SSL/TLS does not work.

Proxy settings

This rule setting is likewise optional. The Agent Updater assumes that there is a direct connection to the Checkmk server and it will ignore all local proxy settings – even if proxy settings have actually been configured on the destination host. If this is the desired behavior this rule setting can therefore be omitted. Otherwise either enter proxy settings manually, or use the host’s existing environment variables.

Executable Format (Linux)

Since version 1.5.0 you can optionally specify how the plug-in is added to the installation package for the agent. How the rule behaves by default depends on the target system:

• Linux (deb, rpm, tgz): You do not have to manually adjust anything for these systems; the agent updater is passed as a 64bit binary. You can also optionally select a 32bit binary for legacy systems, or the old Python script. Important: For the binary you need the glibc package (minimum the 2.5 version). Linux distributions have generally met these requirements since 2006.

• Windows: For Windows hosts Checkmk will always deploy a 32bit-executable. This rule is being ignored for Windows hosts. Note: Should you find a 64bit binary of the agent updater on any of your Windows hosts, this version dates back to an older version of Checkmk and is not up-to-date.
• Solaris: You do not have to adjust anything here either. Checkmk will use the Python script even if you leave the default value on the 64bit binary.
• Other architectures: If you have packages for other architectures such as arm or ppc, set this option manually to the Python script, since Checkmk does not intercept this automatically and no binaries are offered for these platforms.

If you still need to rely on the old Python script the following requirements apply to the system:

• Python2 in Version 2.7.13 or newer
• The Python-Modules requests, requests[socks] and pyOpenSSL

Signature keys

Select at least one signature key whose signature should be accepted by the Agent Updater. You can also optionally specify multiple keys. This can be the case if, for example, you want to disable an old key. For this purpose the host’s agent updater must in the interim accept both keys.

1.3. Baking agents

If you have adjusted the packaging rules in the agent bakery, you’ll notice that the Bake agents button will be highlighted in orange. The created and adapted rules will only then found in the installation packages after you create/bake them again. Once this process has been completed you will receive a confirmation:

1.4. Signing agents

Next, sign the agents with the key created in step 1. For this you need your passphrase for the first time. After you have successfully entered this passphrase the signed agents will be identified by a . If you have created multiple keys, the signature is done separately for each key. Important: An agent updater on the hosts to be monitored is satisfied if the new package is signed with one of its known keys.

Each time you later update the agent packages and rebake them, the signature is removed and must be recreated.

1.5. Registering agents

In the next step register the hosts to be monitored on the Checkmk server. Since a new host is not yet trusted by the Checkmk server, and the server does not yet know that the host should be updated automatically, the agent must be installed manually – once-only – on the host. To do this download the package for the host from the WATO at Monitoring Agents. Make sure that the package also contains the Agent Updater plug-in.

Now copy the package to the host and install it as usual with rpm, deb or msiexec (or with a double-click as applicable). The Agent Updater plug-in will then be found in the host’s plug-ins directory:

• Under Unix-like systems – in the path /usr/lib/check_mk_agent/plugins/[configured interval]/ (Since version 1.6.0 a script of the same name is also stored under /usr/bin, so that cmk-update-agent is also available as a command.)
• Under Windows – before version 1.6.0 in the agent’s installation file path – usually under C:\Program Files (x86)\check_mk\plugins\. Since version 1.6.0, the agent updater’s executable code is located at C:\ProgramData\Checkmk\Agent\plugins\.

Now call the Agent Updater with the register argument. Under Windows this must be done in a prompt with administrator rights. Enter the required information in sequence (if you have have installed a baked agent, not all settings are needed):

Important: As of Checkmk 2.0 the agent updater for Windows hosts will be executed by the agent itself instead of being a standalone program. The command will hence be slightly different:

Alternatively, you can perform the registration in non-interactive mode by entering the required data via the command line option. A call to the cmk-update-agent register--help here shows the settable options. Noteworthy here is that the one-time registration can also be made via an Automation-User – in this method the user is as usual passed via -user/-U, and the automation secret is passed via -secret/-S.

Some notes about registration:

• When registering the plug-in also needs the name of the host as it is known in the monitoring. This is not necessarily identical to the host name of the computer. The host name is then stored locally together with the key.
• To use HTTPS, HTTPS must be set up on your monitoring server. HTTP is much easier here, but does not provide encryption of the transmission. Since the agent can theoretically contain passwords, HTTPS is the recommended method. The authenticity of the agent is however ensured independently by the signature.
• The login as a WATO user is only required once. On registration the agent and the server agree a secret key known only to this host. The password of the WATO user is not stored anywhere.
• While the interactive mode only polls fields that are not yet in any configuration, the non-interactive mode allows all fields displayed in the Help to be set and has the highest priority for this call. Options that are saved in cmk-update-agent.state will be overwritten, but options from cmk-update-agent.cfg will not be overwritten. See also below Viewing the Local Configuration.

After a successful registration the key is stored at the agent in the file /etc/cmk-update-agent.state. On the server it is located in

/var/check_mk/agent_deployment/myhost. From now on the key allows the host to download its own agents from the server without a password. It is not possible to download agents from other hosts, since these could contain confidential data.

1.6. Master Switch

Finally, enable the agent by clicking at the Master Switch. The table Prerequisites should now look like this:

From now on, once during each update interval, the agent will connect itself and check for a new version of the agent. If a new version is ready, and signed, it will be downloaded and installed automatically.

A step-by-step guide is also provided by the video which originated at the Checkmk Conference #3 (2017), under the following link. This is not the latest version – however the basic procedure has not changed: The new automatic agent updates

2. Restricting updates to specific hosts

Before rolling out a new agent to a large number of hosts, you will certainly want to first try it out with a smaller number of hosts. This important step prevents a possible mistake of serious dimensions.

For this function, use the middle box on the Automatic agent updates page:

After you have met the conditions for selecting hosts here, you can use the field Test with this host name to enter individual hostnames and check if the updates for these hosts have now been enabled or not. The conditions are always connected with and.

At the same time of course, the Master Switch is also one way to turn off the updates globally.

Important: Hosts that are not yet to be provided with automatic updates, of course may not include the Agent Updater plug-in – otherwise the plug-in will regularly warn you that the host has not yet been registered.

3. Diagnoses

There are quite a few sources of information for diagnosing whether all updates work as intended:

3.1. Statistics on the Automatic agent updates page

This overview shows how the individual hosts in the agent update behave. The online help gives further explanations. Clicking on provides a detailed list of the individual hosts. You can also get to the complete list of all registered hosts via the Monitoring Agents вћі Automatic updates вћі Update status view. There you can then search for specific individual hosts.

For an agent intended for a host (Target Agent) – which was last downloaded from the host (Downloaded Agent), and which is currently installed on the host (Installed Agent) – this list will also show documentation on how the agent’s hash begins. In this way you can always see if the specifications have been met or where the process is currently located. It should be noted here that the status information appears to the left directly in the communication between agent Bakery and Agent Updater, while the Update Check and Update Check Output fields come from the Agent Updater plug-in when querying the agents of the host, and that due to caching (defined by the polling interval) these may be updated at a different time.

3.2. The new Check Checkmk Agent on each relevant host

If you have installed the update plug-in on an agent, this will regularly produce the current status of the update in the form of monitoring data. The service discovery generates a new service from the host with the name Checkmk Agent. This again reflects the current state of the update. Using monitoring alerts you can enable notification of a problem with the updates.

This check’s state is limited to a severity of WARN.

3.3. Viewing the local configuration

The behavior of the Agent Updater is governed by the two files cmk-update-agent.cfg and cmk-update-agent.state. It always applies that set values from the .cfg file override those from the .state file. If the Agent Updater shows unexpected behavior, it is sometimes worth having a look in the configuration. There is also a handy feature if you call the agent updater directly from the command line:

3.4. Log messages on the destination host itself

In the case of a problem you will also find log data for the updates on the host to be monitored. On Linux cmk-update-agent logs important information to syslog – such as warnings and errors. A more detailed log, including debug outputs and possible tracebacks can be found under /var/lib/check_mk_agent/cmk-update-agent.log. Likewise, under Windows a detailed log will also be in the file log/cmk-update-agent.log. Under both systems you can also use the command line option --logfile LOGFILE to specify an alternate path for a debugging log.

4. Application scenarios

4.1. Deactivating automatic host updates

If a host is to be removed from the automatic updates, alter its setting with the Install agent updater (Linux, Windows) rule set so that the update plug-in is deactivated there. At the next regular update the agent itself then removes its own updater!

It goes without saying that the update can then only be reactivated by the manual installation of a new agent package! The registration is retained and does not have to be renewed.

4.2. Migrating to a new monitoring instance

Should you want to move to a new Checkmk instance without losing the hosts registered on the server, it should be noted that for a successful agent update process the following information on server and host must match:

• The name under which the host is monitored and registered
• The host secret that was granted at registration.
• The signature used to sign the agents

To achieve this, follow these steps:

First add all hosts whose registration information is to be migrated to the new instance to the monitoring. Make sure the hosts in the new instance are monitored under the same name. Then copy the

/var/check_mk/agent_deployment folder from the old to the new monitoring instance.

Export the signature key(s) that are accepted by the agents installed on the hosts to the new monitoring instance. The signature keys can be exported and imported using Monitoring Agents вћі Signature keys.

Configure the agent updater rule on the new monitoring instance according to the instructions, and sign the baked agents with the imported signature key(s).

Lastly, in the agent updater rule on the old instance, configure the fields for the update server and the name of the Checkmk instance conforming to your new monitoring instance, and bake the agents again. Note: Please check at this point that you have specified everything correctly before you re-bake the agents.

As soon as the next automatic updates go through the hosts, the old monitoring instance will be locked out. From that time on the hosts to be monitored will only answer to the new Checkmk server. Following the second automatic update the agent will be installed by the new Checkmk server accordingly.

4.3. The Agent Updater as automatic installer

Note: This is not an official feature of the Agent Updater. These instructions are therefore intended primarily for more experienced users. The official way to install a Checkmk Agent on a host is to download and run the agent package appropriate for the system. It is however also possible to allow the Checkmk Agent to be installed initially by the Agent Updater, since this also works as a stand-alone program.

Proceed as follows:

Copy the cmk-update-agent binary or the cmk_update_agent.py script to the host to be monitored (both can be found at

/share/check_mk/agents/plugins on the Checkmk server).

Register the host on the Checkmk server by invoking cmk-update-agent register. Here it makes sense to pass the required registration information directly via the command line – especially if you want to use an installation script. The corresponding options can be displayed when calling cmk-update-agent register--help.

Then, with a final call to the agent updater plug-in, install the agent with all of the configuration details for the host being monitored. However since there is no local configuration (the Agent Updater also displays a corresponding warning), and thus no signature for the agent package to be downloaded, call the updater once more with cmk-update-agent--skip-signatures to explicitly trust the downloaded package. The prerequisite for the installation by Agent Updater is, of course, that the Agent Bakery has a suitable agent package ready for the target host on the Checkmk server.

5. Agent updates in distributed monitoring

If you are running a distributed monitoring with multiple instances, the updates are thus provided exclusively by the central server. A distribution of the agents on slave servers is not (yet) planned in the current implementation.

6. FAQ

6.1. Typical errors and their solutions

Already fixed errors in the Checkmk Agent service

The Agent Updater will really only be run once within the update interval, so an error will be continuously-displayed until either you call the plug-in manually, or the next interval is pending.

H:Registration fails after a manual reinstallation of the Checkmk agent

The Agent Updater creates its own status file cmk-update-agent.state independently (under Linux/Unix in /etc, and under Windows in the config folder). This file remains on the host after a deinstallation, so that the registry information does not get lost. A new installation will find the file and continue using it. If this situation is undesirable, after a deinstallation simply delete the cmk-update-agent.state file manually.

Update status for hosts with no automatic updates active

The Agent Update Status page displays all of the hosts that are are in the monitoring and for which a status file exists on the Checkmk server. It does not matter if the host actually reports to the Checkmk server for automatic updates. Should an unexpected host be displayed here, it is worth taking a look in the /omd/sites/mysite/var/check_mk/agent_deployment folder – the cause is probably an old or accidentally-created registry.

The connection over SSL/TLS does not function

The Agent Updater is designed to explicitly trust only the certificates which are usually specified under Agent updater (Linux, Windows) in the HTTPS configuration. In particular locally-installed certificates are ignored. It can also occur that the Checkmk server is accessible through the browser, while the agent updater cannot connect due to a wrong configuration.

In the HTTPS configuration of the Agent Updater rule a root certificate must be specified with which the connection to the Checkmk server can be verified. In other words: the certificate chain included in the Checkmk server’s server certificate must be verifiable by the certificate given here. Often the server certificate is specified here instead – this is however not suitable for this purpose.

Take a look at the Checkmk server’s certificate chain with the OpenSSL tool. Due to the chain’s length here only a relevant section is shown and the abbreviated sections marked by [. ]:

For the last entry – in our case subject=/CN=mymonitoring.example.net – you need a valid root certificate. This must not necessarily – as in this example – be the issuer of the certificate. It will usually be a chain of issuers.

Then look at the certificate used. Here too due to the length it will be shortened as seen above:

The top certificate – seen in the above excerpt – is not permitted to have a dependency on another certificate. You can recognize that the issuer (Issuer) and the item (Subject) are identical and that the option CA:TRUE is included. In addition the issuer’s chain that authenticates an object must be consistent until the last entry. You therefore also need all intermediate certificates if the issuer of the last certificate should not be a CA.

A detailed insight into this whole topic is also provided by the following video, which was created at the Checkmk Conference #4 (2018): SSL and Certificates

Error message: Cannot open self cmk-update-agent or archive cmk-update-agent.pkg

On some Linux systems the program Prelink is installed and a cronjob is activated which regularly examines all binary files on the system, and adapts them if necessary to speed up the programs. However the Agent Updater plug-in is packaged with the PyInstaller program which is not compatible with such actions, and is therefore broken. Checkmk therefore has a blacklist entry for deb/rpm packages which is stored under /etc/prelink.conf.d, and – if prelink exists – sets an entry in the existing /etc/prelink.conf file. Since this problem is difficult to handle, it can still happen – especially in the case of a subsequent setup of prelink – that these measures do not take effect.

Therefore, if you install prelink later, set the entry yourself and add the following line to the file with the following command:

Error message cmk-update-agent: error while loading shared libraries: libz.so.1: failed to map segment from shared object

This error message occurs when the /tmp directory with the flag noexec was mounted in the system. With this problem you can either remove the flag, or – if you deliberately set and require the flag – on the Checkmk server in WATO create a rule under Monitoring Agents вћі Rules вћі Installation paths for agent files (Linux, UNIX). There you can define the tmp directory in the Directory for storage of temporary data (set TMPDIR environment variable) option yourself. The Agent Updater plug-in will then in future write temporary files in the defined directory. That works even if you call the plug-in manually with the helper script in /usr/bin/cmk-update-agent.

Источник