Skip to content

checkmk - Dockerinstallation

Verschoben checkmk
  • Nachdem ich wieder ein wenig hier umgebaut habe, wollte ich eine checkmk Installation installieren. Aber wo? Ich habe hier eine pfSense, ok mit FreeBSD scheidet das als Installationsziel aus. Auf meinem ROCKPro64, mein neues NAS mit Debian Buster 10.1, scheiterte die Installation an nicht vorhandenem arm Pakete. Gut, das ich da noch über die Docker Installation gestolpert bin 🙂

    Da auf meinem Haupt-PC sowieso Docker installiert ist, bot sich das an es mal auszuprobieren.

    Die Anleitung zur Dockerinstallation findet man hier. https://checkmk.de/cms_introduction_docker.html

    Installation

    Docker

    apt install docker.io
    

    checkmk Container

    root@debian:~# docker container run -dit -p 8080:5000 --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 -v monitoring:/omd/sites --name monitoring -v /etc/localtime:/etc/localtime:ro --restart always checkmk/check-mk-raw:2.0.0-latest
    Unable to find image 'checkmk/check-mk-raw:1.6.0-latest' locally
    1.6.0-latest: Pulling from checkmk/check-mk-raw
    8f91359f1fff: Pull complete 
    3d794619eec5: Pull complete 
    1468b0cb296b: Pull complete 
    787a36ef0a12: Pull complete 
    159fac9366a1: Pull complete 
    fefc9fe50b26: Pull complete 
    Digest: sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    Status: Downloaded newer image for checkmk/check-mk-raw:1.6.0-latest
    

    Nach der Installation müssen wir uns Logfile schauen, damit wir das Passwort bekommen.

    root@debian:~# docker container logs monitoring
    ### CREATING SITE 'cmk'
    Adding /opt/omd/sites/cmk/tmp to /etc/fstab.
    Going to set TMPFS to off.
    Created new site cmk with version 1.6.0p5.cre.
    
      The site can be started with omd start cmk.
      The default web UI is available at http://xxxxxxxxxx/cmk/
    
      The admin user for the web applications is cmkadmin with password: password
      (It can be changed with 'htpasswd -m ~/etc/htpasswd cmkadmin' as site user.
    )
      Please do a su - cmk for administration of this site.
    
    ### STARTING XINETD
    [ ok ] Starting internet superserver: xinetd.
    ### STARTING SITE
    Starting mkeventd...OK
    Starting rrdcached...OK
    Starting npcd...OK
    Starting nagios...OK
    Starting apache...OK
    Initializing Crontab...OK
    ### STARTING CRON
    ### CONTAINER STARTED
    

    Danach kann man den Container erreichen. Jetzt sollte man als erstes das generierte Passwort durch ein eigenes ersetzen. Dazu brauchen wird die ID des Containers

    root@frank-MS-7C37:~# docker ps
    CONTAINER ID   IMAGE                               COMMAND                  CREATED         STATUS                   PORTS                              NAMES
    b59475ab385b   checkmk/check-mk-raw:2.0.0-latest   "/docker-entrypoint.…"   3 minutes ago   Up 3 minutes (healthy)   6557/tcp, 0.0.0.0:8080->5000/tcp   monitoring
    

    Jetzt einloggen

    root@frank-MS-7C37:~# docker exec -it b59475ab385b bash
    root@b59475ab385b:/# 
    

    Jetzt sind wir innerhalb des Docker Containers. Und nun das Passwort wechseln!!

    root@b59475ab385b:/# omd su cmk
    OMD[cmk]:~$ htpasswd etc/htpasswd cmkadmin
    New password: 
    Re-type new password: 
    Updating password for user cmkadmin
    

    Nun steht dem Einloggen nichts mehr im Wege.

    c76ff794-223f-452e-86ec-9f74459e1136-grafik.png

    Und hier nach dem Einloggen.

    7dd2a7a1-b89e-45cf-a228-e0645f55cbc0-grafik.png

    Sicherheit

    Bitte das hier unbedingt beachten. https://checkmk.de/cms_agent_linux.html#security

    Docker

    docker ps zeigt alle laufenden Docker Container an.

    root@debian:~# docker ps
    CONTAINER ID        IMAGE                               COMMAND                  CREATED             STATUS                  PORTS                              NAMES
    Container-ID        checkmk/check-mk-raw:1.6.0-latest   "/docker-entrypoint.…"   25 hours ago        Up 25 hours (healthy)   6557/tcp, 0.0.0.0:8080->5000/tcp   monitoring
    

    In die Kommandozeile des Containers wechseln.

    docker exec -it Container-ID bash
    

    Sicherheit der Agents

    Dazu bitte die Dokumentation beachten!

  • Ich hatte damals vergessen, die CheckMK Installation zu sichern. Jo, dann halt von vorne. Aber das ist bei den Dockerinstallationen für mich alles noch was neu 😉

    Backup erstellen

    24a87d1d-2951-4793-b60b-bf6d17d065f0-grafik.png

    Was muss in das Feld "Directory to save the backup to" rein!?!?!?

    Es hat etwas gedauert, bis es bei mir Klick gemacht hat. Wenn man sich in die Dockerinstallation einloggt

    docker exec -it Container-ID bash
    

    dann wird es etwas klarer. Wir bewegen uns ja in diesem Dateiverzeichnis.

    root@5e2e67e33438:/# ls -lha opt/omd/sites
    total 20K
    drwxr-xr-x 4 cmk  1001 4.0K Jun 12 22:27 .
    drwxr-xr-x 1 root root 4.0K Jun 10 18:52 ..
    drwxr-xr-x 3 cmk  1001 4.0K Jun 12 22:30 backup
    drwxr-xr-x 8 cmk  1001 4.0K Jun 11 20:23 cmk
    

    Das Verzeichnis backup habe ich angelegt. Danach konnte ich mit CheckMK ein Backup anlegen. Jo, aber wo liegen die Daten auf dem Host?

    Suche auf dem Host

    Beim Startaufruf, wird das hier übergeben.

    -v monitoring:/omd/sites
    

    In der Anleitung steht folgendes.

    Diese Option bindet die Daten der Instanz in diesem Container an eine persistente Stelle im Dateisystem des Docker-Node. Sie gehen daher nicht verloren, wenn der Container wieder entfernt wird.

    Ok. Hilft mir leider noch nicht so richtig. Weiter suchen....

    root@frank:/# docker volume inspect monitoring
    [
        {
            "CreatedAt": "2020-06-12T22:27:13+02:00",
            "Driver": "local",
            "Labels": null,
            "Mountpoint": "/var/lib/docker/volumes/monitoring/_data",
            "Name": "monitoring",
            "Options": null,
            "Scope": "local"
        }
    ]
    

    Und hier finden wir dann den Mountpoint!

    root@frank:/# ls -lha /var/lib/docker/volumes/monitoring/_data
    insgesamt 16K
    drwxr-xr-x 4 frank omd  4,0K Jun 12 22:27 .
    drwxr-xr-x 3 root  root 4,0K Jun 11 20:23 ..
    drwxr-xr-x 3 frank omd  4,0K Jun 12 22:30 backup
    drwxr-xr-x 8 frank omd  4,0K Jun 11 20:23 cmk
    

    Die Gruppe omd habe ich eingetragen, muss ich noch mal testen ob das überhaupt sein muss. Wird ergänzt.....

    Und dort liegen jetzt die persistenten Daten der Docker Installation.

    root@frank:/# ls -lha /var/lib/docker/volumes/monitoring/_data/backup/
    insgesamt 12K
    drwxr-xr-x 3 frank omd        4,0K Jun 12 22:30 .
    drwxr-xr-x 4 frank omd        4,0K Jun 12 22:27 ..
    drwxrwxr-x 2 frank messagebus 4,0K Jun 12 22:30 Check_MK-5exxxxx3438-cmk-backup-complete
    

    Und dieses Backup kann ich mir dann auf mein NAS schieben 🙂

  • Auf meinem jetzigen Ubuntu 20.04 hatte ich das Problem, das ich checkmk nach einem Neustart nicht aufrufen konnte. Kurz mal ein wenig umgeschaut und dann klingelte es 😉

    systemctl enable docker
    

    Der Dienst Docker lief nicht. Problem gelöst.

  • Sichern der Backup Daten aus der CheckMK Installation

    rsync -av /var/lib/docker/volumes/monitoring/_data/backup/ /media/NAS/Dokumente/Sicherungen/checkmk
    
  • Das hat so nicht geklappt 😞

    Dann mal schauen, wie man es noch machen könnte. Docker Container sichern.

    Sicherung

    root@frank-MS-7C37:~# docker ps
    CONTAINER ID        IMAGE                               COMMAND                  CREATED             STATUS                 PORTS                              NAMES
    3ba19e0a9d12        checkmk/check-mk-raw:1.6.0-latest   "/docker-entrypoint.…"   14 hours ago        Up 2 hours (healthy)   6557/tcp, 0.0.0.0:8080->5000/tcp   monitoring
    
    root@frank-MS-7C37:~# docker commit -p 3ba19e0a9d12 checkmk_backup
    sha256:f75be0ea3c256be98979577b880d77718394352ab2b1551343a0a1a3db6a44dc
    
    root@frank-MS-7C37:~# docker ps
    CONTAINER ID        IMAGE                               COMMAND                  CREATED             STATUS                   PORTS                              NAMES
    3ba19e0a9d12        checkmk/check-mk-raw:1.6.0-latest   "/docker-entrypoint.…"   14 hours ago        Up 2 hours (unhealthy)   6557/tcp, 0.0.0.0:8080->5000/tcp   monitoring
    
    root@frank-MS-7C37:~# docker image ls
    REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
    checkmk_backup         latest              f75be0ea3c25        11 seconds ago      832MB
    checkmk/check-mk-raw   1.6.0-latest        c3efcf4b5c6e        2 weeks ago         830MB
    
    root@frank-MS-7C37:~# docker save -o checkmk_backup.tar checkmk_backup
    

    Danach haben wir eine Sicherung des Docker Containers auf der Platte.

    root@frank-MS-7C37:~# ls -lha
    insgesamt 827M
    drwx------  8 root root 4,0K Aug  1 09:57 .
    drwxr-xr-x 23 root root 4,0K Jul 26 11:14 ..
    -rw-------  1 root root 826M Aug  1 09:57 checkmk_backup.tar
    

    Den können wir jetzt noch packen

    root@frank-MS-7C37:~# gzip checkmk_backup.tar 
    root@frank-MS-7C37:~# ls -lha
    insgesamt 307M
    drwx------  8 root root 4,0K Aug  1 09:58 .
    drwxr-xr-x 23 root root 4,0K Jul 26 11:14 ..
    -rw-------  1 root root 307M Aug  1 09:57 checkmk_backup.tar.gz
    

    Wiederherstellung

    Ungetestet im Moment, kommt noch 😉

    docker load -i checkmk_backup.tar
    

    Starten des Containers dann mit

    docker container run -dit -p 8080:5000 --ulimit nofile=1024 --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 -v monitoring:/omd/sites --name monitoring -v /etc/localtime:/etc/localtime:ro --restart always checkmk_backup
    

    Quelle: https://www.laub-home.de/wiki/Docker_Backup_und_Restore_-_eine_kleine_Anleitung

  • Heute mal das Thema noch mal angefasst.

    Das Backup heute erstellt und ausprobiert. Läuft 😉

    root@:~# docker ps
    CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                             PORTS                              NAMES
    a1ca31c7290b        checkmk_backup      "/docker-entrypoint.…"   31 seconds ago      Up 31 seconds (health: starting)   6557/tcp, 0.0.0.0:8080->5000/tcp   monitoring3
    
  • Das ganze jetzt auch mal praktisch umsetzen, damit der Docker Container auch immer schön gesichert wird.

    #!/bin/sh
    # Script sichert den Docker Container von checkmk. Das Script funktioniert nur, da ich nur EINEN
    # Docker Container laufen habe!
    
    # Wir holen uns die Ausgabe von docker ps
    docker ps > ps.txt
    
    # Mich interessiert nur die 2. Zeile
    tail -n 1 ps.txt > ps_2.txt
    
    # Wir brauchen die ID und speichern diese zwischen
    ID="$(cut -d' ' -f1 ps_2.txt)"
    echo $ID
    
    # Docker Container sichern!
    # Damit wird eine Docker Kopie angelegt.
    docker commit -p $ID checkmk_backup
    
    # Hiermit sichern wir den Docker Container als .tar File im angegebenen Pfad.
    docker save -o /root/checkmk_Docker_Container/checkmk_backup.tar checkmk_backup
    
    # Den gesicherten Container aufs NAS schieben
    rsync -av /root/checkmk_Docker_Container/ /media/NAS/Dokumente/Sicherungen/checkmk_Docker_Container
    
  • Meine Dockersicherungen versagen immer kläglich, so bald sich die Versionen bei checkmk ändern. Da ich dieses checkmk aber unbedingt brauche, habe ich das mal als Cloud Server bei Hetzner getestet. Da bekam ich beim kleinsten Server, beim Anlegen eines Hostes sofort Speicherprobleme (2GB). Ok, seltsam.. Dann habe ich den Server auf 4GB hoch skaliert. Danach lief es.

    Aber, jetzt das Problem. Das hätte ca. 72€ im Jahr nur fürs Monitoring verbrannt. Das war es mir nicht wert, obwohl für das Hobby schon der ein oder andere Euro drauf geht 🙂

    Also, kommt wieder eine Dockerinstallation auf meine Haupt-PC. Der ist sowieso an und ich weiß das das gut funktioniert. Habe heute im Eingangspost ein paar Anpassungen vorgenommen, was einem halt so auffällt bei einer Neuinstallation.

    Danach die ganzen Hosts anlegen, das muss ja einfacher gehen. In der Firma der SysAdmin importiert die ja auch. Also mal die checkmk Dokumentation durchsucht und fündig geworden.

    Unter Punkt 6 findet man Import von CSV Dateien.

    Das Beispiel aus der Dokumentation

    hostname;ip address;alias;agent;snmp_ds
    lnx17.example.com;192.168.178.48;Webserver;cmk-agent;
    lnx18.exmpl.com;192.168.178.55;Backupserver;cmk-agent;
    switch47-11;;Switch47;no-agent;snmp-v2
    

    Das bekommen wir hin, alle meine Server eingetragen,

    bf1ddc6f-c726-4c20-8c9c-9156b732a0b6-grafik.png

    Fertig, noch ein wenig Feinarbeit danach an den Diensten und es lief wieder.

  • Und noch was Wichtiges.

    6777da6e-3b4f-41b9-bf6e-26496ae67cd8-grafik.png

    Damit sichert man den Datenaustausch ab.

    Kapitel 7.4. Inbuilt encryption

    Den Ordner findet man hier -> /etc/check_mk/encryption.cfg

  • FrankMF FrankM verschob dieses Thema von Linux am
  • FrankMF FrankM hat am auf dieses Thema verwiesen

  • Proxmox - Video Tipp

    Proxmox
    1
    0 Stimmen
    1 Beiträge
    123 Aufrufe
    Niemand hat geantwortet
  • Meine AMD Ryzen 5 8600G Story

    Linux
    2
    0 Stimmen
    2 Beiträge
    651 Aufrufe
    FrankMF

    Ich habe nun ein 64GB G.Skill Ripjaws S5 schwaru DDR5-5200DIMM CL36 Dual Kit verbaut.

    Beim ersten Einschalten im BIOS die Einstellungen kontrolliert. Speicher mit korrekter Geschwindigkeit (Auto) erkannt. Neu gestartet und erster Test Standby. Scheint zu Laufen. Dann werde ich das mal die nächsten Tage beobachten.

    Kann mir jemand erklären, warum AM5 Boards so furchtbar langsam sind? Also z.B. das Erwachen aus dem Standby, BIOS aufrufen usw. Da sind AM4 Boards ja geradezu Formel1 Boliden.

  • ZFS - Wichtige Befehle

    Linux
    2
    0 Stimmen
    2 Beiträge
    651 Aufrufe
    FrankMF

    Unter dem Beitrag sammel ich mal ein paar Beispiele, für mich zum Nachlesen 🙂

    Den Anfang macht die

    ZFS-Replication

    Ich hatte Am Anfang ein wenig Verständnisprobleme, bis es klar war, das diese Replication von Pool zu Pool funktioniert. Also brauchen wir zwei vorhandene ZFS-Pools.

    root@pbs:/mnt/datastore/datapool/test# zfs list NAME USED AVAIL REFER MOUNTPOINT Backup_Home 222G 677G 222G /mnt/datastore/Backup_Home datapool 2.36G 1.75T 2.36G /mnt/datastore/datapool

    Wir erzeugen ein Dataset im datapool

    zfs create datapool/docs -o mountpoint=/docs

    Wir erzeugen eine Datei mit Inhalt

    echo "version 1" > /docs/data.txt

    Wir erzeugen einen Snapshot

    zfs snapshot datapool/docs@today

    Kontrolle

    root@pbs:/mnt/datastore/datapool/test# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT datapool/docs@today 0B - 96K -

    Wir replizieren den vorhandenen Snapshot zum ZFS-Pool Backup_Home und speichern ihn da im Dataset test.

    zfs send datapool/docs@today | zfs receive Backup_Home/test

    Nun befinden sich die Daten in dem anderen ZFS-Pool

    root@pbs:/mnt/datastore/datapool/test# ls /mnt/datastore/Backup_Home/test/ data.txt

    Und was mich am meisten interessiert, ist wie man das zu einem anderen Server schickt 😉

    zfs send datapool/docs@today | ssh otherserver zfs receive backuppool/backup

    Den Test reiche ich dann später nach.

    Quelle: https://www.howtoforge.com/tutorial/how-to-use-snapshots-clones-and-replication-in-zfs-on-linux/

    ZFS inkrementelle Replication

    Als, nur die geänderten Daten senden!

    Wir erzeugen ein paar Dateien

    root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data1.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data2.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data3.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data4.txt

    Neuer Snapshot

    zfs snapshot datapool/docs@17:02

    Liste der Snapshots

    root@pbs:/mnt/datastore/datapool/test# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT datapool/docs@today 56K - 96K - datapool/docs@17:02 0B - 112K -

    Wir senden dieinkrementelle Replication

    zfs send -vi datapool/docs@today datapool/docs@17:02 | zfs receive Backup_Home/test send from datapool/docs@today to datapool/docs@17:02 estimated size is 38.6K total estimated size is 38.6K cannot receive incremental stream: destination Backup_Home/test has been modified since most recent snapshot

    Dazu schreibt die Anleitung, die ich unten verlinkt habe, das die Daten verändert wurden. Warum, verstehe ich aktuell noch nicht. Mit -F im send Befehl erzwingt man einen Rollback zum letzten Snapshot.

    zfs send -vi datapool/docs@today datapool/docs@17:02 | zfs receive -F Backup_Home/test send from datapool/docs@today to datapool/docs@17:02 estimated size is 38.6K total estimated size is 38.6K

    Und Kontrolle

    ls /mnt/datastore/Backup_Home/test/ data1.txt data2.txt data3.txt data4.txt data.txt

    Quelle: https://klarasystems.com/articles/introduction-to-zfs-replication/

  • Wireguard - nmcli

    Wireguard
    1
    0 Stimmen
    1 Beiträge
    534 Aufrufe
    Niemand hat geantwortet
  • Nextcloud - Upgrade auf 19.0.1

    Nextcloud
    1
    0 Stimmen
    1 Beiträge
    225 Aufrufe
    Niemand hat geantwortet
  • Kopia - HTTP/S Server

    Verschoben Kopia
    3
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF

    Ich hatte ein paar Probleme, die ich mir teilweise nicht erklären kann 🤔

    Ich möchte den Kopia Server gerne über systemd steuern.

    SystemD [Unit] Description=Kopia Server After=syslog.target After=network.target [Service] Type=simple User=kopia Group=kopia ExecStart=/usr/bin/kopia server --tls-cert-file /home/kopia-server/fullchain.pem --tls-key-file /home/kopia-server/privkey.pem --htpasswd-file /home/kopia-server/.htpasswd --address <IPv4>:51515 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

    Danach

    systemctl daemon-reload systemctl start kopia-server

    Mit

    systemctl status kopia-server

    kann man sich den Status anzeigen lassen.

    Client Rechner

    Auf dem Client, der das Backup zum Server schicken soll, machen wir dann folgendes.

    USER@HOSTNAME:~$ kopia repo connect server --url=https://<DOMAIN>:51515 --override-username=USER --override-hostname=HOSTNAME Enter password to open repository: Connected to repository API Server. NOTICE: Kopia will check for updates on GitHub every 7 days, starting 24 hours after first use. To disable this behavior, set environment variable KOPIA_CHECK_FOR_UPDATES=false Alternatively you can remove the file "/home/frank/.config/kopia/repository.config.update-info.json".

    Danach steht die Verbindung und wir können Backups hochschieben.

    kopia snapshot create $HOME

    Damit wird das Homeverzeichnis gesichert. Das initiale Backup, hat 30 Minuten gebraucht.

    created snapshot with root kb9e50ff5xxxxxxxxxx265d40a5d0861 and ID cda5c0ffxxxxxxxxxxxxxxa4cb4a367b in 30m28s

    Ein späteres Backup, sieht so aus.

    USER@HOSTNAME:~$ kopia snapshot create $HOME Snapshotting USER@HOSTNAME:/home/frank ... * 0 hashing, 51 hashed (324.8 MB), 8524 cached (6.6 GB), 0 uploaded (0 B), 0 errors 100.0% Created snapshot with root kc20a4xxxxxxxxxxxx745c6c7b37c and ID d7a96eaxxxxxxxxxxx0961018eacffa in 3m12s

    Nach 3 Minuten durch. Zu diesem Zeitpunkt hat sich aber auch nicht wirklich was geändert!

    Fazit

    Das Tool macht immer noch einen sehr guten Eindruck. Die Geschwindigkeit ist sehr gut. Die Anleitung ist leider unzureichend. Da gibt es so viele Möglichkeiten, da braucht es sehr lange, bis man da mal durchsteigt. Zum Glück, ist das was man normalerweise braucht, recht überschaubar. Bis zum produktiven Einsatz braucht das aber bei mir noch eine Menge mehr Tests.

    Was ich noch testen möchte

    Verzeichnis mounten Backup testweise wieder herstellen (zumindestens teilweise)

    Der Test läuft mit Standard Einstellungen, also z.B. ohne Kompression. Das sollte man dann auch mal testen..

    Bitte achtet auf gleiche Versionen auf dem Clienten, wie auf dem Server. Ich meine da ein paar Probleme festgestellt zu haben...

  • ROCKPro64 - 0.9.16 mit Kernel 5.6 auf PCIe NVMe SSD

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    376 Aufrufe
    Niemand hat geantwortet
  • Linux Umstieg - 6 Jahre

    Verschoben Allgemeine Diskussionen
    1
    1 Stimmen
    1 Beiträge
    266 Aufrufe
    Niemand hat geantwortet