1. Nächstes Treffen: 26.10. (Uhrzeit und Ort haben wir noch nicht festgelegt)
2. ...

1. Debian 11 Upgrade @julian
   1. Kumpir @prisma
2. Upgrade Debian 9 Hosts
   1. EOL: 1.7.2022
   2. kichererbse (DNS Master intern) @kokel
   3. sushi (Hetzner KVM-Host) @prisma
3. PowerDNS Upgrade
   1. kicherbse: 4.1 (EOL) @kokel
   2. reis: 4.2 (EOL) @kokel
4. Kea Upgrade
   1. Kea 1.8 ab 1.7.2022 EOL @julian
5. systemd-networkd @julian
   1. https://github.com/freifunk-mwu/ansible-ffmwu/pull/47
   2. Benötigt systemd >= 248
      1. systemd 250 in Debian 11 bpo verfügbar
6. Knoten-VPN
   1. Wireguard+VXLAN
      1. https://github.com/freifunk-gluon/gluon/pull/2168
      2. ifupdown2 < 3.0.0 ohne VXLAN IPv6 support
      3. pro
         1. Verschlüsselung
         2. kein Contextwechsel (Kernel/User-Space)
      4. contra
         1. MTU-Overhead durch zusätzlichen Layer
      5. Wir wollen Wireguard verwenden, weil verschlüsselt.
      6. Nachdem wir die Updates auf Debian 11 gemacht haben können wir das testen.
   2. fastd+L2TPv3
      1. https://fastd.readthedocs.io/en/stable/releases/v22.html#new-features
      2. https://github.com/freifunk-gluon/gluon/pull/2186
      3. fastd v22 in Debian 11 bpo und Debian 10 bpo-sloppy verfügbar
      4. pro
         1. kein Contextwechsel (Kernel/User-Space)
         2. minimale Config-Anpassungen mit multitap Mode
      5. contra
         1. keine Verschlüsselung
      6. Wir wollen L2TPv3 nicht verwenden, weil nicht verschlüsselt.
7. Backups
   1. kumpir (web): MariaDB, MediaWiki (Uploads), Wordpress(?)
   2. gurke (map): Yanic, InfluxDB, Grafana Dashboards
   3. morchel (mail): Mails, MariaDB
   4. reis/kichererbse (dns): MariaDB
   5. griesbrei: Firmware (Archiv)
   6. Unifi (datenbackup sichern)
   7. UNMS (datenbackup sichern)
   8. Jverein (@prisma)
   9. Wir versuchen uns mal an restic (@ralf)
8. BIRD
   1. statische Routen via BIRD verwalten (nicht mehr so relevant wenn auf systemd-networkd umgestellt)
   2. BIRD2
   3. ROA Logmeldungen (@julian)
9. backend-scripts in ansible-ffmwu integrieren
10. offetune Github Issues / Pull Requests
    1. ansible-ffmwu
       1. https://github.com/freifunk-mwu/ansible-ffmwu/pull/32 @prisma guckt sich das an beim update von sushi
       2. https://github.com/freifunk-mwu/ansible-ffmwu/pull/48
       3. https://github.com/freifunk-mwu/ansible-ffmwu/pull/49
       4. https://github.com/freifunk-mwu/ansible-ffmwu/issues/38
       5. https://github.com/freifunk-mwu/ansible-ffmwu/issues/33
       6. https://github.com/freifunk-mwu/ansible-ffmwu/issues/20
    2. technik-meta
       1. https://github.com/freifunk-mwu/technik-meta/issues/50
       2. https://github.com/freifunk-mwu/technik-meta/issues/48
       3. https://github.com/freifunk-mwu/technik-meta/issues/33
       4. https://github.com/freifunk-mwu/technik-meta/issues/20
11. Nächstes Treffen: 21.6.2022 20:00, eInladen

1. Ansible (Ubuntu 14.04 / Debian Jessie)
   1. zuckerwatte (web)
      1. Wollen wir alle Dienste behalten?
   2. glueckskeks (eisen)
   3. eisen (kvm)
   4. sushi (kvm)
   5. milchreis (build)
   6. okra (repo)
2. Domains ffmz + ffwi migrieren
   1. Zeitpunkt festlegen, Knotenbetreiber informieren.
   2. 30.10.2019 abends.
      1. Announcement anpassen raussenden. (Bis KW38)
      2. Umstellungszeit setzen (Julian)
