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 
* 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.
Kategorie:Protokoll