deshyper-01 und deshyper-02 und alle dazugehörigen vms aktualisiert und durchgebootet.
Tunneldigger auf parad0x restartet, da dort nach dem reboot von des1 650 l2tp verbindungen aktiv waren (und auf des1 nur 4). Jetzt ist es wieder einigermaßen ausgeglichen.
- Ansible-Rollen für KEA-DHCP Server erweitert.
- Collectd-Script für KEA-DHCP Erstellt.
- Das ganze auf
des2
zum Test ausgerollt.- Nach ca. 30 Minuten Laufzeit hat er > 1500 gültige Leases ausgegeben. Scheint also zu laufen (zu prüfen ist noch, ob die Leases auch beim Client ankommen und akzeptiert werden, da aber der Traffic nicht eingebrochen ist, gehe ich jetzt erstmal davon aus).
PS: Ich habe den KEA derzeit mit “memfile” (+persitent) konfiguriert. Also ohne psql. (Laut Doku soll memfile sogar der performanteste Weg sein.) Imho sollte man sich das mit psql+KEA nur anschauen, wenn man plant die Leasepools mit mehreren Gateways gemeinsam zu nutzen.
PPS: Die von @paulinsche erwähnte Problematik sollte beim KEA nicht auftreten, zumindest ist es laut diesem Beitrag das Standardverhalten von ISC-KEA.
bind9.service auf c1024, fanlin und servicevm sind gegen 21:30 abgekackt
auf allen anderen gateways gab es keine probleme.
die drei o. g. server sind als authorative namenserver für freifunk-muensterland.de konfiguriert da alle drei gefailed sind, ging die auflösung für alles für freifunk-muensterland.de nicht mehr fanlin und c1024 haben wohl gefailed, weil sie die servicevm (dns#53) nicht mehr erreichen konnten, warum bind9 auf der servicevm abgekackt ist, habe ich jetzt nicht nachgeschaut
bin jetzt auch zu müde dafür
vielleicht hat ja jemand lust
namensauflösung geht zumindest wieder
Edit: bind scheint auf der servicevm schon länger nicht zu laufen. im log steht schon länger (bis zum letzten log (syslog.7.gz kann ich es nachverfolgen, 2. Dezember) “Unit bind9.service cannot be reloaded because it is inactive.”, mehrfach.
Da der KEA-DHCP auf des2
auf Anhieb super lief, habe ich das jetzt nach und nach auf alle anderen Gateways ausgerollt. Scheint problemlos zu laufen.
Einzig beim bauen der Software war wohl auf parad0x
die Load so hoch, dass er alle l2tp Verbindungen abgeworfen hat, aber diese hat des2
super aufgefangen (habe die jetzt wieder verteilt). Und den Statistiken darf man auch noch nicht vertrauen. Da kommen manchmal negative Werte raus. Die bekomme ich aber bereits so über die KEA DHCP Socket-Schnittstelle.
PS: Da der ISC-KEA eine eierlegende Wollmilchsau ist, würde ich mich freuen wenn der ein oder andere sich mal unsere Konfiguration anschaut: Ich bin mir sicher, dass es da noch einiges zu optimieren gibt. Die ISC-KEA Doku findet ihr hier: https://ftp.isc.org/isc/kea/1.1.0/doc/kea-guide.html
Habe Parad0x und seinen Hypervisor mit Updates versorgt. Downtime war etwas über 5 Minuten.
Dito nightbounce, 0 downtime.
Ich habe in die collectd rolle ein paar neue Metriken eingebaut. Diese sind derzeit nur auf des2 ausgerollt. Eine Übersicht (außer das Histogram) seht ihr hier: https://freifunk-muensterland.de/grafana/dashboard/db/experimente
Collectd auf bezreg-srv
installiert. Und ein Dashboard dafür gebaut: https://freifunk-muensterland.de/grafana/dashboard/db/funk-backbone
Die Daten landen unter “funk_backbone”.
Alle Ubuntu Opfer (forum, wiki, mailserver) aktualisiert.
Alle Systeme aus der des-Dynastie nachgezogen. Und alle anderen Gateways ebenfalls aktualisiert. (PS: GW @FanLin war schon aktualisiert. )
PS: Service-VM habe ich auch mal aktualisiert. Diese müsste auf jeden Fall mal rebootet werden.
Ich habe mal auf den Gateways NTP installiert. Mir war aufgefallen, dass die Systemzeiten auf den verschiedenen Gateways teilweise über eine Minute auseinander lagen. Mir ist es bei den Statistiken aufgefallen, aber eine ungenaue Systemzeit ist sicherlich auch in anderen Kontexten eher suboptimal.
PS: Muss noch in Ansible eingepflegt werden.
Wo wir grad bei aktualisieren sind hab ich das beim Firmwareserver auch mal gemacht und auf reboot gedrückt…
hat sich gelohnt…
155 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
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.