Knoten und Client Status im Wordpress gefixt.
\o/
5 „Gefällt mir“
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. 
2 „Gefällt mir“
Trag mich bitte mal mit meiner AOL-Adresse dafür ein.
1 „Gefällt mir“
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.
Auf Des2 teste ich jetzt feste Mac-Adressen für die Brücken, in die die L2TP-Verbindungen gehängt werden.
Details: Designfehler: dynamische Macadresse der Brücken auf den Gateways
PS: Zusätzlich gerade die Gretap-Rolle auf alle Gateways ausgerollt, dadurch kriegt der neue Kartenserver jetzt alle Kartendaten.
Mal sehen, ob das eine sichtbare Zäsur in den Statistiken gibt.
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.
Auf Des1 Kerneldowngrade von 4.9 auf 4.7.
Das Batman aus Kernel 4.9 mag nicht arbeiten:
# batctl -m bat12 o
Error - mesh has not been enabled yet
Activate your mesh by adding interfaces to batman-advAuf des1 schien das Problem ein Anderes zu sein. Siehe Kommentar zu:
- 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
karteneuausgerollt. 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).
- und bestimmt 1000 Sachen, die ich vergessen habe.
5 „Gefällt mir“
Forum aktualisiert:
3 „Gefällt mir“
- node-respondd wieder deaktiviert, da es einen zu großen Ressourcenbedarf hatte.
- logging für named angepasst
- es wird nun in ein eigenes logfile geschrieben
- es wird jetzt nur noch ab der stufe “error” geloggt
- logrotate für named und tunneldigger-broker konfiguriert
1 „Gefällt mir“
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.
1 „Gefällt mir“
des2 hatte gerade eine kurze Downtime, läuft aber nun alles wieder.
PS: Habe dann natürlich gleich Updates eingespielt.
1 „Gefällt mir“
Security Updates auf Nightbounce eingespielt, reboot.
3 „Gefällt mir“
Ich habe mir jetzt mal angeschaut, warum die iptables regeln nie nach einem neustart laden:
netfilter-persistent.service (welches die iptables regeln lädt) wird von systemd nicht gestartet, da es abhängigkeitsprobleme gibt, die dadurch entstehen, dass zuvor das laden eines kernelmoduls fehlschlägt, das laden des kernelmoduls schlägt fehl, weil zwar ein neuer kernel (4.7) installiert wurde aber nicht die passenden headers dazu.
Da 4.7 nicht mehr supportet ist und ich auch gerade nicht die headers zur hand hatte, habe ich kurzerhand kernel in version 4.9.4 installiert. Nun läuft alles wie es soll. 
3 „Gefällt mir“
Wegen geplanter Wartungsarbeiten an der Stromversorgung werde ich das fanlin-Blech, heute um 22:55, herunterfahren.
Es soll nur ein Ausfall von ca. 20 Minuten entstehen, aber im Zeitraum von 23:00 bis 07:00 des Folgetages. 
Servdiscount - Status - Webseite
1 „Gefällt mir“
Des1 neugestartet da sich in Dom25 das batman auf die Nase gelegt hat.
Anschließend auf Parad0x den Tunneldigger neugestartet zum Knoten verteilen.
1 „Gefällt mir“
Auf Des2 und Nightbounce IPV6 repariert, dazu Ansible gateways_batman und gateway_l2tp ausgerollt.
1 „Gefällt mir“