Ich antworte mir mal selber: Da der icinga in einer VM läuft und ich vor dem OS-Upgrade einen Snapshot der VM gezogen hatte, konnte ich das Binary check_dhcp aus der alten Installation extrahieren und hier neu einfügen. Nun funktioniert es wieder - warum auch immer. Das ist zwar keine befriedigende Antwort aber immerhin ein Workaround mit dem ich erst einmal leben kann. Mark Am 30.10.20 um 14:38 schrieb Mark Wenzel:
Hallo zusammen,
ich habe hier ein seltsames Verhalten nach dem Upgrade von leap 15.1 auf leap 15.2.
Zum Verständnis: Ich habe drei Maschinen in diesem Szenario: 1. primärer DHCP-Server 192.168.23.10 (physischer Host) 2. sekundärer DHCP-Server 192.168.23.11 (physischer Host) 3. Icinga2-Server zur Systemüberwachung 192.168.23.21 (virtuelle Maschine unter VirtualBox; wahlweise auf dem ersten oder zweiten physischen Host).
Der Icinga2-Server prüft regelmäßig beide dhcp-Server über das Plugin check_dhcp (aus monitoring-plugins-dhcp vom Haupt-Repository). Bisherlief icinga2 unter leap 15.1 und hat bei beiden dhcp-Servern zuverlässig funktioniert, egal auf welcher physischen Maschine die VM lief.
Gestern habe ich den icinga2-server auf leap 15.2 aktualisiert. Die icinga2-Maschine läuft in diesem Beispiel auf dem ersten Host als virtuelle Maschine. Nun bekomme ich nur noch beim primären Server ein positives Ergebnis. Beim sekundären Server bekomme ich meistens einen critical-Fehler. Manchmal ist das Ergebnis aber auch OK. Ich habe daher das ganz auch mal manuell ausgeführt und dabei das Log des jeweiligen Servers angesehen:
icinga2# /usr/lib/nagios/plugins/check_dhcp -s 192.168.23.11 -u CRITICAL: Received 844387 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 600 sec.
secdhcp# journalctl -u dhcpd -f Okt 30 11:59:02 secdhcp dhcpd[5183]: DHCPDISCOVER from 08:00:27:4b:d1:e5 via eth0 Okt 30 11:59:02 secdhcp dhcpd[5183]: DHCPOFFER on 192.168.23.48 to 08:00:27:4b:d1:e5 via eth0
und
icinga2# /usr/lib/nagios/plugins/check_dhcp -s 192.168.23.10 -u OK: Received 945640 DHCPOFFER(s), 1 of 1 requested servers responded, max lease time = 600 sec.
pridhcp# journalctl -u dhcpd -f Okt 30 12:01:04 pridhcpdhcpd[19895]: DHCPDISCOVER from 08:00:27:4b:d1:e5 via eth0 Okt 30 12:01:05 pridhcpdhcpd[19895]: DHCPOFFER on 192.168.23.63 to 08:00:27:4b:d1:e5 via eth0
Ein tcpdump auf den beiden dhcp-Servern zeigt, dass die Anfragen beide beantwortet werden, was die Ausgaben im journal bestätigt. Mache ich auf dem icinga-Server einen tcpdump, tauchen dann aber die folgenden Datenpakete auf (Ich habe der besseren Lesbarkeit hier auf IP-Adressen verzichtet).
source | destination | Info icinga2 | secdhcp | DHCP Discover pridhcp | icinga2 | DHCP Offer secdhcp | icinga2 | DHCP Offer
Icinga2 | secdhcp | DHCP Discover pridhcp | icinga2 | DHCP Offer
Warum antwortet der primäre dhcp-Server, wenn doch der sekundäre alleine angesprochen wird? Und warum filtert das Plugin nicht die relevante Antwort heraus? Verschiebe ich den icinga-Server auf den anderen physischen Host, ist das Verhalten genau umgekehrt. Das heißt, dass nur noch der dhcp-Server erfolgreich getestet wird, der auf dem selben physischen Host läuft wie die VM mit icinga2.
Um eine Beteiligung der Firewall auszuschließen habe ich die Firewalls temporär auch schon alle ausgeschaltet. Das hat keinen Effekt!
Vielen Dank für das Mitdenken und den Schubs in die richtige Richtung. Mark -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org