Benutzer:Lars/Blog:2015 March 06 03:21:40 CET

Inhaltsverzeichnis

Philipp hat den Opennet-Server in der Frieda in Betrieb genommen
die Abschaltung des Hardware-RAID war gar nicht so leicht
Debian Jessie läuft, Anbindung an den Frieda-Hausanschluss und unsere Mesh-Wolke ist gegeben

ondataservice auf dem Webserver/mediawiki lief nicht, da die Datenbank (/tmp/database) zwischenzeitlich kaputtging (leere Datei)
Löschen der Datei löste den Deadlock (anschließend wurde vom olsrd-ondataservice-Plugin das "create"-Skript selbständig ausgeführt)
nach einer Weile funktioniert das mediawiki-Plugin (z.B. Firmware_Status) auch wieder

Austausch über ein paar Details und den aktuellen Stand
kleine Korrekturen und Commits
Relevanz der MTU-Tests:
- in der neuen Firmware werden die beiden UGW-Funktionen "Mesh-Verbindung" und "Gateway-Weiterleitung" separat umgesetzt
- es ist unklar, für welche dieser Funktionen der MTU-Test relevant ist
- Martin wird prüfen, ob er MTU-Probleme bei erzwungener Verbindung mit subaru beobachten kann
- daraufhin können wir die Logik der UGW-Funktionen anpassen, auf dass die MTU-Tests sich nur auf die betroffenen Funktionen auswirken

für den bevorstehenden CA-Wechsel müssen wir erkennen, welche APs lediglich alte und keine neuen CA-Zertifikate enthalten
am Zertifikat des Clients lässt sich dies nicht erkennen
daher wollen wir die von jedem AP akzeptierten Zertifikate anhand der von ihm erfolgreich aufgebauten Verbindung mit einem OpenVPN-Server mit einem neuen Zertifikat ermitteln:
- Lars konfiguriert einen Server (z.B. auf ryoko) so, dass er vorgibt, den Gateway-Dienst anzubieten (0er-Adresse, olsr-nameservice-Announcement)
- der Server bricht die VPN-Verbindung in jedem Fall final ab (nach dem tls-Handshake), damit der Client ihn nicht versehentlich für nutzbar hält
- alle Clients, die regelmäßig die verfügbaren Server auf VPN-Tauglichkeit prüfen, können somit von dem Server erfasst werden
- lediglich Clients, die keine automatischen VPN-Tests durchführen, bleiben unklar
- Martin erstellt eine Liste der mit den Gateway-Servern verbundenen Clients - diese können wir mit den Ergebnissen des honeypot-OpenVPN-Servers vergleichen, um die verbliebenen Clients individuell zu prüfen

8. März: Firmware-Release v0.5.1
22. März: Entscheidung über weiteres Vorgehen
- wir entscheiden, ob wir die AP-Aktualisierung auf alle Nutzenden ausweiten oder ob wir die Zertifikate per Hand verteilen wollen
- AP-Aktualisierung wäre natürlich vorzuziehen - das hängt aber von der Qualitätseinschätzung des Release nach zwei Wochen Nutzung ab
5. April: Umstellung ist abgeschlossen
- nun sollten alle APs ein neues Zertifikat haben
12. April: alte CA ist abgelaufen / Zertifikate auf den Servern sind ausgetauscht