*Wer schreibt hier?
*Tobias
*Frieder
*Sebastian

*Start Normalbetrieb Gluon-Netz MWU

*Gateway-seitig
*(f) Freifunkbasisinstallation auf den Gateways (min. 2, aber alle aktiven) fertig (Kai, Tobias)
*(f) das Gate Spinat (VM bei Marc) auf Manitu-Server vom Verein umziehen (Tobias)
*(f) Routing ist geprüft und haftungssicher (Tobias)
*(f) exitVPNs stehen (Tobias)
*Wir haben aktuell zwei VPN Accounts:
*Mullvad auf Hinterschinken und Lotuswurzel
*hide.me auf Spinat
*Für mich reicht das aus, aber ich kann mich entsinnen dass es auch Stimmen für dedizierte Accounts pro Gate gab
*Vorschlag waere auf allen Gates beide accounts einzutragen und dann multiple wan mit loadbalancing zu fahren
*(f) test cases vom Admin-Team ausgeführt und erfolgreich
*Beim Admintreffen am 5.2. erledigt
*Ich habe während der Beta Phase beobachtet, dass die wichtigsten Dinge funktionieren:
*Autoupdater +1
*fastd key sync +1
*exitVPN Testscript -> DHCP Server wurde gestoppt und gw_mode auf 'off' gesetzt und umgekehrt
*Zumindest ein sukzessives Rebooten der Gates hat zu keinen Problemen geführt.
*Auch einen erster Ausfall (Hinterschinken) hat keiner wirklich bemerkt
*Grundlegende Redundanzen funktionieren+1
*(f) auf aktuelle batman_adv version upgedatet, also compat 15 (Tobias)
*(f) ffctl wird eingesetzt, um uns viel Arbeit abzunehmen (Tobias) (ffctl ist kaputt, aber wurde ersetzt :)
*(f) fastd peers werden automagisch zyklisch gesynced (Tobias)
*(f) Logs vernichten - dhcp, fastd, usw - apache_mod_remove_ip, einfach alles ;) (Tobias)

*Testcases:
https://github.com/freifunk-mwu/technik-meta/wiki/Test-Cases

*Node-seitig
*(f) image-Bauen und -Verteilung funktionieren provisorisch (Tobias)
*(f) autoupdate funktioniert (Tobias)
*(f) es ist min. vorläufig geklärt, wie Node-Besitzer erreicht werden können (Tobias)
*"Contact" aus Alfred Daten
*Wenn VPN, dann sogar noch keys@freifunk-...de - Mails

*organisatorisch
*(f) Signieren der Images ist geregelt
*Hier haben wir noch Klärungsbedarf
*Wir brauchen noch ein script, dass checkt wer das Manifest signiert hat.
*Regulär wird auf einem Admin-Treffen entschieden.
*Bei Zeitkritischen releases fast-track, dh. telefonisch/im/etc.
*(f) Gateway Dokumentation muss stehen (Tobias)
*http://gluon-gateway-doku.readthedocs.org/de/latest/
*(f) Nutzerdokumentation zum Flashen muss stehen (Tobias)
*Im Wiki und neuerdings auch auf Mainzer Webseite: http://freifunk-mainz.de/GluonFlash.html
*(f) Disclaimer bzw. Erklärung, dass bei Autoupdates etwas schief gehen könnte auf Download Seite der Images + evtl. autoupdater sektion im config-mode
*(f) Ausdrückliche Bitte bei der Node Einrichtung eine Kontakt E-Mail Adresse anzugeben mit in den condig-mode übernehmen

*zur Nutzung der Liste:
Vor jedem Kriterium steht entweder (o) für 'noch offen' oder (f) für 'fertig'. Wenn mindesten zwei von uns mit ihrem Namen hinter dem Kriterium bestätigen, dass es fertig ist, darf der Buchstaben vorne auf '(f)' wecheln.