3. Backups?
   1. Wir können vermutlich den Backup space bei Hetzner verwenden
   2. Wir sichern keine Images, sondern nur Daten (DB, Mails, Blog, media, dashboards)
4. Statische Routen via BIRD managen
5. Debian Buster
   1. Repos
      1. mwu: kea, batman-adv, fastd
      2. nginx: verfügbar
      3. nodejs: verfügbar
      4. yarn: verfügbar
      5. unifi: verfügbar
      6. grafana: vermutlich (keine Angaben zur kompatibilität)
      7. influxdb: vermutlich (keine Angaben zur kompatibilität)
      8. mongodb: nicht verfügbar

1. kurzer Maschinenüberblick für die Faulen :)
   1. da sollten wir mal die Doku aktualisieren
   2. Root-Server
      1. eisen (Root-Server Freifunk Mainz), sushi (Root-Server von Stadt WI finanziert)
   3. Gates:
      1. wasserfloh (oimel), lotuswurzel (kokel), spinat ( auf eisen ), ingwer (belzebub), uffschnitt (VM auf sushi), extrasahne(Backbone Gate auf Uni)
   4. DNS Extern
      1. linse (VM bei kokel)
   5. DNS Intern/openwrt mirror
      1. aubergine (VM bei kokel)
   6. Debian Packages
      1. okra (VM bei kokel)
   7. Grafana/YANIC/Prometheus
      1. suesskartoffel (VM bei netcup/ Verein)
   8. Mail
      1. glueckskeks (VM auf eisen)
   9. Web
      1. zuckerwatte (VM auf eisen)
2. Ansible
   1. Wasserfloh auf Ansible-managed umstellen ;-)
      1. in progress
   2. Wie machen wir mit den restlichen Servern weiter?
      1. DNS
         1. entscheiden, welche DNS-Server-SW in Zukunft
         2. Split-Horizon DNS um sich die externe VM linse zu sparen; Prüfen, ob views für Slave-DNS Server funktioniert (kokel)
         3. DNS over TLS? DNSsec?
      2. Web
         1. -> Sebastian/Web Team: Etherpad+ DB aktualisieren. Wiki 
      3. Mail
         1. -> kokel
3. Festes wöchentliches Wartungsfenster?
   1. Dienstags abends - 20:00-23:00 Uhr
   2. Reboots
   3. Ansible
4. Transfernetz zwischen Gates und anderen Server
   1. Wenn wir das Netz segmentieren brauchen wir aktuell eine fastd Instanz pro Server und Domain/Site
   2. Layer3 VPN mit Wireguard und Routing auf den Gates?
      1. Von jedem Service-Server je ein Wireguard VPN zu jedem Gate (aktuell 4*6 (oder 4*5))
         1. Pro VPN ein /30 IPv4 Transfernetz, fe80 für IPv6
         2. Aus welchem range kommen die Transfernetze?
5. Eigene DNS Server auf allen Servern nutzen
   1. Momentan ist es problemematisch unsere internen DNS Server für die Adressauflösung auf den Servern einzurichten das sie nur über das Meshnetz erreichbar sind
      1. Namensauflösung schlägt beim Booten fehl und Dienste hängen
6. Segmentierung
   1. Schritt 1
      1. Bingen (+Mittelrhein)?
      2. Rheingau + Taunus in eigene Domains
   2. Schritt 2
      1. Wiesbaden + Mainz weiter unterteilen
         1. Wireless Backbone mit mehreren Domains/Sites?
   3. https://github.com/freifunk-darmstadt/ffda-domain-director
7. Backups
   1. Was?
      1. jverein
      2. grafana dashboards / influxdb / stats.json
      3. nextcloud
      4. pad
      5. ffmz blog
      6. wiki

1. Neue Gates

• • wie viele?
  • welcher Provider?
    • Julian: siehe Punkt 5
    • Provider
      • myLoc
        • interne Bandbreitenbegrenzung?
      • Hetzner
        • Finanzierung des nicht inklusiv Traffics?
      • OVH
        • Ausgehender Traffic ab 250Mbit/s gedrosselt
        • Interner Traffic 1Gbit/s - aktuellem ausgehenden
  • alternativer Gedanke: / zusätzlich kurzfristiger
    • 2. gate-VM neben spinat oder
    • spinat +2 vCPUs
  • Bingen...
    • Julian: Ja, wäre schön wenn die da mal in die Gänge kommen aber ich finde darauf können wir uns bei der aktuellen Dringlichkeit nicht warten
    • Anfragen wie ihre Planung aussieht: Eigene Intrastruktur o. Beteiligung am MWU

