1. Einleitung
In diesem Artikel zeigen wir Ihnen alles rund um Benutzerverwaltung und Berechtigungen in Checkmk. Doch bevor wir in die Details gehen können, müssen wir erst einige Begriffe klären.
Ein Benutzer (User) ist in Checkmk jemand, der Zugang zur Benutzeroberfläche hat. Er hat eine oder mehrere Rollen. Aus den Rollen ergeben sich Berechtigungen (Permissions).
Sobald ein Benutzer für bestimmte Hosts und Services zuständig ist, wird er als Kontakt bezeichnet. Ein Kontakt sieht normalerweise nur seine eigenen Hosts und Services in der Statusoberfläche und wird eventuell über Probleme alarmiert.
Es gibt auch Benutzer, die keine Kontakte sind. Ein Beispiel dafür ist
cmkadmin
, der beim Erzeugen einer Instanz automatisch angelegt wird.
Dieser darf zwar alle Hosts und Services sehen, aber nur, weil in
seiner Rolle admin
die Berechtigung See all hosts and services
enthalten ist und nicht, weil er für alles ein Kontakt wäre.
Wenn ein Kontakt nur zum Zwecke der Alarmierung angelegt wurde (z.B. zur Weiterleitung von Alarmen an ein Ticketsystem), dann kann es sinnvoll sein, ihn so anzulegen, dass kein Login in die Oberfläche möglich ist.
Ein Kontakt ist immer Mitglied von einer oder mehreren
Kontaktgruppen. Der Zweck dieser Gruppen ist die Zuordnung von
Kontakten zu Hosts und Services. Zum Beispiel könnte der Kontakt
hhirsch
in der Kontaktgruppe linux
sein und diese wiederum
per Regel allen Linuxhosts zugeordnet. Eine direkte Zuordnung
von Kontakten zu Hosts oder Services ist nicht möglich und würde in der Praxis
auch Schwierigkeiten bereiten (z.B. beim Ausscheiden eines Benutzers).
Noch einmal zusammengefasst:
Benutzer können die Benutzeroberfläche verwenden.
Kontakte sind Benutzer, die für bestimmte Hosts und Services zuständig sind.
Kontaktgruppen legen fest, für was jemand zuständig ist.
Rollen legen fest, welche Privilegien jemand hat.
2. Benutzerverwaltung über WATO
2.1. Übersicht
Die Benutzerverwaltung finden Sie im WATO-Modul Users.
In einer frisch angelegten Instanz sieht diese Seite so aus:

Sie sehen hier den einzigen Benutzer cmkadmin
, welcher automatisch beim
Erzeugen der Instanz angelegt wurde. Bei der Checkmk-Appliance kann dieser Benutzer anders
heißen, da Sie dessen Namen und Passwort selbst festlegen. Dieser erste Benutzer hat folgende
Eigenschaften:
Er hat die Rolle Administrator (
admin
) und damit alle Berechtigungen!Er ist für nichts Kontakt und bekommt keine Alarme.
Er darf trotzdem alles sehen (wegen seiner Rolle
admin
).Das Standardpasswort sollten Sie dringend ändern!
An der Titelzeile sehen Sie übrigens immer, als wer Sie gerade angemeldet sind und welche Rolle Sie haben:

Die Maske zum Anlegen eines neuen Benutzers mit oder
zum Editieren eines bestehenden Benutzers mit
ist in fünf Abschnitte unterteilt. Im ersten geht es um die Identität:
2.2. Identität

Wie immer in Checkmk ist die ID eines Datensatzes (hier Username) später nicht änderbar. Sie wird für die Anmeldung verwendet und auch als interner Schlüssel in sämtlichen Dateien und Datenstrukturen.
Die E-Mail-Adresse ist optional und nur dann notwendig, wenn der Benutzer ein Kontakt werden soll, der per E-Mail alarmiert werden soll (SMTP-Konfiguration notwendig). Analog ist das Feld Pager address für die Alarmierung per SMS oder ähnliche Systeme vorgesehen. Wenn Sie eigene Alarmierungsskripte schreiben, können Sie auf die Werte in den Feldern zugreifen und sie für beliebige Zwecke verwenden.
Über Authorized sites dürfen Sie optional beschränken, auf welche der vorhandenen Sites zugegriffen werden darf. Praktisch ist das vor allem bei sehr großen Umgebungen, etwa einem verteilten Monitoring mit Hunderten von Sites: Sofern ein Nutzer nur einen Teil dieser Sites für seine Hosts benötigt, wird die GUI auch nur die autorisierten Sites kontaktieren, um Ansichten aufzubauen. Was wiederum der Performanz enorm zugutekommt.
2.3. Sicherheit