*Dinge, die zu tun sind beim Schwenk vom Legacy-Netz auf neues Gluon-Netz:

*DNS
*Karten
*alte Karte nach altemap.freifunk-mainz.de legen (Vorschlag, DNS Name ist mir egal) (Alte Karte soll weg, das pusht doch nur weiterhin das alte Netz?!)
*Gluon
*map.freifunk-mainz.de => neue Mainzer Map
*map.freifunk-wiesbaden.de => neue Wiesbadener Map
*map.freifunk-mwu.de => passt schon
*??? Sonst noch was ???
*Freifunk API
*Für Wiesbaden und Mainz auf neues Netz anpassen
*changeffapi anpassen sodass das API-File zyklisch mit der aktuellen Knoten Anzahl angepasst wird
*Twitter Bots anpassen
*Nodegame ??? Wer möchte das mal für Gluon aufsetzen, vorausgesetzt das wollen wir haben?
*Announcements
*Blog
*Mailing Liste
*Homepage
*Kirchenblättchen
*Apotheken Umschau
*Alverde Magazin
*Junge Freiheit
*Neue Züricher Zeitung!!1!
*etc.
*Knotenbetreiber des Legacy-Netzes informieren
*altes Netz wird am XX.XX.2015 abgeschaltet (Ich halte 3-4 Monate nach Start Normalbetrieb für lange genug)
















*Ab hier altes Zeugs
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

beta-Phase kann starten, wenn die folgenden Punkte erfüllt sind:
(Nutzung der Liste(n): s.u.)

*Gateway-seitig
*(o) Freifunkbasisinstallation auf den Gateways (min. 2, aber alle aktiven) fertig (Kai)
*(o) das Gate Spinat (VM bei Marc) auf Manitu-Server vom Verein umziehen
*(o) Routing ist geprüft und haftungssicher
*(o) exitVPNs stehen
*(o) test cases (s.u.) vom Admin-Team ausgeführt und erfolgreich
*(o) auf aktuelle batman_adv version, die in barrier breaker zum Einsatz kommt, upgedatet, also 2014.3.0 (Tobias)

*Node-seitig
*(o) image-Bauen und -Verteilung funktionieren provisorisch
*(o) Altes Gluonnetz umziehen
*(o) autoupdate funktioniert
*(o) SSID ist vorlaufig auf "<URL> Testnetz" geändern
*für das testnet weiter behalten um nodes (stable und testing) nebeneinander betreiben zu können (für testnetz vormerken)
*(o) es ist min. vorläufig geklärt, wie Node-Besitzer erreicht werden können- wir können nie alle erreichen und wollen das eventuell auch gar nicht es sollte möglich sein annonym an Freifunk teilzunhemen. Wer auch immer die pinke Meinung vertritt: das schießt sich nicht aus. Wenn jmd anonym am FF teilnehmen will mit einem Node, dann kann er/sie sich irgendwo ne eMail-Adr. klicken und gut. Wir WOLLEN aber möglichst ALLE erreichen können, um eben so wenig Heterogenität im Netz zu haben, dem aktiv entgegenwirken zu KÖNNEN. Weitere Diskuss. gerne in Mail oder per Mund. [jan]

*organisatorisch
*(o) Signieren der Images ist geregelt

*zur Nutzung der Liste:
Vor jedem Kriterium steht entweder (o) für 'noch offen' oder (f) für 'fertig'. Wenn mindesten zwei von uns mit ihrem Namen hinter dem Kriterium bestätigen, dass es fertig ist, darf der Buchstaben vorne auf '(f)' wecheln.
Bei haftungstechnisch besonders kritischen Fragen sollten die Gate-Betreiber bestätigen - auch wenn das dann mehr als 2 sind!

----------------------------------------------------------------------------------------------------------------------------

*Regelbetrieb ...

