Alarm and alert handler scripts (also in Shell or other Script languages)

All of these enhancements are effected by saving your own data in the ~/local folder
in a Check_MK instance. In order to manage these extensions effectively, to roll them out from
distributed environments, and also to enable these to communicate with other users, Check_MK provides
its own package format: the Check_MK extensions package - the MKP.

An MKP can collect any number of extensions - e.g., a set of check plug-ins including handbook pages,
WATO masks and metric definitions. The MKP has a name, a version,
and can be installed or likewise subsequently deinstalled with a simple action.

1.1. The Check_MK exchange

Users can submit user packages for the community to share on
the Check_MK Exchange site.
From here free extensions can be downloaded for your use.
Please be aware that packages in the exchange have been voluntarily submitted by other users
and are therefore provided without any kind of guarantee. It is possible that these have not
been correctly programmed and can cause problems with your Check_MK version.
MKPs can naturally also contain errors that can lead to all sorts of problems and even to data loss.
It is strongly-recommended to first trial all externally-provided packages on a test system.

1.2. Tools for MKPs

The are two tools for managing MKPs:

The command line command mkp

The [icon_mkps.png] Extension Packages (only ) WATO module

We will now look at both of these procedures. They are compatible, so that sometimes one,
or sometimes the other can be used without getting "mixed up".

2. Managing extension packages using WATO

From version 1.2.8 WATO has offered the new Extension Packages module,
with which MKPs can be managed and also be modified or created. This module can be accessed, as usual, via the
WATO element in the sidebar:

2.1. Installing an MKP

An MKP, for example, that you have downloaded from the Exchange, can be uploaded and installed
by using the Upload Package button. You will also need the data on the computer
on which your web browser is running. The data set name must have the .mkp extension.

During the installation the data sets will be installed in the correct locations under ~/local/.
In addition, a package description file will be saved in ~/var/check_mk/packages/.
Following the upload the package will appear in the list of installed MKPs:

Finally, you require only an Activate Changes, with which all of the package's functions will
be anchored in the system and ready for use:

2.2. Deinstalling packages or releasing their files

Using the appropriate symbol in the package list you can either delete
a package or release its files. With a deletion the package with its
installed files and extensions will be removed - the opposite of an installation so to speak.
A release on the other hand leaves the package's data under ~/local/ quasi free and
removes only the package description - the result being that the files are unpackaged and the
extension remains active. This is the opposite to creating a package.

2.3. Creating packages

Creating your own MKP is very simple (not considering the small matter of the
extension first having to be coded, naturally). The starting point is that your own data sets
have been saved to the appropriate folders under ~/local/.
For own check plug-ins the correct folder is, for example, ~/local/share/check_mk/checks.
These data sets at first belong to no package and thus will be listed under Unpackaged Files:

Via the symbol you can access the dialogue for creating a new package:

Alongside the obvious entries it is important that you select at least one data set to be packed.
With the creation a package description will be saved under ~/var/check_mk/packages/,
this description defining the general information and also the list of included data sets.

This package - intended for another system or for uploading to the exchange, for example
- will be seen in the package list with the symbol as an MKP data set for downloading.

Note that subsequent changes to the packaged data sets do not require the package to be created anew.
A simple download of the MKP file is sufficient. On the other hand, following a change it
naturally can't hurt to give the package a new version number.

3. MKP on the command line

All of the actions described above can be executed on the command line.
The mkp command (an abreviation of cmk -P) serves this function:

3.2. Deinstalling packages or releasing their files

Deinstalling a package is executed with mkp remove. This command deletes the
package description as well as all of its data sets!

OMD[mysite]:~$ mkp remove mypackage

Release a package with mkp release. With this the extension's data sets are retained,
and only the package description is deleted:

OMD[mysite]:~$ mkp release mypackage

3.3. Creating packages

Creating MKPs on the command line is analogous to creation in the WATO module,
but perhaps not so conveniently. Firstly, create your extensions in the appropriate folders
under ~/local/. All unpackaged data sets can be found with mkp find:

4. MKPs in distributed environments

With a distributed monitoring it is sufficient
when the packet has been installed on the master. For each connection to a slave
site it can be specified whether the customisation should be passed to that site.
The Extensions option must only be activated to make this possible.
Subsequently during a synchronisation the MKPs and all other changes within the
~/local directory will be carried over.

Should a carryover not be desired, simply deactivate the option for any specific, or all sites.

Important: The customisation will only be carried over if the Replication method
has been set to Slave: push configuration to this site.