Technische Informationen zum Freifunk Netzupdate

25 Okt

Der harte Kern der Admins (ich, Marvin und Madonius) befindet sich in diesem Moment immer noch im Hackerspace und beschäftigen sich mit dem Update des Freifunk-Saar Netzes (seit 9/10 Uhr morgens Samstag). Konkret handelt es sich hierbei um einen stufenweisen Rollout eines neuen Gluon-Updates, das von Batman-v14 auf v15 updatet und die MTU von fastd von 1426 auf 1406 senkt um IPv6 als äußeres Netz zu unterstützen.

Zur Vorbereitung habe ich 2 unserer 4 Gateways mit neuem Debian bespielt und den lange vorbereiteten SaltStack-State draufgebügelt. Der war natürlich nicht perfekt und musste weitere ca. 8 Stunden debuggt werden. Dann habe ich die Ports von Fastd geändert und die Mesh-WLAN-{B,E}SSID geändert um die Kompatibilität mit dem alten Netz komplett zu brechen und nervige Fehlermeldungen zu vermeiden. Dann habe ich eine Gluon v2015.1.2-basierte Firmware mit den neuen Einstellungen gebaut und an die Experimentals und Beta-Leute verteilt.

Vorspulen zu gestern morgen, dem Beginn des Hackathons. Es haben sich einige ToDos über die Zeit angesammelt und wir wollten mal ein paar davon angehen. Während das größte das Netzupdate war, haben wir spontan beschlossen ein paar Management-Services auf eine neue VM von GW1 weg auszulagern. Darauf wandert jetzt also Monitoring, Salt-Master, Kartengenerierung (und Alfred-Master) und Autoupdate-Server für (erstmal nur) das neue Netz.

Als dann alles vorbereitet war in dem neuen Netz, mussten wir noch einen sinnvollen Weg finden, das Update selber auf den Knoten auszurollen. Das Problem, das einem anfangs vielleicht nicht auffällt existiert wirklich nur bei einem Update des Meshing-Protokolls / -Mechanismus‘: Knoten, die nur über das WLAN-Mesh angeschlossen sind können nicht mehr mit dem Internet kommunizieren wenn ihr Internetknoten geupdatet wurde.

Die bisher sinnvollste Idee, die ich dazu gehört habe, gab es auf der Gluon-Mailingliste: Man kann den Netzgraph als einen mathematischen Baum betrachten, bei dem die Gateways zu einer Wurzel verschmelzen. Das Update muss dann manuell von unten nach oben im Baum ausgerollt werden. Die Knoten die am meisten WLAN-Mesh-Links bis zum nächsten GW haben werden zuerst versorgt und gehen dann erstmal offline. Danach kommt die „Schicht“ des Baumes eins weiter oben dran. Diese gehen dann auch offline. Das ganze wiederholt man dann so lange, bis man bei den Knoten angekommen ist, die direkt mit den GWs verbunden sind. Sobald diese geupdatet sind, kommen auch die reinen Mesh-Knoten wieder online.

Am schönsten kann man diesen Prozess beobachten, wenn man 2 Karten für die beiden Netze parallel betreibt. Ich habe uns ein kleines Skript geschrieben (IPv6-Präfix und Pfad zur nodes.json muss in der HTML-Datei angepasst werden, evtl Cross-Origin-Warnungen im Browser beachten und im Server auf dem die nodes.json liegt freigeben (Google hilft) oder runterladen und dann von da aus ausführen, IPv6-Calc Teile des Skripts aus dem Internet zusammengeklaut), das uns aus der sowieso erzeugten nodes.json die Distanzen raussucht, aus den Mac-Adressen die IPv6-Adressen berechnet und dann Allow-Befehle für die Config vom Apache des Autoupdater-Servers erzeugt. Dann haben wir auf diesem erstmal alles gesperrt und dann einzeln pro Welle ein paar IPs erlaubt.


Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
deny from all
Allow from FD4E:F2D7:88D2:FFFF:...:A
Allow from FD4E:F2D7:88D2:FFFF:...:5
Allow from FD4E:F2D7:88D2:FFFF:...:4
Allow from FD4E:F2D7:88D2:FFFF:...:2

Nun mussten wir noch die Knoten dazu bringen, sich auch wirklich zu updaten. Die Knoten mit aktiviertem Autoupdater versuchen explizit jede Nacht zwischen 4 und 5 Uhr nach Updates zu suchen. Da wir da aber eigentlich gerne schlafen haben wir versucht, das ganze etwas zu beschleunigen. Tatsächlich kam Madonius auf die Idee, die Knotenzeit via NTP zu manipulieren. Dafür haben wir die Zeit auf GW1 geändert und alle Upstream NTP-Server deaktiviert. Das hat dann dazu geführt, dass bald alle Knoten die neue Zeit hatten. Die /etc/ntp.conf sieht dann also temporär so aus:

server 0.debian.pool.ntp.org iburst
#server 1.debian.pool.ntp.org iburst
#server 2.debian.pool.ntp.org iburst
#server 3.debian.pool.ntp.org iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 10

Dann noch via sudo date -s "2015-10-25 03:50:00 CET" die Uhrzeit auf dem Gateway setzen und den Knoten ca 80 Minuten Zeit lassen sich zu updaten. Dann Uhr zurücksetzen und falls alle Knoten durch sind (pingen oder meshviewer beobachten) die Sperrregeln im Webserver ändern.

Wiederholen bis das Skript keine Mesh-only Knoten mehr ausgibt. Dann alle Sperrregeln entfernen und die breite Masse sich updaten lassen.

Wir befinden uns jetzt in der zweiten Update-Welle. Marvin hat erfolgreich so lange am Meshviewer rumgebastelt, bis er wieder alle Funktionen hatte 🙂 Für das neue Netz ist er jetzt hier zu finden: http://94.242.195.73/meshviewer/. DNS-Name und SSL-Zertifikate für den neuen Server kommen noch. Sieht im Moment noch etwas mager aus, aber kommt noch 🙂

New Meshviewer

Die Nacht wird sicherlich noch etwas dauern, aber wir haben ja Dank Zeitumstellung ein bisschen mehr Zeit um Schlaf nachzuholen. Also sobald hier alles geregelt ist mit dem Update…

Für Details schreibt uns einfach auf Twitter @Tobi042 an 🙂

Marvin, Madonius und TobiT

One thought on “Technische Informationen zum Freifunk Netzupdate

  1. Pingback: Wichtige technische Änderungen | Freifunk Saar

Comments are closed.