*Gateway-seitig
*(o) ffctl wird eingesetzt, um uns viel Arbeit abzunehmen
*(o) fastd peers werden automagisch zyklisch gesynced
*(o) Logs vernichten - dhcp, fastd, usw - apache_mod_remove_ip, einfach alles ;)
*organisatorisch
*(o) Gateway Dokumentation muss stehen, siehe: https://pad.freifunk-mainz.de/p/gluon_gateway_doku
*(o) Ins GIT übertragen
*(o) Nutzerdokumentation zum Flashen muss stehen
*(o) Disclaimer bzw. Erklärung, dass bei Autoupdates etwas schief gehen könnte auf Download Seite der Images + evtl. autoupdater sektion im config-mode
*(o) Ausdrückliche Bitte bei der Node Einrichtung eine Kontakt E-Mail Adresse anzugeben mit in den condig-mode übernehmen

----------------------------------------------------------------------------------------------------------------------------
*Detailbeschreibung zu Punkten in den Listen (wenn nötig):

*Freifunkbasisinstallation:
*alle benötigte SW installiert und konfiguriert (fastd, batman, etc.)
*Gates unterenander vermascht
*Routing ist geprüft und haftungssicher
*/etc/network/interfaces korrekt
*Routing innerhalb einer Community zwischen allen Gates OK
*Routing zwischen beiden Communities und allen Gates OK
*Default-Route wird durch openvpn-up script korrekt in beide rt's gesetzt
*Grundsätze für unser Routing: https://github.com/freifunk-mwu/technik-meta/wiki/Gateway-Routing

----------------------------------------------------------------------------------------------------------------------------
*Aber hier wilde historische Notizen:

Heute (nach wie vor):
*wir haben ein Altsystem, das noch halbrund läuft und
*wir haben neues Gluon-System, das schon halbwegs läuft.
*an jedem dieser Backends hängt ein Satz von Knoten, von denen wir die Eigentümer kennen oder auch nicht.
Gateways routen Traffic korrekt untereinander.

Erste Testreihe:
Eine Node, 2 Gateways - Was passiert wenn..
*... am ersten Gate das VPN ausfällt, was am Node?
*... am ersten Gate der DHCP Server ausfällt?
*wir benötigen ein script, dass prüft ob der DHCP noch da ist und wenn nicht, muss für das Gate das gw-flag im batman_adv entzogen werden
*... am ersten Gate der RADVD Server ausfällt?
*kein Problem, andere Gates schicken noch RAs (mit default route, iwann) sowie nodes auch (ohne default route)
*... am ersten Gate der DNS Server ausfällt? Was, wenn der Master-Server wegfällt.
*Wenn an einem Gate nur der DNS wegfliegt ist das kein Problem, über DHCP verteilen wir ja mehrere
*Wenn der Master DNS wegfliegt hat das für den Betrieb zunächst keine Konsequenzen, die Slaves laufen mit dem letzten Stand der Zone weiter
Super Punkt: Testfälle schreiben.

ExitVPN Testscript Schreiben, auf korrekte Funktion testen




Nutzerdoku schreiben (== Anfang von der alten Doku)



GLUON Autobuild & Distribute funktioniert
GLUON Autoupdate funktioniert
*Die Frage, wie Nodes zu neuer FW kommen, ist geklärt und entschieden. Es gibt Ergebnisse in Form von Doku (Entscheidungsfindung und -nachvollzug) und ggf. eine EULA (siehe hierzu das Trello-Kärtchen!)
*Der Ort der Platzierung der EULA ist auch noch zu klären
*Idee: vor dem ersten Flashen des Routers
*Idee2: beim Aushändigen des vorbereiteten
*Idee3: Jeder Nodebetreiber füllt eine Art Datenblatt über sich oder für jeden Node aus (wollen wir eigentlich nicht, da Papierkram(-) sowie Vorhalten von persönlichen Bestandsdaten(-) )
*Idee4: Jeder Nodebetreiber muss sich an einem System anmelden, dass Zuordnung der Nodes mit zumindest E-Mail Adresse speichert (eigentlich für die Zukunft unumgänglich)

Warranty Void-Einverständniserklärung einholen beim Nutzer/Besitzer des Node

Karte aufsetzen, FreifunkAPI und so anpassen (nicht wichtig)

Zweite Testreihe:
Wiederholung der ersten, an bis dahin allen Gateways


Alle Stellen, die loggen (zB fastd) , werden bereinigt, ihnen wird das Loggen abgewöhnt, sie werden anonymisiert. Der Server/das gate hält damit unser gegebenes Versprechen auf Datenschutz und Anonymität.


Freifunk 1.0 ist fertig
*es läuft gut und die Nutzer sind zufrieden
*Funktionierendes Gluon-Backend-Netz
*Das Netz ist redundant an den kritischen Stellen: Gates, DHCP, VPN. Failover klappen zu 9x %
*Das Backend ist dokumentiert (neue Admins/neue Maschinen können schnell eingerichtet werden)
*Router kommen problemlos hinzu, auch durch Noobs
*sie wissen, welche Modelle geeignet sind und wie sie die kriegen (Welchen Router kaufe ich)
*sie wissen, wie sie den Router ins FF-Netz bringen (Nutzerdoku)
*der Prozeß dafür ist dokumentiert und klappt IMMER
*Die Knoten sind fähig, eine neue Firmware zu laden und einzuspielen.
*Vor dem ersten Flashen wird vom Nutzer die Eula zur Kenntnis genommen.
*Wir erreichen wir die Node-Besitzer (auch noch in 3 Jahren)?
*Release Management:
*Geklärt ist wer unter welcher Vorraussetzung Updates zur Verfügung stellt (signiert) und wo diese lagern.
*Genauso ist klar, WIE ein Release von der Testumgebung in die Produktionsumgebung kommt.
*Rückbau der alten FF-Knoten ist im Gange, alte Router werden in neue umgewandelt (gluon) und an den Eigentümern von Altsystemen, die schlecht erreichbar sind, sind wir dran.
*Automatischer Probe, ob VPN da ist und nicht das Ende vom Geld wieder verpaßt wurde. Der Aufpasser mailt Status in den maschinenraum@ Der automatische Geldnachwerfer auch
*Das Freifunk-TKG-Starterkit ist auf unsere Bedürfnisse angepasst und alle Freifunker sind darüber informiert, wie damit umgegangen werden muss.
*Da, wo schon Freifunkknoten im Einsatz sind, ist die Meldung an die Bundesnetzagentur nachgeholt worden.


Meilenstein Freifunk 1.1 ist erreicht und umfaßt folgende Features:
*die implementierten Sachen von der v1.0 sind im Wiki dokumentiert
*Übersicht senkt Mitmachbarrieren! Alter Kram aus 2013er Zeiten verwirrt Neulinge und alte Hasen gleichermaßen nicht mehr, denn er ist aus der Doku rausgeflogen.
*neue Sachen, gluon-spezifisch und anderes, sind drin. Was an Doku drin ist, trifft auch zu 100 % zu, ist keine Spekulation oder "man müßte mal-Zeugs"
*wir haben eine Lösung für das Batman-adv-Skalierungsproblem (200 Nodes) gefunden und implementiert
*Erst hier so Kram wie Images per Torrent verteilen
*Erst hier so Kram wie interne Services
*Alfred läuft getrennt für beide Communities
*Freifunk Karte (eine für beide Communities)
*IC-VPN
*IPv6, wie wer warum und überhaupt
*Überwachung der Gates / Wie / Wann / überhaupt ?


Freifunk 2.0 hat folgendes Zeug drin:
*wie haben einen Directory Server (openLDAP?) am Start für SingleSignOn für uns als Admins und ggfs. Nutzer für Wiki + netmon