2. Server-zu-Server Verbindungen - Wiederaufnahme nach 5

• • GRE/L2TPv3/fastd
    • bleiben bei fastd solange es keine Probleme verursacht
  • Verschlüsselung?
  • Kompression?

3. Migration zu Debian

• • Webteam einverstanden (wartet auf Debian 9)
  • Ingwer läuft mittlerweile stabil
    • Was waren die Probleme, warum geht's jetzt?
      • Julian: Race Condition in batman-adv. Gefixt durch 2016.4 und Optimierung der Netzwerkkonfiguration
  • Kein Einwände: Wechsel mittels Ansible

4. Automatisierung via Ansible v2.2

• • Struktur - Stand, gut so?, Zukunft
    • wir sammeln:   https://pad.freifunk-mwu.de/p/ansible_fuer_gates
      • benötigte host vars => Struktur dazu
      • benötigte "Funktionen" pro server-Typ => vllcht roles ableiten
    • danach restrukturieren + Neues coden
  • was fehlt noch? - s.o.

5. Quertraffic

• • Analyse (inkl. v4 vs v6)
  • eigenes IPv6 Subnet pro Gateway
    • Anfrage an FFRL ob Netze kleiner /48 erlaubt sind: Julian fragt mal nach.
  • Clients bekommen Router Advertisements aller Gateways
    • Filterung auf den Gateways möglich?
      • https://github.com/freifunk-gluon/gluon/issues/277
    • Filterung auf Knoten: gluon Paket
      • https://github.com/freifunk-gluon/gluon/pull/838
      • sieht fertig aus und es ist beim FF Bremen seit 2016.2+bremen2 im Einsatz (ca. 90 Knoten)
      • sollten wir nach Erfahrungsaustausch mit jplitza nach packages-ffmwu aufnehmen
      • Wir bauen mal eine Testfirmware und beobachten.
    • Reduzierung der Backbonestandorte (z.B Hetzner und myLoc)
      • eigene fastd peer group pro Hoster jeweils mit peer limit 1 (2 fastd Tunnel pro Knoten)

6. SSL Zertifikate mit Letsencrypt

• • Alternativen? - keine praktikablen
    • Julian: Gibt es meines Wissen nicht deshalb wurde Letsencrypt ins Leben gerufen
      • alternativen waren StartSSL und Wosign
  • Zentrale Erstellung auf einem Server und interne Weiterverteilung? - zentral
    • https://github.com/freifunk-mwu/technik-meta/issues/29#issuecomment-257798257
  • Letsencrypt direkt auf den Servern aber nur wo es wirklich benötigt wird?
    • Web-/Mail-/Mapserver
  • Roundrobin mit Letsencrypt nicht möglich
    • dedizierter Firmware-Host anstelle von Hosting auf den Gates (Quertraffic)
    • nach unserer Diskussion müsste RR mit LE schon gehen
  • prisma wurde zum Freiwilligen bestimmt ;}

7. Monitoring

• • (formal:) ja/nein - ja!
  • was?
    • pad einrichten, um das "was" herauszubekommen / zu beantworten / zu strukturieren
  • womit? - CheckMK, wenn dann nichts dagegen spricht
  • wo?
  • wer?

8. Ablösung photon Scripte

• • https://pad.freifunk-mwu.de/p/decommission_photon
  • Julian: hatte leider noch keine Zeit...
  • Kai auch nicht ;)

9. Ablösung Meshviewer durch Hopglass

• • unterstützt kein respondd: dadurch haben wir aktuell alfred und respondd auf den Knoten laufen
  • ToDo's: https://github.com/freifunk-mwu/technik-meta/issues/51

10. L3 Mesh Gedanken

• • https://www.nilsschneider.net/2016/04/10/babel-in-gluon.html
  • Klaus_Dieter vom FF FFM arbeitet aktiv daran
    • https://wiki.ffm.freifunk.net/firmware:babel
    • http://l3-freifunk.readthedocs.io/de/latest/
    • https://github.com/freifunk-gluon/gluon/pull/934

11. [...]

• ...
• Außerbedriebnahme Kaschu
  • Julian setzt neues Gate auf, löst Kaschu ab
  • Julian nimmt als Basis Debian - wir könnte dann einen generellen Schwenk auf Debian überlegen...
