Wartungsarbeiten 16.02.2017 ab 22 Uhr //Update 17.02: FERTiG!

//Update 17.02: 
Die Wartungsarbeiten waren heute morgen gegen 04:00 abgeschlossen!
Ein schönes Wochenende!

Wichtige Information!

Ab dem 16.02.2017 22 Uhr bis zum nächsten Morgen wird das Defaultnetz
teilweise, bis gar nicht erreichbar sein.

Unser dedicated Server, auf dem u.a auch die VM’s für das Defaultnetz
untergebracht sind, wird in ein anderes Rechenzentrum umgezogen.
Wir werden ab 21.45 Uhr die Server runterfahren, um einen Crash zu
verhindern.

Es kann in der Zeitspanne zu Störungen im Netz kommen. Wir werden das
Defaultnetz in der Zeit auf eine Sandbox legen, damit die Router
trotzdem online bleiben.

Freifunk Infoabend in Rastede

Freifunk verbindet! Genau dies wollen Freifunker aus Rastede in einer Informationsveranstaltung für jedermann näherbringen. Nachdem der Ausbau des Freifunknetzes im vergangenem Jahr schon sehr weit fortgeschritten ist, wollen die Beteiligten mit der Unterstützung des Freifunk Nordwest e.V. und der Gemeinde Rastede weitere Enthusiasten für den zukünftigen Ausbau finden. (mehr …)

Neue Firmware 1.2.2

Gestern war zwar nicht Freitag der 13., aber der Tag des Fehlerteufels in unserer Firmware.
Irrtümlicherweise war das 1.2.1-Release auf Testing konfiguriert.

Basisdaten:
 * Firmware-Version: 1.2.2
 * Gluon-Version: v2016.1.x
 * Commit ID: 8c9504bccb1899325f1dfb2a5a292074a6f9173c
 * Download: https://firmware.ffnw.de/1.2.2/

Folgende Comunnity spezifischen Änderungen gab es:
siteconf:
Konfiguration von SSID etc. auf Produktivbetrieb

Neue Firmware 1.2.1

In den nächsten Stunden wird im Freifunk Nordwest Netz eine neue Firmware ausgerollt. Leider hat die Version 1.2 einen Fehler enthalten, sodass Router mehrere öffentliche IPv6 Adressen er- und behalten haben.

Basisdaten:
 * Firmware-Version: 1.2.1
 * Gluon-Version: v2016.1.x
 * Commit ID: ee597c66769a455d38467192598813e7f8411cfd
 * Download: https://firmware.ffnw.de/1.2.1/

Folgende Comunnity spezifischen Änderungen gab es:
package repo:
* Kritischer Fehler im multiple-v6-watchdog:
  Dieser schaute nur nach GLEICHEN v6 Adressen,
  nicht nach unterschiedlichen aus den Hoods. 
  Dieser Fehler wurde behoben.

Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/v1.2...v1.2.1

Die Änderungen an unseren eigenen Paketen können im Packages-Repository
hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/v1.2...v1.2.1

Neue Firmware 1.2

In den nächsten Stunden wird im Freifunk Nordwest Netz die neue Firmware 1.2 ausgerollt. Alle Router, die den Autoupdater auf den Branche „stable“ aktiviert haben, erhalten dies automatischt.

 * Firmware-Version: 1.2
 * Gluon-Version: v2016.1.x
 * Commit ID: ee597c66769a455d38467192598813e7f8411cfd
 * Download: https://firmware.ffnw.de/1.2

Die upstream Änderungen findet ihr hier:

https://github.com/freifunk-gluon/gluon/compare/ee597c...ee597c

Folgende Comunnity spezifischen Änderungen gab es:
package repo:
* logic Fehler im configmode wurden behoben
    Das Dropdown menu hat, bei wiederholten ausführen des
    configModes seinen zustand nicht wiederhergestellt.
    Das setzen zweier uci Parameter ist durch einen Typen Fehler
    nie zu Stande gekommen.

* Client seitige Javascript map im configeMode
    Es wird nun vom Router aus via Javascript auf den Client eine
    OSM Karte geladen, sofern der Client über eine Internet
    Verbindung verfügt. Um das selektieren von statischen Geo
    Koordinaten zu vereinfachen.

* hoodselector: hoodinfo Sektion in respondd wurde erstellt #63 #48
    Über respondd werden nun Informationen über die aktuell
    selektierte hood eines Routers verteilt.

* hoodselector: das MOLWM Protokoll wurde implementiert Mesh On Lan
/ Wan Managemend
    Das MOLWM Protokoll detektiert hood Kollisionen im mesh on lan
    oder mesh on wan. U.a. anhand von Vergleichungen von md5 hashes
    der einzelnen hoods.

* hoodselector: Der hoodselector gibt nun returncodes bei der
Terminierung zurück.

* hoodselector: pid datei write Permission wird abgefangen

* hoodselector: Unbenutzte variablen wurden entfernt und das überlappen
von Globalen variablen wurde behoben (zum Einsatz kam luacheck)

* hoodselector: Es können nun mehrere fastd peers mit äquivalenten DNS
aber unterschiedlichen Port bestehen. #40
    Das ermöglicht uns anstelle von folgenden zu schreiben:
      starwars0.sn.ffnw.de 1001
      starwars1.sn.ffnw.de 1010
      starwars1.sn.ffnw.de 1011

    Lediglich:
      starwars.sn.ffnw.de 1001
      starwars.sn.ffnw.de 1010
      starwars.sn.ffnw.de 1011

    Das reduziert somit die ganzen DNS Einträge.

