Protokolle/20160206: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
KKeine Bearbeitungszusammenfassung
K (Mayosemmel verschob die Seite 20160206 nach Protokolle/20160206: Protokolle vergessen....)
 
(kein Unterschied)

Aktuelle Version vom 6. Februar 2016, 21:52 Uhr

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
  • Holger?

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.