Protokolle/20160206

Techniktreffen Sa. 06.02.2016, FabLab Nürnberg

Zeit: ab 11:00 Uhr bis ca. 19:20 Uhr

Wer war da:

• mayosemmel (Jan)
• ChristianD
• Flo
• Green
• Dominik
• Red

Themen:

• L3-Mesh (oder die Hoodgrenze Fürth Nürnberg etwas nach SüdOst verschieben?--> wäre ja nur eine kurzfristige Lösung)
• Einführung von striktem Semantic Versioning (http://semver.org/lang/de/ ) der Firmware und anderer Repositories?
  • Versionierung nach Datum des letzten commits
    • YYYYMMDD-[Anzahl commits]-[Commit-ID]
    • YYYYMMDD-alpha
    • YYYYMMDD-beta
    • YYYYMMDD
  • Release nach Gefühl
• Wollen wir demnächst ne offizielle Beta machen? Das Web-If funktioniert ja mittlerweile ganz gut.
  • Diskussion um die Versionsnummer, 0.6.0 war Vorschlag im IRC
    • d.h. "20160130-beta1"
    • Sollte raus gehen
      • Danach noch BugFixes zum nächsten Stable:
        • http Weiterleitung auf non ::1 IP
        • Geo-Koord übernehmen fix
        • weitere bisher (un)bekannte Bugs
      • Umbau Web-UI (ohne JS) erst ein Release später
• Diskussion Auto-Update
  • Zu gefährlich, entfernt sich zu sehr vom Freifunk Gedanken
  • ggf. auch ein rechtliches Thema vorhanden, da Fremde Geräte manipuliert werden
• Diskussion Gateway Auslastung
  • Klee soll aus der Hood Fürth raus genommen werden
• Web-Interface als eigene nachinstallierbare Komponente/Repository!?
  • Ziel ist es alle Freifunk Franken Komponenten in Packages zu überführen.
  • Web Interface ist bereits ein OpenWRT-Package
    • Möglicherweise sind die Abhängigkeiten anderer Packages defekt, so dass ein Build ohne WebInterface aktuell nicht korrekt geht.
  • Erst mal eins haben, damit man was funktionierendes hat.
  • Ein separates Repo macht erst Sinn, wenn es neben unserer Verwendung noch eine weitere Verwendung findet
    • => Aktuell nicht gegeben.
  • Es soll kein zweites Ding eröffnet werden, nur um einen anderen GIT Workflow zu etablieren.
• Kaputte Gatewayselection ansprechen - Alternativen? Hat sich vermutlich durch ein Patch von Tim erledigt, können nochmal kurz drüber quasseln aber viel ist hier nicht mehr nötig (glaub ich).
  • ChristianDr berichtet, wie gut der Bugfix beim Höffner funktioniert.
• Diskussion über Umgang mit versehentlichen Hood-Verbindungen (Loops), jetzt wo der Netmon die Position nicht mehr vorgibt.
  • Es gibt die Möglichkeit ein VPN Client über den zentralen KeyXchange in eine bestimmte Hood zu lenken
  • Diskusison über absichtliche Angriffe
    • Aktuell keine Möglichkeiten ..
  • Zukünftig (ohne zentralen keyXchange) muss jeder VPN Server Betreiber spezifische Client blacklisten.
    • Dabei ist eine Absprache zwischen allen VPN Server Betreibern (mindestens innerhalb einer Hood) nötig.
• IPv6 Adressen für Router (Hood verteilung?!)
  • Tim erklärt die Idee mit den Hood Dateien
  • Trust-Chain mit Signaturen sind im Gespräch
  • Blockchains haben den Vorteil einen Mehrheitsentscheid herbei zu führen.
  • Übergang zu L3 Richtfunk. ChristianDr erklärt, warum ultra kleine Hoods eine Lösung für L3 Richtfunk sein könnte.
• Mehr als ein Master im Alfred (evtl. für DNS)
  • Dominik erklärt die Funktionsweise von Alfred
  • Es wäre schön, wenn die AlfredProxys die IPs sowie den Namen aus den node.data's extrahieren würde und dann an das DNS weitergeben würden.
    • Der AlfredProxy ist ein Alfred-Master, welche die Daten einsammelt und an das monitoring schickt.
      • Zur Zeit gibt es einen Alfred-Master, der nur auf dem Netmon-Server läuft (der ist in allen Hoods), langfristig soll auf jeden Gateway dieser AlfredProxy laufen.
• Wie aktuell ist https://pad.freifunk.net/p/FrankenSchlachtplan ? Kann man da draus evtl. was öffentliches machen, wo jeder seine Sachen einträgt bzw. abarbeiten kann. (solange noch kein Bugtracker da ist)
  • Das ist größtenteils veraltet. Das ist "Pre-Monitoring" Zeiten.
  • GitHub bietet einen Bug- und Feature-Tracker
• Was ist mit GitLab?
  • Flo erklärt
    • Erstmal nur ein Vorschlag. Selbst noch nicht im großen verwendet.
    • Alles was man braucht, ist da: wiki, CI, Issues, Merge-Request, User-Management, SelfHosting, OpenSource
    • Kritik: Mega kompliziert zum Installieren -> Quatsch: Docker und fertig
  • Vorraussetzungen/Anforderungen:
    • Issue-Tracker
    • Verknüpfung Diskussion <-> Commit
    • Continues Integration
    • Mail-Benachrichtigungen inkl. Antwortmöglichkeit
    • GIT
    • Peer-Review
    • Pull/Merge-Requests
  • GitLab wird getestet
  • Workflow wie bisher, nur das Review wird ggf. ins Issue-Management verlagert
    • Patch/MergeRequest (evtl gelinkt mit Issue)
    • Review
    • Apply/Merge
  • Flo legt heut Nacht ein Test-Gitlab an und schickt Link
    • Darin ein Issue-Tracker für die "GitLab Umstellung"
    • Das GitLab soll zum Testen für die nächsten paar Wochen genutzt werden
• Umgang mit Firmwareentwicklern, mit denen man nicht reden kann --> ? Sind doch eigentlich Alle auf der Liste!?
• Accounts im Monitoring?!
  • schützen von Mail-Adresse -> ggf. Captcha
  • Account wird mit Netmon-Username und Router-Kontakt-E-Mail Adresse angelegt
    • Nur eingeloggte User können die kompletten E-Mail Adressen sehen
    • Somit kennt der Account sowohl Router mit Firmware 0.5.1-0.5.2 als auch 2016...
    • Jeder User kann seine Router löschen
    • Jeder User kann auf seiner User-Seite noch ein paar Daten hinterlegen, z.B. XMPP, Telefon, kurze Beschreibung (darunter gibt es seine Routerliste)
    • Router sollen nach x Monaten ohne Kontakt automatisch gelöscht werden
• Sichern von Einstellungen auf Routern
  • EInstellungen exportierbar/importierbar machen (XML export oder sowas...)
  • Idee: Den "Config-Sicherungs" Mechanismus von OpenWRT, der während eines sysupgrade durchgeführt wird nutzen. Dieser verwendet die Daten aus /etc/sysupgrade.conf . Es sollten auch keine anderen Daten exportiert werden, da wichtige Änderungen einer neuen Firmware dann ggfs wieder überschrieben werden.
• Reverse DNS bei mehreren Einträgen
  • sortierung, nur einen -> welchen behalten?
  • Neue Richtlinie: Maximal ein A-Record pro IP, für weitere Namen den CNAME Eintrag nehmen.
    • Langfristig soll das Script angepasst werden, dass nur noch der erste A Eintrag einer IP genommen werden soll.
• Wie soll es beim Webinterface weiter gehen? (mit JS / aufräumen / komplizierter machen / einfacher / etc .. diskussion)
  • Aktueller Zustand: HTML mit viel AJAX, lädt komplette /etc/config/* Dateien und verarbeitet diese mit JS. Beim Speichern werden wieder neue configs angelegt.
  • Ziele des WebInterfaces:
    • Soll einfach zu bedienen sein
    • Muss wartbar und langfristig pflegbar sein
    • Statusseite (erste Seite ohne Login)
      • Hostname
      • Kontaktdaten
      • Monitoring einblenden
        • Lieber nicht, lädt lange, sieht doof aus bei Offline
      • Lieber schlank halten
    • Ohne Login darf man nicht im Stande sein den Router durch das WebInterface auszulasten
  • Mögliche Lösung:
    • Statische CGI's per Post-Request
  • Idee für die Zukunft:
    • Knopf für ein Update
      • (dieser könnte den gluon autoupdater verwenden um die Version und die Signaturen zu prüfen)
• Diskussion, wie man beim Update rausfinden kann, ob eine Version neuer ist.
  • Ziel wäre es das sysupgrade.sh Script so umzubauen, dass es erstmal die Version prüft.
    • Soll nicht gemacht werden, weil es reicht eine Datei downzuloaden, welche die current Version enthält. Langfristig könnte diese Aufgabe durch den gluon autoupdater (wird nicht als autoupdate verwendet) erfolgen.