Der zweite Kasten dient der Anmeldung und Berechtigung. Die Option Automation secret for machine accounts ist für Accounts gedacht, die skriptgesteuert per HTTP auf Checkmk zugreifen und sich über die URL authentifizieren. Wie das geht, zeigen wir Ihnen weiter unten.
Bei den Rollen müssen Sie mindestens eine auswählen. Theoretisch können Sie einem Benutzer auch mehrere Rollen geben. Er bekommt dann die Rechte von allen diesen Rollen. Mit den drei vordefinierten Rollen (siehe weiter unten) macht dies wenig Sinn.
Wenn Sie einen Benutzer mit der Option disable the login to this account
sperren, wird er in der Tabelle mit dem Symbol
dargestellt. Er kann sich dann nicht mehr anmelden,
bleibt aber trotzdem im im System erhalten. Falls er ein Kontakt ist, ist auch die Alarmierung
von der Sperre nicht beeinflusst und er wird weiterhin E-Mails etc. erhalten.
War der Benutzer zum Zeitpunkt der Sperrung gerade angemeldet, so wird er
automatisch abgemeldet.
2.4. Kontaktgruppen

Sobald Sie einen Benutzer einer oder mehreren Kontaktgruppe zuordnen wird dieser zum Kontakt. Bei einer neuen Instanz wird automatisch die Kontaktgruppe Everything angelegt, die immer alle Hosts und alle Services enthält. Ein Benutzer in dieser Gruppe ist automatisch für alle Hosts und Services zuständig.
2.5. Alarmierungen

Im Kasten Notifications können Sie über die Option Receive fallback notifications festlegen, dass dieser Kontakt Alarmierungen für Ereignisse bekommt, wenn keine Alarmierungsregel greift.
2.6. Persönliche Einstellungen

Alle Einstellungen im letzten Kasten kann der Benutzer über
auch selbst ändern
(außer in der Rolle
guest
). Abgesehen von der Auswahl der Sprache der Oberfläche
handelt es sich um selten benötigte Einstellungen. Details dazu finden Sie wie
immer in der Onlinehilfe.
3. Kontaktgruppen
3.1. Kontaktgruppen anlegen und editieren
Kontaktgruppen sind das Bindeglied zwischen Hosts und Services auf der einen und Kontakten
auf der anderen Seite. Jede Kontaktgruppe repräsentiert eine Zuständigkeit für einen bestimmten
Bereich in Ihrer IT-Landschaft. So könnte z.B. die Kontaktgruppe SAP
alle Personen
umfassen, die SAP-Systeme betreuen, und allen Hosts und Services zugeordnet sein, die
Dienste in diesem Umfeld bereitstellen.
Die Kontaktgruppen verwalten Sie mit dem WATO-Modul
Contact groups. Folgende Abbildung zeigt
dieses Modul mit vier angelegten Kontaktgruppen:

Das Anlegen einer neuen Gruppe ist trivial. Wie immer ist die ID unveränderlich und der Alias ein Anzeigename, den Sie später jederzeit anpassen können:

Die neue Kontaktgruppe ist erst mal leer in doppelter Hinsicht: Sie enthält weder Kontakte noch Hosts oder Services. Die Zuordnung von Kontaktgruppen zu Kontakten geschieht über die Benutzerprofile, wie wir schon beim Editieren des Benutzers gesehen haben. Die Zuordnung von Hosts und Services geschieht wie folgt:
3.2. Hosts in eine Kontaktgruppe aufnehmen
Zum Aufnehmen von Hosts in Kontaktgruppen gibt es zwei Methoden: über Ordner und über Regeln. Sie können auch beide Methoden kombinieren. In diesem Fall bekommt der Host dann die Summe der jeweiligen Kontaktgruppen zugeordnet.
Zuweisung über Ordner
Zu den Eigenschaften eines Ordners gelangen Sie über den Knopf
während Sie im Ordner sind. Dort finden Sie die Option Permissions. Aktivieren Sie diese
Checkbox, um zur Auswahl der Kontaktgruppen zu kommen:

Der eigentliche Sinn dieser Option ist das Setzen von Berechtigungen für das Pflegen von Hosts in WATO, welches wir weiter unten im Detail besprechen. Sobald Sie Berechtigungen für bestimmte Kontaktgruppen vergeben, können Sie diese im gleichen Zug auch als Kontaktgruppen für die Hosts im Monitoring eintragen lassen. Dabei können Sie entscheiden, ob diese auch für Hosts in Unterordnern gelten sollen und auch, ob die Services der Hosts ebenfalls explizit diese Gruppen bekommen sollen. Services ohne explizite Zuweisung erben nämlich alle Gruppen eines Hosts, auch solche, die durch Regeln zugewiesen wurden.
Achtung: Die Vererbung des Permissions-Attributs über die Ordner ist an dieser Stelle außer Kraft gesetzt. Dies erlaubt Ihnen, in Unterordnern weitere Kontaktgruppen hinzuzufügen. Die Zuordnung geschieht also kumulativ auch über alle Elternordner, falls in diesen die Option Add these groups as contacts in all subfolders aktiviert ist.
Übrigens finden Sie die Kontaktgruppenoptionen in vereinfachter Form auch direkt in den Details eines Hosts. Somit können Sie einzelnen Hosts auch hierüber Kontaktgruppen zuordnen. Da das aber schnell recht unübersichtlich werden kann, sollten Sie das nur in Ausnahmefällen tun und bei Bedarf eventuell lieber mit Regeln arbeiten.
Zuweisung über Regeln
Die zweite Methode — das Zuweisen von Kontaktgruppen über Regeln — ist etwas umständlicher, aber dafür deutlich flexibler. Und es ist sehr nützlich, wenn Sie Ihre Ordnerstruktur nicht nach organisatorischen Prinzipien aufgebaut haben und daher die Ordner nicht eindeutig Kontaktgruppen zuordnen können.
Den schnellen Zugriff auf den dafür nötigen Regelsatz
Assignment of hosts to contact groups erreichen Sie vom WATO-Modul der Kontaktgruppen
aus bequem mit dem Knopf . In diesem Regelsatz finden
Sie eine vordefinierte Regel, die beim Erzeugen der Instanz angelegt wurde
und welche alle Hosts der Kontaktgruppe Everything zuweist.

Bitte beachten Sie, dass dieser Regelsatz so definiert ist, dass alle zutreffenden Regeln ausgewertet werden und nicht nur die Erste! Es kann nämlich durchaus nützlich sein, dass ein Host zu mehreren Kontaktgruppen gehört. In diesem Fall benötigen Sie für jede Zuweisung eine eigene Regel.

3.3. Services in Kontaktgruppen aufnehmen
Es ist nicht immer sinnvoll, dass ein Service in den gleichen Kontaktgruppen ist wie sein Host. Daher können Sie über den Regelsatz Assignment of services to contact groups Services zu Kontaktgruppen zuordnen — unabhängig von den Gruppen des Hosts. Dabei gelten folgende Regeln:
Wenn einem Service keine Kontaktgruppe zugeordnet ist, erhält er automatisch die gleichen Kontaktgruppen wie sein Host.
Sobald einem Service mindestens eine Kontaktgruppe explizit zugeordnet ist, erbt er die Kontaktgruppen vom Host nicht mehr.
In einer einfachen Umgebung genügt es also, wenn Sie nur den Hosts Kontaktgruppen zuordnen. Sobald Sie mehr Differenzierung brauchen, können Sie auch Regeln für die Services anlegen.
Kontrolle der Zuordnung
Ob Sie alle Regeln und Ordner richtig konfiguriert haben, können Sie in den Details eines Hosts oder Services in der Statusoberfläche überprüfen. Dort finden Sie die Einträge Contact groups und Contacts, welche die letztendliche Zuordnung für dieses Objekt auflisten.

