Hallo Leute, ich richte gerade den CheckMk-Agent auf meinen Linux-Servern ein. Dies funktioniert bis auf einen Server auch erfolgreich. Leider gibt es bei einem Server Probleme mit der Kommunikation. Ein Blick in die systemctl hat gezeigt, das bei diesem Server system-check_mk.slice nicht geladen wurde. Wie lässt sich dies manuell erledigen? Ein löschen und erneut installieren des Agent hat das Problem leider nicht behoben.
Danke für die Unterstützung
Bei einer Verwendung des Agenten mittels systemd muss doch nur der “check_mk.socket” aktiv sein.
Also der “system-check_mk.slice” wird erst geladen sobald eine Abfrage auf den “check_mk.socket” erfolgte.
Schau mal nach was ein “systemctl status check_mk.socket” ergibt.
2 Likes
Der Status ist loaded und active (listening). Die Host-Diagnose liefert aber: Communication failed: timed out. Gibt es irgendeine Abhängigkeit, die fehlt?
Tests auf dem nicht erreichbaren Host laufen lokal durch ?
Falls lokal ein telnet installiert ist telnet 127.0.0.1 6551 mal starten und dann Schritt für Schritt vom System zum Server arbeiten.
Gruss
1 Like
telnet 127.0.0.1 6551
Hat sich der Port geändert?
Standard ist:
- 6556 - Agent
- 6557 - Livestatus
- 6558 - Realtime Checks
nope
Tippfehler
Gruss
Hallo,
telnet 127.0.0.1. 6556 liefert etliche Ergebniszeilen. telnet mit den beiden anderen Posts: Unable to connect to remote host. Laut systemctl ist der Check_MK Agent Socket loaded, attive (listening). Gibt es irgendwo eine Log-Datei, in der Hinweise auf das Problem stehen könnten?
bedeutet lokal läuft alles
jetzt wechsel zum Server und versuche den gleichen Befehl aber nicht mit 127.0.0.1 sondern mit der IP des Systems auf dem es lokal klappt.
Gruss
Vom Server aus funktioniert der Ping auf den Rechner, aber telnet liefert bei allen Ports einen TimeOut. Der Port 6556 auf dem Rechner ist offen. Der Server überwacht 6 weitere Rechner ohne Probleme.
da allen mir ein
Server im Client für Zugriff nicht zugelassen in der agent-config
Server und Client stehen getrennt durch Netzwerkkomponeten und ein Filter/ Blocker sperrt
am Client firewall oder andere security-tools aktiv?
Gruss
Ansonsten mal in der Konfigurationsdatei deines Agents mal nach der Zeile only from = ... suchen. Ist diese korrekt?
Ich habe zwei identische Rechner (gleiche Hardware, identisches Betriebssystem), die beide dieselbe Konfiguration besitzen. Lediglich die installierte Software ist unterschiedlich. Die Einstellungen der Firewall unterscheiden sich auch nicht. Der eine Rechner kann überwacht werden, der andere macht die Probleme. Gibt es eine Übersicht welche Abhängigkeiten für den Agent benötigt werden?
Hast du dir schon die Logs von deinem fehlerhaften Agent angeschaut? Vielleicht liefert es hilfreiche Antworten.
Wenn der agent lokal,Ergebnisse liefert sollte das auch remote klappen wenn er richtig konfiguriert ist.
Netzwerk sauber auf dem Client konfiguriert. Gateway und Netmask ok?
Gruss
Bei der unterschiedlichen Software ist nicht noch zufällig irgendeine Snakeoil-Software dabei (Bitdefender, Kaspersky, Comodo, ZoneWall), die dir hier reingrätscht?
1 Like
Nein, es gibt keine Snakeoil-Software auf den Rechner. Es sind Linux-Rechner auf Debian-Basis. Das Netzwerk auf dem Rechner funktioniert auch sauber, da dort unser GIT-Repro liegt und regelmäßig auf die gepusht und gepullt wird. Der Serve kann den Rechner im Moment leider nur über ping überwachen.
Ach Linux.
Überwachst du den Agent per XinetD oder per SSH?
Mit systemctl status xinetd.service kannst du schauen ob der Dienst läuft. Er ist zuständig dafür, dass dein Agent auf 6556 abrufbar ist.
Ansonsten kannst du auch generell schauen ob der Port “oben” ist mit ss -tnl oder alternativ mit netstat (parameter bleiben gleich).
Auf dem Rechner liefert netstat folgendes:
tcp6 0 0 :::6556 :::* LISTEN 0 15302 1/init
Der andere Rechner mit derselben Hardware liefert zusätzlich folgende Zeile:
tcp6 0 0 XXX.XXX.XXX.XXX:6556 XXX.XXX.XXX.XXX:37180 TIME_WAIT 0 0 -
Ich habe mir dann mal den Status von xinetd.service angesehen. Dort finde ich Fehler. Sie lauten:
bind failed (Address already in use). Jetzt lautet die Frage, wer diese Adresse verwendet.
Dann füge deinem Befehl noch den Parameter -p hinzu, er zeigt dir die ProcessID desjenigen Prozesses, der den Port verwendet.
Ganz oben im Thread steht doch der Agent verwendet nicht xinetd sondern systemd.
Damit ist doch geklärt wer den Port hat. Und xinetd hat auf dem System nix verloren also jedenfalls die Agent Config vom xinetd sollte hier nicht aktiv sein.
@spacer2020 deine netstat Ausgabe sagt aber auch nur, dass der eine Prozess auf alle IPs lauscht und der andere nur auf einer bestimmten. Ist erstmal nicht weiter problematisch.