• v6-Scharfschaltung durch Admin-Beschluss (in Zusammenarbeit mit FW-Team)? (nach Vorschlag aus meiner mail vom 4.5. 13:14)
  • pro-Argumente:
    • Ankündigung vor langer Zeit erfolgt
    • Stimmen aus community waren mehrheitlich dafür, es gab keine oder sehr wenige klar dagegen
    • Diskussionsbedarf hinsichtlich eines anderen Themas (Sichtbarkeit Status) -> Vorschlag trägt dem Rechnung
    • Von Statuspagediskussionpushern angekündigtes Treffen kommt nicht zustande, könnte nach Vorschlag aber später auch noch
    • es gab auch keine Gegenstimmen zu erwähntem Vorschlag
• Haben wir einen bug im Routing?
  • s. mail von Michael im Maschinenraum vom 22.5. 10:59
    • sollte schon länger behoben sein - gab's kurzzeitig im Rahmen von rules-Anpassungen für Rheinland
• ansible?
  • beführwortet - Kai schaut mal
• ICVPN
  • Neustrukturierung
    • Schritt 1: Unter einer Private AS-Flagge segeln
      • Wiesbadener Private AS aus icvpn-meta entfernen und an Mainz delegieren
      • tinc hosts namen anpassen nach "mwu_<gatename>" migrieren
    • Schritt 2: MWU im icvpn-meta anlegen
      • Neues /48 IPv6 ULA-Netz und z.B. /22 IPv4 Netz
      • Mainzer Private AS nach MWU umziehen und Mainz und WIesbadener Netze dorthin delegieren
    • Ein eigenes icvpn-meta file für MZ+WI sollte bleiben
    • Vorschlag: http://pad.freifunk-mainz.de/p/icvpn_meta
  • Tobias erläutert das Ansinnen noch mal - Freiwillige vor! - Tobias ist freiwillig ;)
• fastd peer limit
  • bei Kai noch auf'm Zettel
    • nexter Schritt: extra peer group für server-Geraffel => zwei Ordner im keys-repo (=>mail an key-Verwalter!)
• split-horizon
  • in bind gut dokumentiert - Beispiel im git-repo von ffda
  • split-master könnte aubergine werden, linse wäre dann nach Übergangsfrist obsolet
    • Matthias müsste dann seine slaves auf neuen master (aubergine) umbiegen

• Status (mit langem 'u')
  • Monitoring-VM
  • neue gespendete VM Zwiebel von Peter 
    • als Monitoring VM nutzen?
    • Wahrscheinlich zu klein (zu wenig Speicher) -> für Check_MK
    • Plan: LibreNMS installieren und testen -> Wer? -> Jan setzt es auf
  • fastd peer limits auf Gates
    • aktueller Stand?
    • Script von Frieder laueft auf den Gates Fastd-Limit wird allerdings nicht gesetzt.
    • http://spinat.freifunk-mainz.de/fastd_status.json
    • Wer kümmert sich um weitere Pflege/optimierungen? Kai? 
    • Moritz aber erst Anfang Mai
• Neuer Vereins-Server Suesskartoffel
  • suesskartoffel.freifunk-mwu.de
  • Welche Dienste von Aubergine sollen umgezogen werden?
  • Status: komplett im Freifunk Netzwerk integriert
    • Aubergine aktuell:
      • Alfred Master
      • DNS Master für alle interne Zones
      • 3x Karten Backend + 6x Meshviewer
      • interne Portale (MoinMoin) -> Umzug auf Zuckerwatte
      • BGP Looking Glass -> Umzug auf Zwiebel
      • OpenWrt Packages Mirror -> Umzug auf Zuckerwatte
    • Umzugs-Plan:
      • Alfred Master (muss wegen des Karten Backends)
      • 3x Karten Backend + 6x Meshviewer
      • DNS Master/ alle internen Zones
    • Zukunft:
      • RRD Statistiken ersetzen!
      • Diskussion in Community führen, ob wir statistische Daten erheben und wenn ja, welche über welchen Zeitraum.

• • •   Letzter Stand der Anforderungen: https://pad.freifunk-mwu.de/p/Graphite

