Gab heute Nacht einen längeren und grade einen kleinen Schluckauf im FFNW Backbone. Sollte aber alles wieder gehen. Falls nicht eben Meldung im Sörungsbereich auf machen.
Auch von meiner Seite kurz Stellung dazu: Heute Nacht hat ein ISP an einem VLAN was rumgewurschtelt und dabei wohl alle VLANS von uns entfernt. Ende vom lied: In der Nacht ging im v4 Bereich nicht mehr viel. Heute mrogen gegen 6:30 hab ich es behoben.
Eben gerade gab es ein wenig Schluckauf, da die NAT Export IPs bei uns nicht mehr imported wurden - Techniker ist informiert
Forum und zugehörige VM aktualisiert.
FanLin-Blech und VM mit Sicherheitsupdates versorgt; u.a. DSA-4196.
Reboot erfolgt direkt.
PR für Knotenstatistiken bearbeitet.
Befehl zum Filtern der nodes.json:
for i in $(cat macs.txt); do jq ".nodes[] | select(.nodeinfo.node_id==\"$i\")" nodes.json |grep 'node_id\|contact'; done
Node Statistiken repariert.
Statistik VM upgedatet.
Hab mal den Loglevel von unserem Grafana vom default Level Trace
auf Error
runtergedreht und das Consolen bzw. syslog logging abgedreht.
Voyager neu gestartet da die Auslastung hochgeschossen ist. Kam nach dem Reboot nur kurz wieder. Erst der Hetzner Hardware Reset hat ihn wieder zum leben erweckt.
Mastodon auf die neue Version 2.4.0 upgedated. Außerdem eine Blacklist für Nginx angelegt, um Spambots fernzuhalten. Content Security Policy von Nginx musste nach dem Update angepasst werden, da sonst keine Bilder mehr hochgeladen werden konnten.
Mehrere Tunneldigger Instanzen auf Automatix neu gestartet.
Mehrere Gateways neu gestartet um das Problem mit der spray-and-pray Methode zu beheben, welches @corny456 dann hier behoben hat:
dabei py-respondd auf corny manuell nach gestartet, weil es von selbst nicht wollte.
Irgendeine Nase hat ifupdown2 auf Deshyper-01 installiert. Bitte darauf achten, das nicht zu tun. Ifupdown2 kommt mit unserer komplexen Netzwerkarchitektur nicht zu recht, daher war der Server offline.
Habe aus dem Rescue-System per chroot ifupdown(1) wieder eingespielt. Jetzt läuft Deshyper-01 wieder.
Statistics VM auf Deshyper-01 wieder gestartet.
Hypercorn hat eine neue Festplatte bekommen und macht grad den resync des RAID’s. Hypercorn und somit Gateway Corny ist dank der Hilfe von @MPW seit gestern wieder online. Irgendwann musst du mir nochmal erklären was genau du da gemacht hast
Somit sollte alles bis auf Corny2 wieder rennen. Die Corny2 VM ist durch #hetznerdown in den Schredder geplumpst und wird in den nächsten Tagen ersetzt.
Einfach mit der Lara aus Grub Rescue gestartet und die Bootreihenfolge der Platten im Bios getauscht.
Corny2 wieder neu aufzusetzen wäre doch mal ein super Job für @wurmi und @fll.
Klar. Ich bereite nächste Tage die VM vor dann können die zwei loslegen.
Beim Fläschen der AC-Lite für den Hawerkamp haben wir die bootselect-Partition nicht gelöscht. Leider kann man das in unserer Firmware nicht nachträglich nachholen.
root@HAW-Gluon-Sd:~# cat /proc/mtd | grep bs
mtd7: 00020000 00010000 "bs"
root@HAW-Gluon-Sd:~# dd if=/dev/zero bs=1 count=1 of=/dev/mtd7
dd: can't open '/dev/mtd7': Permission denied
Details: https://forum.freifunk.net/t/unifi-ac-mesh-pro/13863/100?u=mpw
Wie es richtig geht: https://wiki.darmstadt.freifunk.net/Unifi_AC#5_Bootselect_schreiben
Ich habe daher erstmal den Autoupdater auf den drei Geräten hier deaktiviert:
HAW-Gluon-Süd
HAW-Gluon-Nord
Tankstelle-Nottuln-2
@fll @wurmi: Davon sind ebenfalls die AC-Lite betroffen, die wir in Hiltrup und Amelsbüren aufgebaut haben.
Es gibt schon 69 AC-Lite bei uns im Netz \o/ und noch einige AC-Mesh.
Da müssen wir auf jeden Fall die Leute kontaktieren, bevor wir die Firmware ausrollen. Die Wahrscheinlichkeit für einen Softbrick liegt wohl so bei 50%.
Entweder das riskieren und die dann im neueren Gluon entsperrte Partition löschen. Dabei muss man zu 50% per tftp an die Geräte ran. Oder von vorne herein einmal zurück auf die Originalfirmware fläschen.
Für Hiltrup und Amelsbüren könnten wir evtl. per SSH zurück auf die Originalfirmware, dann richtig fläschen und per Portweiterleitung neu konfigurieren. Das ist vermutlich unter dem Strich besser als nachher hinzufahren, denn ein Gerät pro Standort würde es sonst vermutlich sicherlich erwischen.