Fast Food:


Some of the steps described here can be done with



Can't find link to the Chef Recipe :/




Repository Setup

GPG Key for Consol Labs

Apt / Yum repository (stable / testing, etc.)

then install the omd version you want


Without repository

dpkg -i omd-version.dpkg

yum localinstall omd-version.rpm



Use OMD Module for creating a site

(Exists for Chef, probably for other CM too)


omd::site name=mysite state=exists


otherwise i.e. in ansible:

command: omd create sitename uid={{ omd_site_uid }} gid={{ omd_site_gid }}



Site Parameters

After the site is created, set any parameters you might need


omd config mysite set CORE icinga


note these need to be set in order, i.e. you first need to turn on LIVESTATUS_TCP and then set LIVESTATUS_PORT.

Alternatively, you can template all the config files as OMD does it and push them.

If you enjoy duplicate work on each release instead of working with the omd cli.


Check_MK addon packages

use CM to install any addons you might need

i.e. fetch mkp packages and 

mkp install mysql.mkp


You can also simply copy the files contained in a mkp if you don't care about the internal packaging to work

Many packages you find on github etc. aren't properly packaged in the first place.



Now you can start the site for initial access, it'll be set to the default logon settings of omdadmin / omd.

If you use HTTP auth you can play with the .htpasswd at this stage already and updated the PW before startup.

But note the integrated Multisite Auth is the way to go, so you might gain very little by sticking with basic HTTP auth.


Deploy the config

Config and the binaries, checks, etc. are strictly separated with WATO.

The easiest way is to upload a recent WATO snapshot using the WATO backup/restore option.

After it's uploaded you'll need to run a full inventory and restart.



Advanced stuff:

There is a tiny api using check_mk --automation for triggering the inventory and similarly it would be possible to programmatically call the config restore.

Even easier, you can just extract the tarballs in the WATO snapshot. If you supplant a cmk --backup tarball you will also have a recent state of the autochecks handy.

To be honest, this isn't really a smart thing to do. Let the monitoring admin decide.

If you wanna deploy a "standard" config, then make sure it only contains standard elements, so i.e. make a site that contains only rules that don't have geographic rules etc.

(This is possible, no problem)


Really advanced stuff:

  • You can also make your rules only apply under certain conditions.
  • You can of course also let your CM write rules and other things, _but_ first learn how to do it right, then come up with opinions.

Bad example:

CM writes in the conf.d/wato subfolder, clashing with anything GUI-driven, losing human updates intransparently

You'll get stuck and might not be able to run your automation ever minute (in that case, don't automate, I made the mistake, so I know...)

Good example:

CM writes a hook to conf.d/ subfolder and the hook lets Check_MK read live CM objects from REDIS on start.

(@Mpsimmons runs something like that)



Puppet is mentioned as example since Chef/Cfengine users tend to simply figure this out ;p