• Diskussion fastd durch tunneldigger zu ersetzen
  • Infos
    • Blog-Post: https://wlan-si.net/en/blog/2012/10/29/tunneldigger-the-new-vpn-solution/
    • Doku: https://tunneldigger.readthedocs.org/en/latest/
    • Source Code: https://github.com/wlanslovenija/tunneldigger
    • Gluon Implementation:
      • Hauptpaket: https://github.com/ffrl/ffrl-packages/tree/master/tunneldigger
      • Intern-Konfigurations-Paket: https://github.com/ffrl/ffrl-packages/tree/master/gluon-mesh-vpn-tunneldigger
      • Config-Mode Paket: https://github.com/ffrl/ffrl-packages/tree/master/gluon-config-mode-tunneldigger
      • Migrations Paket: https://github.com/ffrl/ffrl-packages/tree/master/gluon-migrate-vpn
      • Watchdog Paket: https://github.com/ffrl/ffrl-packages/tree/master/gluon-tunneldigger-watchdog
      • Beispiel-Communities sind:  <irgendwo im Pütt>
  • Ist quasi l2tp (unverschlüsselt) im Kernel-Space, dadurch enorm performanter als fastd im user-space
  • VPN Durchsätze auf WR841er mit bis zu 30MBit/s möglich
• DNS
  • Split-Horizon DNS
    • Wer machts?
    • Beispiel Config: https://github.com/freifunk-darmstadt/ffda-bind9
  • Public DNS Server mit CCCMZ zusammen aufbauen?
    • 2 Server für Slave Zones, einer wird vom CCCMZ bezahlt, einer vom Freifunk
    • Hidden Master verbleibt in Eigenverantwortung
    • Public Slave DNS Server von treck.de auf Kokel -> IPv6
  • neue Domain ffmwu.org
  • -> bestehende gemeinsame  Dienste intern unter *.ffmwu.org erreichbar
• Exit über Freifunk-Rheinland

• Problem nach Umstellung auf v6 Knoten Kontaktdaten oeffentlich einsehbar auf der Statuspage des Knoten einsehbar.
• Diskussion auf Maschinenraum, dann Überarbeitung, dann auf großer ML mainz@ wiesbaden@

• ICVPN
  • Neustrukturierung
    • Schritt 1: Unter einer Private AS-Flagge segeln
      • Wiesbadener Private AS aus icvpn-meta entfernen und an Mainz delegieren
      • tinc hosts namen anpassen nach "mwu_<gatename>" migrieren
    • Schritt 2: MWU im icvpn-meta anlegen
      • Neues /48 IPv6 ULA-Netz und z.B. /22 IPv4 Netz
      • Mainzer Private AS nach MWU umziehen und Mainz und WIesbadener Netze dorthin delegieren
    • Ein eigenes icvpn-meta file für MZ+WI sollte bleiben
    • Vorschlag: http://pad.freifunk-mainz.de/p/icvpn_meta
• im-Blick-behalten-und-immer-mal-wieder-besprechen
  • Spaltung des Mainzer Mesh in mehrere?
  • Ersatz von IBSS durch 802.11s?

1. 1. Monitoring-VM
      1. -> Plan wird geändert, kommt auf ...
   2. neue gespendete VM (Zwiebel)
      1. -> kokel schon kräftig dabei
   3. Spinat-Umzug
      1. -> Soweit durch - Konfetti!
   4. http://pad.freifunk-mainz.de/p/rechner
   5. fastd peer limits auf Gates
      1. -> kümmert sich jetzt Frieder drum (Kai hat's ja nicht gemacht ;) )
      2. -> kann aber ein paar Wochen dauern, bitte geduldet euch ein bisschen.
2. Split-Horizon DNS
   1. -> Klingt vernünftig. Machen wir.
   2. -> Wir überlegen uns, ob wir in Zukunft bei BIND bleiben, oder uns was anderes suchen. Bundy! -> http://bundy-dns.de 
   3. -> wir schauen, wie wir CNAMEs, oder identische zone files zwischen ff*org und Freifunk-*de hinbekommen
3. neue Domain ffmwu.org
   1. gibt es jetzt, vielen Dank :)
4. TLS Zertifikate
   1. kokel könnte Startcom Zertifikate (wildcard) erstellen (2 Jahre Gültigkeit)
   2. jan könnte Letz Encypt empfehlen ;) Dann mach das doch mal ;-) Okay.
   3. -> kokel besorgt erst einmal Zertifikate bei Startcom, dann haben wir 2 Jahre Zeit zum entscheiden (oder es zu verpeilen ;)