* hoodselector: Im scanmode arbeitet der hoodselector nun nicht mehr mit
einen statisch festgelegten WLAN Interface, sondern scannt über alle WLAN
Interfaces die ein Gerät hat. #69

* hoodselector: Im scanmode wird nicht mehr statisch 30 sec abgewartet
um anschließend zu prüfen ob eine mesh Verbindung besteht. Es wird nun
kontinuierlich geschaut und spätesten nach einem Zeitablauf von 30 sec
fortgesetzt. #70

* hoodselector: Fehlermeldungen werden nun in ein logfile geschrieben und
können und über logread eingesehen werden. #36

Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/v1.1.1...v1.2

Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/v1.1.1...v1.2

Bericht aus dem Maschinenraum (Teil 2): Umzug von Hoods

Bereits seit mehreren Wochen planen wir den Umzug von 2 Hoods: Die Friesland / Wilhelmshaven Hood soll auf einen leistungsstärkeren Server umgezogen werden. Zusätzlich soll unser altes Defaultnetz auch auf unsere neue Infrastruktur eingerichtet werden. Diese beiden Milestones haben uns in den letzten Wochen einiges an Arbeit bereitet:

Wie plant man so einen Umzug sinnvoll und auf welche Punkte im Hintergrund muss dabei geachtet werden? Fangen wir mal ganz von vorne an.

Womit werden die Hoods eigentlich eingerichtet?

Unser aktuelles Hood-Setup läuft auf Basis von Puppet. Puppet ist ein Systemkonfigurationswerkzeug. Hauptanwendungsfall ist die automatisierte Konfiguration mehrerer Computer via Netzwerk. Konfigurationsparameter können etwa die Installation von Software, Datensynchronisation oder das Ausführen von Programmen sein.

Puppet ist Open Source und prinzipiell plattformübergreifend-unterstützt werden jedoch insbesondere unixoide Betriebssysteme wie Unix, Linux und FreeBSD. Jeder einzelner unserer Server ist über eine Konfigurationsdatei eingerichtet worden – in der alle Details für die automatische Installation eingetragen werden.

In der oben angegebenen Konfiguration werden mehrere Teile der Hood definiert. Wir unterscheiden bei unseren IPv6 Netzen zwischen 2 Typen:

  • 2a03:2260:1001:9000::/64 ist ein Netz, aus dem die Router und Clients Ihre IP Adressen beziehen
  • 2a03:2260:1001:0104::/64 ist ein internes Netz, das ausschließlich für unser dynamisches OSPF Routing (sprich das Routing zwischen unseren Hoods) genutzt wird.

Standardmäßig werden alle Konfigurationseinstellungen für den Server im Bereich network::inet gesetzt, damit der Server normal an das Internet angebunden ist.

Wie läuft so ein Umzug genau ab?

Für den Umzug unserer Hoods haben wir uns einen extra Milestone in unserem Gitlab erstellt, in dem entsprechende Issues nach deren Prioritäten abgearbeitet werden müssen. Dabei entsteht der große Vorteil, dass keine wichtigen Arbeiten (die in Vergessenheit geraten könnten) übersehen werden. Die einzelnen Issues können einem Administrator oder Entwickler hier direkt zugeordnet werden. Wenn hier alle Issues geschlossen und umgesetzt wurden, können die entsprechenden Hoods umgezogen werden. Zum Teil ist hier die Mitarbeit aus unterschiedlichen Teams notwendig.

Bereits vor einigen Monaten haben wir eine Hood (Kreis Steinfurt, wir haben hier bereits drüber berichtet) umgezogen. Aus den hier gemachten Fehlern haben wir gelernt und auch vernünftige Workflows für solche Umzüge gestrickt.

Der eigentliche Umzug der Hoods besteht darin, dass die Router (die immer noch mit dem alten System ihren VPN Tunnel aufrecht erhalten) zu dem neuen Server wechseln. Hierbei wird im ersten Schritt die TTL der DNS Einträge auf einen kleinen Wert gesetzt. Die TTL ist dafür zuständig, dass der Client sich den DNS Eintrag für eine bestimmte Zeit merkt. Wir benötigen hier eine relativ kleine Zeit, damit die Router nach Abschalten der alten Einträge eine neue Anfrage starten. Wir können hier unter anderem genau beobachten, wieviele Router sich schon auf den neuen Server verbunden haben.

Nachdem die DNS Einträge geändert wurden, müssen wir die VPN Verbindung bewusst von unserer Seite trennen, sodass der alte Server keine Tunnel mehr annimmt und alle Router eine neue Verbindung zu der neuen Hood aufbauen. Hierfür stoppen wir den kompletten fastD Dienst auf den alten Servern und warten gespannt einige Minuten.
Wenn alle Router den neuen Server gefunden haben, kann das alte System komplett abgeschaltet werden: Wir machen es uns hier aber auch nicht so einfach, denn den alten Server nutzen wir weiterhin als Exit – der Exit leitet den Traffic, der im Freifunk Nordwest Netz entsteht weiterhin zum Freifunk Rheinland.

Eins ist klar: Routine wird bei unserem Netz nie eintreten, es warten immer spannende und neue Baustellen…

Bevor wir es noch vergessen: Die Umzüge haben reibungslos geklappt und sollen ein kleines Weihnachtsgeschenk für alle Nutzer sein 🙂