Manage check_mk agent and partly server




227 latest version

5.0 quality score

Version information

  • 1.0.1 (latest)
  • 1.0.0
released Feb 23rd 2021
This version is compatible with:
  • Puppet Enterprise 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x, 2017.2.x, 2016.4.x
  • Puppet >= 4.10.0 < 7.0.0
  • CentOS

Start using this module


chrisonpppt/check_mk — version 1.0.1 Feb 23rd 2021


Build Status

1. Description

This module manages Check_mk agent and partly Check_mk server. It mainly provides an alternative to Check_mk agent bakery as configuration items (e.g. /etc/check_mk/…) and library items (e.g. /usr/lib/check_mk_agent/…) can be fully managed with Puppet. This is a very comfortable way of automating your check_mk agents in Puppet centralized environments, as you have now all benefits of standardization and vcs on check_mk.

In contrast to the agent, the server part is widely untouched. Check_mk server installations (and upgrades!) need a human not to mess up the whole thing. Hence, the module only lets you manage the htpasswd file for each site and lets you install required packages. Further more it provides a fact omdsites, which you can use in your profiles for more specific adoptions (such as managing the site-apache for SSO, etc.)

2. Getting Started

There is no main class (reg. init.pp). Please see server and agent parts.
Note: A node can contain the cmk server and cmk agent part at once.

2.1. Server

Start by typing

contain check_mk::server

Puppet will then install required packages. Inspect module hiera data or overwrite the param on your own.

2.2. Agent

The installation of the agent requires the package either to be located in a repo or to be available on the node. For an installation from source you have to configure check_mk::client::package_provider and check_mk::client::package_source.

Note: This module does not handle the package file management as there are too many options to implement that. It highly depends on your environment how you want to install the check_mk_agent package.

If you provide the agent package on an already included repo, start by typing

contain check_mk::agent

Puppet will then install the agent and create the library item directory and the config item directory. Inspect module hiera data for directory names.

Note: Puppet will purge all not managed files in these directories.

3. Further Configuration

3.1. Server

This module does not create OMD sites and does not configure them, as it may be very dangerous if you do it automated. Thus, please exec the omd commands manually.

To manage local htpasswd users per site you have to provide a hash for check_mk::server::htpasswd_users. Example:


  '*': # defaults for all Check_mk servers and all sites on them
    adminuser: '$1$451319$dlsdfjghlkjsfngkjnj45n63456'
    automation: '$1$451319$dlsdfgjsdfhgkjherjtgdfg'

  'main': # only for site main on
    extrauserone: '$1$453419$d3567889dfjkfdgh895435'
    extrausertwo: '$1$453419$d39dfj59789g9d8f7gsdfg'
  'integration': # only for site integration on
    extrauserone: '$1$453419$d3567889dfjkfdgh895435'
    extrausertwo: '$1$453419$d39dfj59789g9d8f7gsdfg'

Inspect the hiera docs on how to merge this data. Then you will have the adminuser and automation user in addition to the site users.

Note: You can use the omdsites fact in your profiles to automate site configs on your own (e.g. apache SSO, etc.).

3.2. Agent

Please see Reference for all params.

3.2.1. Encryption

To enable encryption:

check_mk::client::encryption_passphrase: >
  ENC[PKCS7, kdjfvkuwezriusdfhudf879845u6ojhgkhdfg987598ukdjsgh98w7e56…]

3.2.2. Defaults for library items and configuration items

Optional: It is useful (and recommended!) to provide the default locations for configuration EPPs and library items. For example, this extra repo could be your control-repo.

check_mk::client::library_item_default_file_source_path: 'puppet:///modules/<my_extra_repo>/check_mk/client/'
check_mk::client::configuration_item_default_epp_path: '<my_extra_repo>/check_mk/client/'

If you don't want to use EPPs and file source deployment for library items, you can provide a string (the content) for each file (see below).

3.2.3. Plugins (library item)

This example requires the library items in your file store (see above). One could provide the plugin file contents as plain text here as well. Please see Reference for detailled information.

    exec_interval: 3600
      - 'python3-fancy'
      - 'python3-wow'

Inspect the hiera docs on how to merge data and how to extend the baseline of plugins from common.yaml in node.yamls.

3.2.4. Plugin Configs (configuration item)

This example requires a valid epp for apache_status in you default epp store (see above). Instead of giving a hash, one could provide the config file contents as plain text here as well. Please see Reference for detailled information.

      protocol: 'http'
      host: 'localhost'
      port: 80
      protocol: 'https'
      host: 'localhost'
      port: 443

3.2.5. Local Checks (library item)

This example requires these library items in your file store (see above). One could provide the check file contents as plain text here as well. Please see Reference for detailled information.

      - "nmon"
    exec_interval: 3600
    content: "#!/bin/bash\necho new line is working!\n"

3.2.6. Logwatch

One could provide a baseline config in common.yaml…

    - 'C .*I/O error.*'
    - 'C .* segfault at .*'

… and extend it in specific yamls:

    - 'W This is a Warning:.*'
    - 'C java\.lang\.OutOfMemoryError:.*'

Inspect the hiera docs on how to merge this data.

3.2.7. Other

One could also deploy library items and configuration items directly per Puppet DSL…

::check_mk::client::configuration_item { 'extra_config':
  mode   => '0400',
  config => 'my content',
::check_mk::client::library_item { 'extra_lib':
  library_path => 'plugins',
  content      => 'my content',

… Or in hiera:

    mode: '0400'
    config: |
    mode: '0400'
    config: |
    library_path: 'plugins'
    content: |
      echo 'my plugin'

4. Limitations

  • Does not manage xinetd oder systemd socket. There are extra modules for that purpose, see here and here
  • Does not install or configure omd packages or omd sites. See above.
  • The Agent part is verified on Ubuntu >= 14.04 and CentOS 7
  • The Server part is verified on Ubuntu >= 18.04
  • It should work on all Debian based and RedHat based distros :smile:

5. Development

Any contributing is welcome! Please open a issue or create a pull request on Github.