Keine Updates…aber Parad0x musste wegen Wartung am Hypervisor für etwa 3 Minuten vom Netz genommen werden. Der Server scheint es gut überstanden zu haben.
Firewall vor jetplow/nightbounce aktiviert. Hetzer Special: v4 only (facepalm)
Jetplow/Nightbounce war komplett weg. Ursache Unklar auffällig war das zeitgleich Hetzner ne IP aufgeschaltet hat. Beim Hochfahren war’s auch nicht sauber. Hetzner Firewall abgeschaltet.
Jetzt (13:04) Host nochmal durchgestartet um sicherzugehen das alles sauber hochkommt oder da nicht was krumm ist.
Ein bisschen im Hintergrund am node-stats gewerkelt. U. a. wird jetzt auf Basis der MAC erkennt, welcher batman neighbour das gateway ist (falls vpn) und entsprechend abgelegt, sodass man sich jetzt leicht die GW-Verbindungs-TQ anzeigen lassen kann.
Danach habe ich das Grafana-Dashboard mal etwas überarbeitet: https://freifunk-muensterland.de/grafana/dashboard/db/advanced-node-stats?var-node=a0f3c15b4180
@Handle Wie weit bist du mit Hopglass-Server/Prometheus? Ansonsten würde ich mich nämlich noch mal etwas grundlegender an das node-stats setzen, das ist sehr uggly vong code stiehl her (wobei das bei so string/json hin und her konvertiere nie so wirklich hübsch wird, aber so wie es derzeit ist, ists kacke).
@descilla beim HopGlass-Server habe ich die Ansible-Files jetzt soweit fertig. Die Config müsste man dann ggf. noch an der ein oder anderen Stelle für unsere Zwecke ergänzen. Nach einem letzten Test mache ich dann ein Pull Request in unserem Github-Repo auf, dann könnt ihr noch mal drüberschauen.
Dann ist HopGlass dran und danach Prometheus
Edit: PR im Repo eröffnet.
In ISC-DHCP Bug Leasefile löschen - #32 von paulinsche hatte ich schon auf diese Standardverhalten des ISC-KEA hingewiesen.
Tunneldigger auf Nightbounce neu gestartet, weil da irgendwie sehr wenige L2TP-Verbindungen liefen.
Da ist noch was anderes kaputt. Habe die Kiste gestern schon mal rebootet (und dann iptables regeln neu geladen und dann noch mal tunneldigger restarted), leider ohne Erfolg. @kgbvax ist die fw dort noch aktiv?
Der Server bezreg-srv (Domplatz) wurde durch Herrn F. manuell neu gestartet. Er reagiert wieder, hat aber noch ein Problem bei einer der beiden Gluon-VMs. Ob das an fehlendem Uplink oder sonswas liegt kann ich erst nach der Arbeit analysieren.
Status siehe
- https://freifunk-muensterland.de/grafana/dashboard/db/advanced-node-stats
- https://karte.freifunk-muensterland.de/map/#!v:m;n:525400751a8d
Was mir gestern noch aufgefallen ist. Der Hostname passt nicht zum Namenskonzept. Wäre gut, wenn wir den bei der nächsten Wartung in BEZ-Hypervisor oder BEZ-Server umbenennen können. Siehe auch internes Wiki.
Bei der neu-installierten VM für Dom16 war Autostart nicht aktiviert.
Security Patches auf Wiki, Forum, Mailvax installiert und dabei die Forums Mail reanimiert
Nochmal geschaut. Ist aus !!1!
deshyper-01 hatte sich heute Morgen verabschiedet. War leider den ganzen Tag unterwegs, habe ihn gerade mal restarted.
Auf fanlin läuft / voll. Um 15:00 wird das Blech kurzzeitig heruntergefahren und das Filesystem wird vergrößert.
…
So, nu stehen 19 GB freier Plattenplatz, auf /, zur Verfügung
Auf dem FanLin Gateway wurde nach dem Neustart der kea-dhcp4 Server nicht gestartet, da es noch ein Lock-File gab (vermutlich wurde der Dienst zuvor nicht korrekt beendet). Habe dieses entfernt und den kea-dhcp4 Server gestartet.
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.
@corny456 ist jetzt Vollmitglied im Adminteam. Herzlich Willkommen und Danke für deine viele Arbeit, die du bisher schon gemacht hast.