4. Sichtbarkeit von Hosts und Services
4.1. Übersicht
Die Tatsache, dass ein normaler Anwender (Rolle user
) nur solche
Objekte sieht, für die er ein Kontakt ist, ist umso wichtiger, je größer
Ihre Monitoringumgebung ist. Das sorgt nicht nur für Übersicht, sondern
verhindert auch, dass Benutzer dort eingreifen, wo sie nichts zu suchen
haben.
Als Adminbenutzer (Rolle admin
) dürfen Sie natürlich immer
alles sehen. Gesteuert wird das über die Berechtigung See all host and services.
In Ihren
persönlichen Einstellungen
finden Sie die Checkbox
Only show hosts and services the user is a contact for. Mit dieser können
Sie das „Alles Sehen“ freiwillig aufgeben und nur noch die Hosts und Services
sehen, für die Sie ein Kontakt sind. Diese Option ist für Doppelrollen gedacht — also für jemanden, der gleichzeitig Administrator und auch normaler Benutzer
des Monitorings ist.
Die Rolle guest
ist so voreingestellt, dass auch ihre Benutzer alles
sehen können. Ein Eingreifen oder persönliche Einstellungen sind hier deaktiviert.
Für normale Anwender ist die Sichtbarkeit in der kompletten Statusoberfläche so umgesetzt, dass sich das System so anfühlt, als wären die Hosts und Services, für die man nicht Kontakt ist, überhaupt nicht vorhanden. Unter anderem berücksichtigen folgende Elemente die Sichtbarkeit:
Sämtliche tabellarischen Ansichten von Hosts und Services
Die Tactical Overview
Dashboards inklusive der „Globen“
Berichte, die von dem Benutzer erstellt werden
4.2. Sichtbarkeit von Services
Wie wir oben gezeigt haben, ist es möglich, dass Sie für einen Host Kontakt sind, aber nicht für alle seine Services. Trotzdem werden Sie in so einem Fall alle Services des Hosts in der GUI sehen können.
Diese Ausnahme ist so voreingestellt, weil das meistens nützlich ist. Das bedeutet in der Praxis z.B., dass der Kollege, der für den Host an sich verantwortlich ist, auch solche Services sehen kann, die mit dem eigentlichen Host (Hardware, Betriebssystem, etc.) nichts zu tun haben. Trotzdem erhält er für diese keine Alarme!
Wenn Ihnen das nicht gefällt, können Sie das umstellen. Die globale Option
dazu heißt Monitoring Core > Authorization settings. Wenn Sie
dort Hosts auf Strict - Must be explicit contact of a service
umstellen, können Benutzer Services nur noch dann sehen, wenn sie direkt
als Kontakt dem Service zugeordnet sind.
Das Ganze hat übrigens nichts damit zu tun, dass ein Service die Kontaktgruppen seines Hosts erbt, falls für ihn keine eigenen definiert sind. Denn dann wären Sie ja Kontakt für den Service (und würden auch deren Alarme bekommen).

4.3. Host- und Servicegruppen
Die zweite Einstellung in dieser Option betrifft Host- und Servicegruppen. Normalerweise können Sie eine Gruppe immer dann sehen, wenn Sie mindestens ein Element der Gruppe sehen können. Allerdings sieht die Gruppe dann für Sie aus, als würde sie auch nur die für Sie sichtbaren Element enthalten.
Ein Umschalten auf Strict - must be contact of all members macht alle Gruppen unsichtbar, in denen Sie für mindestens einen Host bzw. Service kein Kontakt sind.
Bitte beachten Sie, dass diese beiden Einstellungen zur Sichtbarkeit keinen Einfluss auf die Alarmierung haben.
5. Alarmierung
Kontaktzuordnungen haben auch einen Einfluss auf die Alarmierung. Checkmk ist so voreingestellt, dass im Falle eines Problems alle Kontakte des betroffenen Hosts oder Services alarmiert werden. Die geschieht durch eine Alarmierungsregel, die bei neuen Instanzen automatisch angelegt wird. Dies ist ein sehr sinnvolles Verhalten.
Trotzdem können Sie bei Bedarf die Regel anpassen oder durch weitere Regeln ergänzen, so dass eine Alarmierung im Extremfall sogar ganz unabhängig von den Kontaktgruppen geschieht. Häufiger Grund dafür ist, dass ein Benutzer sich wünscht, bestimmte Alarme nicht zu bekommen oder umgekehrt über Probleme bei einzelnen Hosts oder Services informiert zu werden, auch wenn er für diese nicht zuständig (und folglich kein Kontakt) ist.
Details erfahren Sie im Artikel über die Alarmierung.
6. Rollen und Berechtigungen
6.1. Vordefinierte Rollen
Checkmk vergibt Berechtigungen an Benutzer immer über Rollen — niemals direkt. Eine Rolle ist nichts anderes als eine Liste von Berechtigungen. Wichtig ist, dass Sie verstehen, dass Rollen das Niveau von Berechtigungen definieren und nicht den Bezug zu irgendwelchen Hosts oder Services. Dafür sind die Kontaktgruppen da.
Checkmk wird mit folgenden drei vordefinierten Rollen ausgeliefert, welche niemals gelöscht, aber beliebig angepasst werden können:
Rolle | Berechtigungen | Einsatzzweck |
---|---|---|
admin | Alle Berechtigungen — insbesondere das Recht, Berechtigungen zu ändern. | Der Checkmk-Administrator, der das Monitoringsystem an sich betreut. |
user | Darf nur seine Hosts und Services sehen, in WATO nur in für ihn freigegebenen Ordnern Änderungen machen und darf generell nichts machen, was andere Benutzer beeinflusst. | Der normale Checkmk-Benutzer, der das Monitoring nutzt und auf Alarme reagiert. |
guest | Darf alles sehen aber nichts ändern. | Gedacht zum einfachen „Gucken“, wobei sich alle Gäste einen gemeinsamen Account teilen. Auch nützlich für öffentliche Statusbildschirme, die an der Wand hängen. |
Die Rollen werden im WATO-Modul Roles & Permissions verwaltet:

Übrigens: Beim Erzeugen einer neuen Checkmk-Instanz wird nur ein Benutzer
der Rolle admin
angelegt (cmkadmin
). Die beiden anderen
Rollen werden erst mal nicht verwendet. Wenn Sie einen Gastbenutzer wünschen,
müssen Sie diesen selbst anlegen.
6.2. Bestehenden Rollen anpassen
Wie üblich gelangen Sie über das Symbol in den Editiermodus für eine Rolle:
Welche Bedeutung die zahlreichen Berechtigungen, hier in Auszügen, haben erfahren Sie aus der Onlinehilfe.
Das Besondere hier: Für jede Berechtigung gibt es drei Auswahlmöglichkeiten: yes, no und default (yes) bzw. default(no). Am Anfang stehen alle Werte auf default. Für die Berechtigung selbst macht es erst mal keinen Unterschied, ob Sie yes oder default (yes) eingestellt haben. Allerdings kann eine neue Version von Checkmk den Defaultwert ändern (auch wenn das sehr selten vorkommt). Eine von Ihnen explizite gemachte Einstellung wäre dann von der Änderung nicht betroffen.
Außerdem können Sie durch dieses Prinzip sehr schnell erkennen, wo Ihre Checkmk-Installation vom Standard abweicht.

6.3. Eigene Rollen definieren
Vielleicht sind Sie überrascht, dass es keinen Knopf gibt, um eine neue
Rolle anzulegen. Dahinter steckt eine Absicht! Neue Rollen erschaffen Sie
durch ein Ableiten von bestehenden Rollen mittels
Clone. Die neue Rolle wird nicht einfach als Kopie erzeugt, sondern
behält den Bezug zur Ausgangsrolle (Based on role):

Diese Verbindung hat eine wichtige Funktion. Denn alle Berechtigungen der geklonten Rolle, die nicht explizit gesetzt sind (also noch auf default stehen), werden von der Ausgangsrolle geerbt. Änderungen in der Ausgangsrolle schlagen also durch. Das ist sehr praktisch, denn wenn man bedenkt, wie viele Berechtigungen es gibt. Bei einer simplen Kopie könnten Sie sonst leicht den Überblick verlieren, was eigentlich das Besondere an Ihrer selbst definierten Rolle ausmacht.
Und das Ableiten löst noch ein weiteres Problem: Da wir Checkmk rege
weiterentwickeln, kommen immer wieder neue Berechtigungen hinzu.
Jedes mal entscheiden wir dann, in welcher der drei Rollen
admin
, user
und guest
die neue Berechtigung
enthalten sein soll. Da auch Ihre eigenen Rollen von genau einer von diesen
abgeleitet ist, wird dann die neue Berechtigung automatisch auf einen sinnvollen
Wert voreingestellt. Es wäre doch sehr unpraktisch, wenn Sie z.B. eine eigene
user
-Rolle definieren und dort neue Berechtigungen immer fehlen
würden. Dann müssten Sie bei jedem neuen Feature Ihre Rolle anpassen,
damit Ihre Benutzer diese nutzen könnten.
6.4. Rollen vergleichen mit der Matrixansicht
Wenn Sie die Berechtigungen in den einzelnen Rollen vergleichen möchten, hilft
der Knopf . Er erzeugt folgende Darstellung,
in der Sie nicht nur die Berechtigungen der einzelnen Rollen vergleichen können,
sondern auch die Stellen sehen, an denen explizit Berechtigungen gesetzt
(Symbol
) bzw. entfernt (Symbol
) wurden.

