Hallo
Zwei Server haben iptables am Laufen. Checkmk ist auf beiden Servern der Meinung, dass iptables nicht am Laufen ist und setzt Systemd Service Summary auf kritisch.
Wie kann ich das in Ordnung bringen?
Besten Dank
Martin
Was sagt denn systemctl status iptables.service (bzw. systemctl status derjenigen Unit, die da angemeckert wird)?
Ich habe bei mir (Ubuntu 22) zwar iptables installiert, aber gar keine Unit dafür. 
Ggf. kannst du mal mit systemctl reset-failed iptables.service den Zustand von failed wieder zurücksetzen.
Wenn du sicher bist, dass iptables korrekt läuft und nur die systemd-Unit dafür spinnt, kannst du die auch bei der Summary ignorieren. Da gibt es eine Regel für.
2 Likes
Hallo Dirk
Der Dienst von iptables läuft ganz sicher. vor wenigen Tagen musste die beiden Server neu starten und nach dem Start konnte iptables wegen einem Problem nicht starten. Ich behob das Problem und dann war gut.
Ich vermute, dass seit diesem Zeitpunkt Checkmk den Zustand falsch meldet.
systemctl reset-failed iptables habe ich vorher schon durchgeführt, was leider nicht geholfen hat.
kannst du die auch bei der Summary ignorieren. Da gibt es eine Regel für.
Okay, das kann ich suchen. Wir dann der Service immer noch korrekt überwacht? Das wäre schon wichtig.
Danke!
Hallo Martin,
najaaa, ich habe z.B. diesen Service:
Logrotate spinnt bei mir gelegentlich mal, wenn er MySQL-Logfiles packen soll. Das juckt mich aber nicht. Am nächsten Tag (wenn logrotate wieder per Timer gestartet wird) ist das meist weg.
Ich könnte jetzt folgende Regel einrichten:
Dann wäre das CRIT weg, aber dann kriege ich natürlich nicht mehr mit, wenn logrotate nicht funktioniert.
Auf dem Host sieht das “failed” so aus:
# systemctl status logrotate.service
× logrotate.service - Rotate log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static)
Active: failed (Result: exit-code) since Fri 2024-04-26 00:00:19 CEST; 14h ago
Nach einem systemctl reset-failed logrotate.service geht die Meldung aber weg und in checkmk wird der Service wieder grün.
Insofern weiß ich jetzt nicht, warum das bei dir nicht klappt. Was zeigt denn dein systemctl status iptables.service an und wie sieht das in der checkmk-GUI aus?
Gruß Dirk
Hallo Dirk
Ein systemctl status iptables sieht unauffällig aus:
iptables.service - IPv4 firewall with iptables Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: disabled) Active: active (exited) since Thu 2024-04-25 12:13:00 CEST; 1 day 6h ago Main PID: 836886 (code=exited, status=0/SUCCESS) Tasks: 0 Memory: 0B CGroup: /system.slice/iptables.service
Der Firewall finde ich noch als wichtiges Teil und den zu überwachen ist schon sehr wichtig.
Ihn von der Überwachung auszuschliessen ist nicht gerade mein Ziel.
wie sieht das in der checkmk-GUI aus
Da weiss ich gerade nicht, was du sehen möchtest. Aber gebe die mal dies:
Danke!
Hallo Martin,
danke. Genau das meinte ich. Aber jetzt stehe ich echt auf dem Schlauch.
Ich würde vielleicht mal
systemctl status --all --type service --no-pager --lines 0
auf dem Host machen (das ist einer der Befehle, mit denen der Agent die systemd-Daten einsammelt) und gucken, ob mir da was bzgl. iptables auffällt.
Hallo Dirk
Das Problem hat sich selber gelöst. Heute Morgen ging der Alarm einfach mal in den Feierabend.
Vorher arbeitete ich allerdings an der Firewall. Ich musste einige Regeln einbauen und ergänzen. Weil ich mit zuwenig Kaffee in Gehin arbeitete, musste iptables mehrfach stoppen und starten.
Vielleicht war halt doch irgendein Resten in den systemd-Daten vorhanden. Seltsam ist es alleweil.
Den Befehl systemctl status --all --type service --no-pager --lines 0 kannte ich so nicht. Das ist sehr hilfreich.
Besten Dank für deine Hilfe.
Sehr gut, gern geschehen.
Das ist einer der drei Befehle, die der Agent absetzt und die der checkmk-Server auswertet.
Die anderen beiden sind
systemctl list-unit-files --full --no-legend --no-pager --plain --type service
systemctl --all --full --no-legend --no-pager --plain --type service
(Ich habe das auch nur im checkmk-Agent nachgeguckt.)