5. Exit über Freifunk-Rheinland
   1. Announce-Liste: https://mailman.freifunk-rheinland.net/mailman/listinfo/backbone-announce
   2. Wir müssen die TCP Max Segment Size clampen, weil sonst viele TCP-Verbindungen nicht aufgebaut werden können
      1. FFRL Tunnel MTU = 1400
   3. -> kokel dokumentiert das neue setup
   4. RIPE-Handles sind zugeordnet
      1. https://apps.db.ripe.net/search/lookup.html?source=ripe&key=185.66.195.32%20-%20185.66.195.35&type=inetnum
      2. https://apps.db.ripe.net/search/lookup.html?source=ripe&key=185.66.195.36%20-%20185.66.195.39&type=inetnum
      3. https://apps.db.ripe.net/search/lookup.html?source=ripe&key=2a03%3A2260%3A11a%3A%3A/48&type=inet6num
      4. https://apps.db.ripe.net/search/lookup.html?source=ripe&key=2a03%3A2260%3A11b%3A%3A/48&type=inet6num
   5. Abuse haben wir momentan noch nichts mit am Hut, weil FFRL noch nicht so weit ist. Wenn der Leidensdruck hoch genug ist die soweit sind, kommen sie wieder auf uns zu.
   6. Wer hat was getestet?
      1. iperf tests direkt auf das gate: https://gist.github.com/kokel/ed9ff6c4b563dcfa19ec
      2. Daheim hinter Futro-Offloader an VDSL50 Leitung mit speedtest.net: bis zu 37MBit/s down, 8MBit/s up (Lotuswurzel)
   7. Schalten wir scharf, wenn ja, wann?
      1. Zuerst IPv4?
      2. Dann nach Ankündigung mit Aufklärung auch IPv6?
      3. Nicht nach Erlaubnis fragen, einfach (nach netter Ankündigung) einfach machen.
   8. -> die anderen admin werden per Liste informiert; Moritz trägts wegen spinat in den Vorstand; werden hoffentlich alle mitmachen
   9. Tunnel für die drei verbleibenden Gates sollten schnell gehen, Kommunikation läuft momentan sehr schnell
   10. Behalten wir Perfect Privacy? (https://www.perfect-privacy.com)
   11. Bis zur Umstellung auf Freifunk Rheinland
   12. Wenn wir umgeschaltet haben müssen wir an FFRL spenden
   13. 10-20euro/monat wird in der naechsten Vorstandsitzung beraten
6. Mail-Setup auf glueckskeks
   1. Wie strukturieren wir die Mailinglisten? (entscheiden wir das überhaupt?) Was gäbe es denn zu strukturisieren? -> subdomain "lists"
   2. Wie wird mit Mail umgegangen? (entscheiden wir das überhaupt?)
      1. Funktionspostfächer, auf die persönliche Postfächer berechtigt werden
         1. Man kann im Namen derer E-Mails verschicken
         2. schließt Aliases aus
      2. Oder wieder stumpf Weiterleitungen?
   3. EZMLM! http://cr.yp.to/ezmlm.html
   4. Mailman! https://www.gnu.org/software/mailman/jwzrebuttal.html
   5. -> JobAusschreibung über Listenverteilen -> MailAdminTruppe initiieren
7. ffhesscon - https://wiki.mag.lab.sh/wiki/Freifunk_Fulda/ffHessCon_2015.1
8. Dokumentation
   1. Wieder verstärkt das (Mz->MWU)Wiki nutzen - Systeme / github-Wiki schließen
   2. Gateway-Dokumentation kann auf readthedocs.org bleiben
   3. Netzplan sollte ins Wiki umziehen
9. Backbones MZ / WI / MWU
   1. Wir koordinieren stark und betreiben quasi ein gemeinsames BB.
   2. 2 VLANs auf WLAN (37 und 56) und 2 Batman-Instanzen auf gemeinsamen Standorten (auf 1 HW oder 2 HW)
      1. werden->eth auf andere VLANs gebridged

1. Status (mit langem 'u')
   1. Monitoring-VM - warten auf Frieder
   2. neue gespendete VM -> Aubergine
   3. Spinat-Umzug
      1. Neuaufsetzen mit LVMs für virtuelle Maschinen
      2. Virtualisierung mit KVM
      3. 1x Gate
      4. 1x Web Server (Mainz HP, Mainz Blog, Wiki, Wiesbaden HP)
      5. 1x Mail - alle domains auf einem mail server + mailing listen
2. fastd peer limits
   1. auf Gluon Knoten auf 1 herabsetzen - beschlossen
   2. gute Werte für fastd peer limit auf Gateways finden (separat für die jeweiligen meshes)
      1. eigene peer group für Inter-Gate + Dienste-Server
      2. Peer Limit auf Dienste Server = Anzahl an Gates
      3. Peer Limit Berechnung
         1. Aktuelle fastd Verbindungen auf jedem Gate pro Mesh per Alfred announcen
         2. Alternativ jedes Gate fragt jedes Gate über ssh remote commands -> verlässlicher -> akzeptiert
         3. gate fragt alle:
            1. ist gate ein gate?
            2. aktuelle fastd connections
         4. jedes Gate speichert die maximale anzahl an aktiver fastd verbindungen in summe über alle gates
      4. Mainz, insg. 332 Knoten
         1. /4 = 83 + Aufschlag  = peer limit von 110
      5. Wiesbaden, insg. 188 Knoten
         1. /4 = 47 + Aufschlag = peer limit von 70
      6. Alternativer Weg:
         1. Peer Limit auf die Hälfte der Gesamt-Anzahl an Knoten setzen, damit sichergestellt ist, dass mindestens zwei Gates das volle Netz stemmen können
      7. welche Zahl auch immer - bekommen wir eine Automagisierung hin? (á la alle 24h gates Zählen und Wert neu setzen...)?
         1. Über den fastd-status socket ist das möglich
            1. Gesamtanzahl an eingelesenen fastd-peers: sudo fastd-status /var/run/fastd-wiesbaden.status | jq '.peers | length'
            2. Anzahl der verbundenen fastd-peers: sudo fastd-status /var/run/fastd-wiesbaden.status | jq '.peers | map(select(.connection)) | length'
            3. Aktuelles Limit in fastd.conf: awk '{ if (match($0, /^peer\slimit\s([[:digit:]]+)\;$/, limit)) print limit[1] }' /etc/fastd/wiVPN/fastd.conf
         2. Damit ließe sich das scripten, erfordert allerings einen richtigen Restart von fastd
   3. Dadurch schaffen wir unabhängig der batman-adv version auf den knoten eine bessere Gateway-Verteilung
3. HT-Mode auf 20MHz herabsetzen -> beschlossen
   1. Client-WLAN wir von hostapd verwaltet
   2. Mesh-Adhoc nicht
   3. Wenn der sekundäre Kanal belegt ist wechselt hostapd automatisch das client wlan auf 20MHz um, das mesh-interface bleibt aber auf 40MHz - suboptimal für chipsatz, airtime, etc.
4. sinnvollste MTUs an allen beteiligten interfaces ausklabüstern
   1. Backbone-Geräte
      1. BATMAN = 1532 Bytes
      2. VLAN = 4 Bytes
      3. Summe = 1536
   2. fastd
      1. Viele Communities haben die fastd-MTU auf 1280 herabgesetzt, um einfach jegliche MTU-Probleme diverser Internet-Anschlüsse aus dem Weg zu gehen.
      2. Wird für gut befunden, geringe Priorität, da viel Aufwand
5. MAC-Konflikt-Warnung
   1. https://github.com/freifunk-gluon/gluon/blob/71cdd65f30580df9d683718ce96417a133851bdc/package/gluon-core/files/usr/lib/lua/gluon/util.lua#L83-L90
6. Bingener
   1. Wollen eigene Infrastruktur aufbauen
   2. Eigene Infrastruktur unabhängig vom MWU Netz ist präferiert
      1. fördert Dezentralitat
      2. keine zusätzlichen Latenzen bei Abstimmungen zwischen Bingen und MWU
      3. Austausch erfolgt trotzdem
7. Monitoring
   1. Was wollen wir Monitoren (Freifunk ist kein HA so bekommen alle Nutzer ausfälle mit)
   2. Wie machen wir das Alerting (mail ...)
   3. Welche Daten wollen wir Speichern ?

1. Neuer Admin: Daniel
2. Exit über Freifunk Rheinland
   1. https://ticket.freifunk-rheinland.net
   2. Aktuell noch starke Probleme mit IPv6 Traffic über den GRE-Tunnel
      1. Aug 20 14:23:36 lotuswurzel kernel: [ 769.240973] ip_tunnel: non-ECT from 185.66.195.1 with TOS=0x1
      2. Ein paar Sekunden später steht die ganze VM + VM-Host + alle anderen VMs auf dem Host -> nur Reboot hilft
      3. Primär wird an einer Problemlösung gearbeitet, um vernünftig testen zu können.
      4. Parallel versuchen wir ein weiteres Gate (Mettigel) hochzuziehen und auch für Rheinland Exit zu konfigurieren. Um Unique-Probleme der Lotuswurzel (Hetzner) auszuschließen wird auf dem Mettigel nochmal getestet.
      5. Prisma setzt Mettigel mit Ubuntu 14.04 auf.
      6. Kokel bittet Rheinland (mit Nachdruck!) um Konfiguration weitere GRE-Tunnel
   3. Wie testen wir?
   4. Wann schalten wir IPv4 um?
   5. Wann schalten wir IPv6 scharf?
   6. Wie und was kommunizieren wir an die Gemeinschaft?
3. Integration kleinerer Communities
   1. Bingen
      1. Go the standard way and launch just another mesh instance on all gates
   2. Westerwald
      1. Gluon-Luft im Mainzer oder Wiesbadener Mesh schnuppern
      2. Wenn von Anfang an eigene Firmware, dass mit eigenem FIrmware-Repo
      3. Ob im Mainzer oder Wiesbadener Mesh dürfen die selbst entscheiden
4. Öffentliches Admin-Treffen
   1. Wann, wo?
   2. Treffen wird öffentlich announced mit Aufforderung bei Teilnahmewunsch (verbindlich!) per mail Bescheid zu sagen.
   3. Wofür? (Ziel,Themen,...)
   4. Wer bereitet was vor?
   5. Für weitere Aufwändige Treffen muss erst evaluiert werden wer daran interesse hat.
5. Inkarnation Firmware-Truppe
   1. Wie?
      1. Termin raussuchen, Announcement und auf interessierte Leute warten
   2. Wer kümmert sich?
      1. spky, kokel, prisma hilft beim announcement formulieren
6. Neue Routing-Config
   1. Ziel? Vorteile?
   2. OK? Nicht OK?
   3. rc.local oder doch upstart-script?
   4. wir nehmen erstmal rc.local im Zweifel kann das auch noch kurzfristig geändert werden
   5. Kai kümmert sich darum, siehe gluon gateway doku
7. Monitoring
   1. gewollt? Ja!
   2. wo? wie? im moment bei kokel zu hause. Verlegung auf VM vom chaos und tuning. Frieder stellt den Antrag im Chaos.
8. Layer-3-Routing zwischen mehreren Wolken (City-Communities)
   1. Gluon-Ansätze, Sammlung von Links:
      1. https://forum.freifunk.net/t/experimenteller-server-fuer-verteiltes-dhcp/5426
      2. https://gist.github.com/tcatm/94932ffc80ca30d07e8e
      3. https://gist.github.com/tcatm/9f39c3fe14684db02803
      4. https://gist.github.com/tcatm/2dd0e6699f2a153505d0
      5. https://gist.github.com/NeoRaider/0c36adf38bcf775b0ebe
      6. https://github.com/tcatm/pyddhcpd
      7. https://github.com/freifunk-gluon/gluon/tree/babel
9. Terminfindung regelmäiges Admin-Treffen
   1. Regelmäßig
      1. Jede 1. Woche im Monat
      2. Rollierender Werktag
      3. Beginn am Montag, den 05.10.2015 in Mainz
      4. Abwechselnd in Mainz/Wiesbaden
10. Dynamisches Routing für intern
    1. Wofür? -> z.B. Dienste-Server, die auch aus dem ICVPN erreichbar sein sollen
       1. Beispiel Aubergine (Karte, Portal) hat nur ein layer2-Bein in jeder Wolke, keine Rückrouten ins ICVPN, ergo Portal/Karte nicht aus anderen Communities erreichbar
    2. Wie - iBGP/RIP/OSPF ???
       1. vermutlich iBGP -> Kai
11. Bugfix Release stable?
    1. Daniels Key mit reinnehmen
    2. Dann Go
12. 802.11s Test in experimental Firmware
    1. jo

• isc-dhcp-server lease-file rotating bug durch ACL gefixt
• neue Beta
  • http://pad.freifunk-mainz.de/p/gluon-announcement
  • DATE=2015-07-01 23:42:42+02:00
  • PRIORITY=1.2
  • Unterschied zur letzten Beta: Aufnahme des Gates Kaschu
• DNS-/NTP-Verteilung über DHCPv4/Router Advertisments
  • Jedes Gate verteilt nur noch seine eigene IP-Adresse als DNS und NTP Server
• neue Arbeitsgruppe: Firmware
  • eines der nächsten Admin-Treffen läuft unter dem Motto "Firmware"
  • öffentlich zugänglich für jeden, der Interesse hat
  • Ort finden
  • Datum finden
  • rechtzeitiges Announcement

Link to the Pad