7. Persönliche Einstellungen
Einen kleinen Teil der Benutzereinstellungen kann jeder Benutzer selbst verwalten.
Diese finden sich in am Fuß der Seitenleiste hinter dem Knopf .
Dieser bringt Sie zu folgende Maske:

Die wichtigste Funktion ist die Änderung des Passworts. Dazu
muss der Benutzer nicht nur das neue, sondern auch das bestehende Passwort
eingeben. Eine Beschreibung der weiteren Einstellmöglichkeiten finden Sie
wie immer in der Onlinehilfe.
Bei einem Verteilten Monitoring werden nach jeder Änderung die neuen Einstellungen sofort auf alle Monitoringinstanzen übertragen. Nur so ist sichergestellt, dass das neue Passwort auch sofort überall funktioniert — und nicht erst beim nächsten Aktivieren der Änderungen. Das klappt allerdings nur für Standorte, die zu diesem Zeitpunkt auch über das Netzwerk erreichbar sind. Alle andere Standorte bekommen die Aktualisierungen beim nächsten erfolgreichen Activate changes.
8. Automationsbenutzer (für Webservices)
Bei der Anbindung von Checkmk an andere Systeme kommt oft der Wunsch auf, bestimmte Tätigkeiten, die normalerweise über die GUI stattfinden, zu automatisieren. Einige Beispiele dafür sind:
Setzen und Entfernen von Wartungszeiten per Skript
Verwalten von Hosts in WATO per Web-API
Abrufen von Daten aus Ansichten als CSV oder JSON zum Zwecke der Weiterverarbeitung
Abrufen des aktuellen Status von BI-Aggregaten, um diese als Service anzulegen
In diesen Situationen muss eine externe Software bestimmte URLs der Checkmk-Oberfläche automatisiert abrufen können. Und da stellt sich natürlich die Frage, wie hier die Benutzeranmeldung geschieht. Der normale Weg über die Loginmaske ist umständlich und erfordert den Abruf von mehreren URLs hintereinander und das Speichern eines Cookies.
Um dies zu vereinfachen, bietet Checkmk das Konzept der Automationsbenutzer. Diese Benutzer sind ausschließlich für eine Fernsteuerung vorgesehen und erlauben keine normale Anmeldung über die GUI. Die Authentifizierung geschieht hier über bestimmte Variablen in der URL.
Sie legen einen Automationsbenutzer wie einen normalen Benutzer an, vergeben
aber kein Passwort, sondern ein Geheimnis (Automation secret). Dieses
können Sie mit dem Würfel automatisch erstellen lassen:

Ein Automationsuser hat genauso wie ein normaler Benutzer eine Rolle und kann auch Kontakt sein. Damit können Sie also die Berechtigungen und die Sichtbarkeit von Hosts und Services nach Bedarf einschränken.
Beim automatischen Abruf von Webseiten geben Sie dann in der URL folgende Variablen zusätzlich an:
_username | die ID des Automationsusers |
_secret | dessen Automation secret |
Hier ist ein Beispiel für den Abruf einer Ansicht im JSON-Format mit dem
Automationsbenutzer automation
und dem Geheimnis aus der obigen
Abbildung:
root@linux# curl 'http://moni01.mycompany.net/mysite/check_mk/view.py?_username=automation&_secret=GLV@GYCAKINOLICMAFVP&view_name=svcproblems&output_format=json'
[
"service_state",
"host",
"service_description",
"service_icons",
"svc_plugin_output",
"svc_state_age",
"svc_check_age",
"perfometer"
],
[
"CRIT",
"stable",
"Filesystem /",
"menu pnp",
"CRIT - 96.0% used (207.27 of 215.81 GB), (warn/crit at 80.00/90.00%), trend: +217.07 MB / 24 hours",
"119 min",
"30 sec",
"96%"
],
...
Wenn das Skript, das die URL abruft, direkt in der Monitoring-Instanz läuft,
können Sie das Geheimnis für den Benutzer direkt aus dem Dateisystem auslesen.
Das ist keine Sicherheitslücke, sondern so vorgesehen: Sie können
Automatisierungsskripte schreiben, die das Geheimnis nicht enthalten müssen und
keine Konfigurationsdatei benötigen. Lesen Sie dazu die Datei
~/var/check_mk/web/myuser/automation.secret
aus:
OMD[mysite]:~$ cat var/check_mk/web/automation/automation.secret
GLV@GYCAKINOLICMAFVP
In der Shell können Sie den Inhalt dieser Datei leicht in einer Variable speichern:
OMD[mysite]:~$ SECRET=$(cat var/check_mk/web/automation/automation.secret)
OMD[mysite]:~$ echo "$SECRET"
GLV@GYCAKINOLICMAFVP
Dies macht sich z.B. auch das Script downtime
zunutze, welches Sie
in den Treasures von Checkmk finden und mit dem Sie skriptgesteuert
Wartungszeiten für Hosts und Services setzen und entfernen können. Wenn
der Automationsbenutzer wie bei uns im Beispiel automation
heißt,
brauchen Sie als einziges Argument den Hostnamen, für den eine Wartung
eingetragen werden soll:
OMD[mysite]:~$ ~/share/doc/check_mk/treasures/downtime myhost123
Weitere Optionen des Skripts erfahren Sie in dessen Onlinehilfe:
OMD[mysite]:~$ ~/share/doc/check_mk/treasures/downtime --help
9. Automatische Anmeldung über die URL
Wie wir gesehen haben, können Sie mit Automationsbenutzern beliebige URLs ohne Anmeldung skriptgesteuert abrufen. In Situationen, die einen echten Browserlogin benötigen, funktioniert dies jedoch nicht, da die Logindaten bei enthaltenen Links (z.B. zu Bildern und iFrames) nicht weitergereicht werden.
Das beste Beispiel dafür ist der Wunsch, einen Bildschirm an die Wand zu hängen, der ständig ein bestimmtes Dashboard von Checkmk zeigt. Der Bildschirm soll von einem Rechner angesteuert werden, der beim Starten automatisch den Browser öffnet, sich an Checkmk anmeldet und das Dashboard aufruft.
Um so etwas zu realisieren, legen Sie sich am besten zunächst dafür einen
speziellen Benutzer an. Die Rolle guest
ist dafür gut geeignet, weil
diese alle Leserechte einräumt, aber keine Veränderungen oder Eingriffe zulässt.
Die URL für eine automatische Anmeldung konstruieren Sie wie folgt:
Beginnen Sie mit
mycmkserver/mysite/login.py?_origtarget=
Ermitteln Sie die eigentlich anzuzeigende URL (z.B. die des Dashboards) mit Ihrem Browser — am besten, in dem Sie mit dem Browser nur das rechte Frame anzeigen und die Seitenleiste weglassen.
Hängen Sie diese URL an, wobei Sie alles vor dem Teil
/mysite/…
weglassen.Fügen Sie an die URL die beiden Variablen
_username
und_password
an und zwar in folgender Form:&_username=myuser&_password=mysecret
Fügen Sie noch ein
&_login=1
an.
Hier ist ein Beispiel für so eine URL:
Bitte beachten Sie:
Ersetzen Sie im Beispiel die Werte
mycmkserver
,mysite
,myuser
undmypassword
durch die bei Ihnen gültigen Werte.Kommen die Sonderzeichen
&
oder%
in einem dieser Werte oder in dem Wert von_origtarget
vor, müssen Sie diese wie folgt ersetzen:&
durch%26
und%
durch%25
.
Testen Sie das Ganze, in dem Sie sich in Ihrem Browser von Checkmk abmelden und dann die konstruierte URL in Ihre Adresszeile vom Browser kopieren. Sie müssen dann direkt auf die Zielseite gelangen — ohne Anmeldemaske. Gleichzeitig werden Sie dabei angemeldet und können in der Seite enthaltene Links direkt aufrufen.
Sie können die fertige URL auch mit curl
auf der Kommandozeile
ausprobieren. Wenn Sie alles richtig gemacht haben, bekommen Sie als
Ergebnis in „302 Found
“ und eine Weiterleitung („The document
has moved…
“).
OMD[mysite]:~$ curl 'http://localhost/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1'
302 Found
Found
The document has moved here.
Bei einem Fehler erhalten Sie den HTML-Code der Anmeldemaske. Dieser endet mit folgendem Code: