CommunityDay2019

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen

Draft!

Details

Wann?

In 2019? https://dudle.inf.tu-dresden.de/FFKBUCommunityDay2019/

Wo?

C4?

Programm

Status 100x Wlan

Landesföderprogramme

KBU Backbone Arbeit

Adminbootcamp

Wireguard in der Hood Bonn v2

FFRL Werbeblock

??????????

Mesh ./. Ad-Hoc (802.11s ./. IBSS)

  • Was sind die genauen Gründe, für den Wechsel auf 802.11s in Bonn v2?
  • Welche Hinweis geben wir Freifunkern, deren Hardware kein 802.11s kann? (z.B. RaPis)
  • Warum zieht Bonn auf 802.11s um - Köln und Umland jedoch nicht? Gibt es Argumente dafür?

yanosz denkt, es wäre gut, wenn wir:

  • den gleichen Modus überall verwenden (also 802.11s default überall)
  • den Modus konfigurierbar halten (soweit möglich)
  • auf der Karte anzeigen, welcher Modus verwendet wird, damit pico-Peering möglich ist.

Dokumentation Auto-Updater

Remote-Access

Diskussionspunkte:

  • Wie soll die/der Benutzer/in Updates zustimmen (Radio-Button / Feld im Config-Mode? / Hinweis)?
  • ToDos für die Key-Inhaber
    • Nachvollziehbare Dokumentation der Ownership (PGP / Web-Of-Trust?)
    • Soll die Zustimmung der Nutzer dokumentiert werden? Falls ja, wie?
  • Wie werden ausgerollte Updates dokumentiert?
    • Wiki-Seite mit changelog
    • E-Mail über spezielle Liste?
    • Kontrolle / Auditing in der Community?
  • Haftung für Freizeit-Admins bei Fehlern?
  • Wie können Benutzer einzelene Updates zurückhalten?
  • Freifunker haben aktuell noch ohne Zustimmung und ggf. Kenntnis des Aufsteller/innen Zugriff auf private Netze & Daten. Bis 01/2018 wurden Aufsteller(innen) über die Zugriffsmöglichkeit in die Irre geführt.
    • Praktisch eine Hintertür
    • Was machen wir mit dem Schlamassel?
    • Re-keying, löschen aktueller Keys: Ernsthafte Zusicherung, dass geschaffene Zugänge gelöscht wurden, sofern Aufsteller/innen nicht explizit zugestimmt haben.

Es-gibt-keine-Updates - Auto-Updater ja/nein Entscheidung.

Die Dokumenation suggiert z.T., dass es einen Auto-Updater bzw. automatische Updates gibt. Benutzer/innen gehen z.T. gutgläubig davon aus. Die / der Benutzer/in kann sich für oder gegen automatische Updates entscheiden.

Diskussionspunkte:

  • Welche Dokumentation macht Stand jetzt Sinn? Wie soll die aktuelle Firmware beschrieben werden? Evtl. klarer herausstellen: Es geht nicht um automatische Updates, sondern um Zugriffsrechte auf private Devices.
  • Auto-Updater ist keine ja / nein - dafür / dagegen Frage. Es wird immer Leute geben, die "Ihre"-Firmware bauen. Das ist der Sinn des Projekts! Wie soll dies aus der Dokumentation hervorgehen?
  • Passt es zum Projekt, Nutzern zu empfehlen (bzw. vor die Wahl zu stellen) uns Zugang zu Ihrem Netz zu geben, ohne dass tatsächlich Updates gibt? Warum sollte das jmd. tun wollen, d.h. welche Argumente sprechen dafür?
  • Die Doku sollte weder den Eindruck erwecken, dass es üblich ist, dass Freifunker Zugriff auf fremde Devices nehmen noch sollte der Download eine implizite Zustimmung ausdrücken (d.h. aktuelles Opt-Out verfahren).

Ideen / Arbeitspunkte / Anregungen

  1. Wir branchen jetzt eine neue Firmware für neue Devices. Was tun?
  2. Auto-Update klar als Projekt einzelner Freifunker herausstellen: Es gibt auch Leute, die auch eine Firmware bauen, wo ihre Keys hinterlegt, damit sie ggf. Updates einspielen können. Wer macht genau was?
  3. Netzstabilität ohne Auto-Updater (Notfall-Plan für fastd-Port Rotation)?
  4. Das Scharf-Schalten (d.h. verlinken als Download in der Installationsanleitung) sollte der letzte Schritt sein - d.h. die Doku-Todos müssen erledigt sein, bevor entsprechende Software zum Download angeboten wird.
  5. Vorschlag zur Auto-Updater Umsetzung
    1. 2 Branches: Mit / ohne Auto-Updater (2018.x) asap für alle Hoods
    2. Zunächst nur Firmware ohne Auto-Updater in der Anleitung verlinken
    3. Wenn die Doku fertig ist und es regelmäßige Updates gibt: Hinweise in Installationsanleitung aufnehmen.