Gestern Abend den Kernel auf bezreg-srv von Version 4.7 auf 4.8 aktualisiert, sowie GRO und GSO auf dem Hypervisor auf den physischen Interfaces sowie den Bridges deaktiviert (bzw. Eintrag in der Interfaces-Datei hinzugefügt). Zusammen mit @Alucardo die Firmwareversion der Dom01-KVM auf Version 2.2.0 aktualisiert (dabei wieder geshreddert und neu installiert). Btw: Dabei ist mir aufgefallen, dass ich auf der Dom01 VM schon beim letzten Mal vergessen hatte eth2 in die client-bridge zu werfen.
PS: Ich habe gestern zum Testen das Kabel vom wz-uplink von wan-mesh ins lan-mesh gesteckt und vergessen es wieder umzustecken. Also @MPW bitte nicht wundern, wenn dein Script nicht funktioniert.
PPS: Flow Control auf den ToughSwitch in der oberen Ebene auf allen Ports deaktiviert.
Ich habe die Tatsache, dass der kea-dhcp4 Server auf nightbounce folgendes sagte: Active: failed (Result: exit-code) since Mon 2016-12-26 20:06:47 CET; 6 days ago, und wir nur hierdurch darauf aufmerksam geworden sind, mal zum Anlass genommen das Alerting für Prozesse zu erstellen (die Metriken liegen schon etwas länger vor, ich bin nur nicht dazu gekommen sie auch zu nutzen.
Kurzum: Die Prozesse für
keadhcp4
bird
bird6
named
tunneldigger
wird geschaut, ob mindestens ein Prozess läuft, andernfalls wird ein Alert ausgelöst und wir bekommen ne mail.
Hinweis: Prozess läuft != Prozess tut. Daher könnte man das sicherlich optimieren. Den Status von systemd auszulsesen wäre z. B. eine Möglichkeit. Es gibt durchaus Szenarien in denen der Prozess noch läuft (aber nicht mehr reagiert), aber systemd schon “weiß”, dass der Prozess kaputt ist. Hätte, könnte, würde, … für die allermeisten Fälle bekommen wir allerdings jetzt ein Alert.
Gateway fanlin hatte seit Tagen quasi keine l2tp Verbindungen mehr angenommen. Es scheint so, dass der tunneldigger Patch dort nicht ausgerollt wurde. Leider ließ sich der Patch auch nicht applizieren. Daher habe ich das Verzeichnis verschoben und die l2tp rolle erneut ausgerollt. Jetzt scheint es wieder zu funktionieren.
kea-dhcp4 war auf des1 abgeraucht, Monitoring hat es erkannt (nach 3 Minuten Mail erhalten) und ich habe ihn gerade neu gestartet (nach 3 Stunden), da ich eher keine Zeit hatte.
Möchte jemand aus dem @Adminteam (oder sonst jemand) die Alert-Mails erhalten? Dann geht das vielleicht schneller.
Gestern Abend auf allen Gateways ein dist-upgrade durchgeführt. Dadurch wird sich der Kernel nach dem nächsten reboot auf Version 4.8 aktualisieren. Auf nightbounce konnte dkms die Virtualisierungsmodule für Kernel 4.8 nicht bauen. Falls du die also brauchst, @kgbvax, sollten wir die in einer neueren Version installieren.
Auf des1 hatte sich vorhin der tunneldigger restarted. Ich habe die Gunst der Stunde genutzt und die VM, sowie den Hypervisor neu zu starten. Ich habe auf des1 den Kernel 4.9.1 installiert. Ich bin mal gespannt, wie der so läuft.
hypervisor von des2 (und somit auch des2) neu gestartet, da upgrades durchgeführt werden mussten. Vorher noch die von @Fungur angepasste batman rolle ausgerollt. Die interfaces kamen erfolgreich mit ipv6 wieder hoch.
Logfile-Einstellungen von kea-dhcp4 geändert (von INFO auf WARN umgestellt)
logrotate angepasst
jetzt wird auch das kea-dhcp4 logfile rotiert
außerdem wurden die rotate und count Einstellungen nicht auf die einträge in /etc/logrotate.d/ angewandt.
Außerdem habe ich die tasks zum bauen von batctl angepasst
ab batadv 2016.3 fallen die einträge im debugfs weg und es muss über netlink/ioctl gearbeitet werden. Das konnte die bisherige batctl Version (2015.1) nicht. batctl 2016.4 (was nun installiert wird) funktioniert aber auch noch mit dem 4.7er Kerneln, respektive batadv 2016.2 (getestet).
es wird nun geprüft ob die passende Version installiert ist, ansonsten wird neu gebaut.
Erforderliche Pakete zum bauen hinzugefügt (libnl-genl-3-dev)
respondd Rolle aktualisiert und auf allen Gateways ausgerollt
repos von nodejs (und key) werden hinzugefügt
abhängigkeit nodejs wird nun installiert
die node-respondd-* services werden nun auch aktiviert
“networking restart” Handler angepasst (überall werden nun die selben Aufrufe durchgeführt)
es wird nun auch der kea-dhcp-server restartet
tunearpcache dem services playbook hinzugefügt und auf karteneu ausgerollt. Dort ist der ndisc cache vollgelaufen (respondd geht ja über ipv6 multicast).
hopglass server
Daten werden nun über nginx reverse-proxy ausgeliefert
dadurch ist die nodes.json ist 403 kb anstatt 2,6 mb groß
Auf den Detailseiten zu den Nodes werden die Statistiken jetzt als Grafana-Iframe eingeblendet (schön interaktiv)
Auf der globalen Statusseite findet sich jetzt der Status aller Grafana-Alerts.
Pull-Request von @Handle muss noch gemerged werden (da sollte das alles drin sein, aber @Handle hat noch einiges mehr gemacht).
sysupgrade auf fanlin durchgeführt (ohne Kernelupgrade) und neu gestartet, da:
PS: Es bleibt zu beobachten, ob das BATMAN-Problem unter 4.9 weiterhin besteht. Für die Eifrigen unter euch: Ihr könnt ja mal die entsprechenden Commit-Messages zwischen 4.7 und 4.9 durchblättern.
Ich habe auf der Service-VM und auf dem Firmwareserver simp_le aus einem neuen Git-Repository neu installiert (weil das alte nicht mehr funktioniert) und dann neue Let’s-Encrypt-Zertifikate erzeugt.
