Nachdem die Infrastruktur, die der 4830.org e. V. für verschiedene Freifunk-Gruppen betreibt, runderneuert und von Altlasten befreit wurde, möchten wir im Rahmen von hands-on-Sitzungen alte und auch neue Admins an diese unsere Infrastruktur heranführen.
Wir haben auf unserem Treffen am Donnerstag konkret besprochen, daß wir für die Zielgruppe »Linux-Admins mit sudo-Kenntnissen« uns mal zwei bis drei Stunden per Videokonferenz treffen und versuchen wollen die Frage zu erörtern, was einerseits alles, und ggf. wie, funktonieren muß, daß ein Nutzer sich über seinen Knoten ins Freifunk-Netz verbinden kann und es vollumfänglich nutzen — und, ggf. zeitbedingt nur kurz ansatzweise, wie denn verschiedene Dienste per Ansible bei uns konfiguriert werden.
Dies wird die erste von vermutlich wenigstens drei bis vier solcher Sessions sein, Ziel dieses Mal ist das »Big Picture«, also welche Komponenten haben wir, wie spielen sie zusammen und wie werden sie bei uns administriert (auch: welche Syteme fallen unter »cattle«, welche unter »pets«).
Ort: unser Jitsi, Dauer: zwei bis max. drei Stunden, Termin: wird genuudelt, Vorkenntnisse: ›Junior Linux-System-Administrator‹, Sprache: deutsch, Zielgruppe: Freifunk-Admins (d/m/w) – sowie solche, die es werden möchten ;-) – aus den betreuten Communities.
Wir werden eine (Audio-) Aufzeichnung vornehmen und aus dem Transkript hoffentlich Blöcke für eine High-Level-Dokumentation nutzen können.
Und noch ein reminder … Ich werde die Terminumfrage auf Nuudel am kommenden Mittwochabend schließen, damit alle wissen, woran wir sind. Z. Zt. wären wir nur zwei Teilnehmer, das wäre etwas enttäuschend, bliebe es dabei, denke ich. Zumal auch keine generelle Kritik an den angebotenen Terminen kam …
Nachdem Mailauslieferung bei @bjoerrrrn wg. zu vieler Bounces deaktiviert war und auch an @Andreas und @m.bitterlich der Reminder nicht verschickt wurde (dunno why), zweiter Anlauf —sorry for the noise an den Rest
Ja, wie gesagt, es gab’ am 14.04. 2x User-Unkown-Bounces, da ist Discourse dann wohl schnell am Zustellung abdrehen:
<XXXXXXXX@XXXXXXXXXXXXXXX.de>: host mail.XXXXXXXXXXXXXXX.de[123.456.789.666]
said: 550 5.1.1 <XXXXXXXX@XXXXXXXXXXXXXXX.de>: Recipient address
rejected: User unknown in virtual mailbox table (in reply to RCPT TO
command)
Aktuell haben wir also Pfingstsamstag und am Sonntag drauf , 26.05., jeweils um 14 Uhr 'nen Best Match. Warten wir also bis Mittwoch und dann wird der Termin festgesetzt.
FTR, ich habe hier in ~700 MB .webm die Aufzeichnung der Session — @kurt, Du erwähntest, Du hättest Dir für die Transkription schon 'ne Pipeline gebaut?
FTR: wir haben uns für kommenden Sonntag nochmal von 14-16 Uhr (Plan, dritte Stunde bitte möglichst freihalten) verabredet; neue URL (weil die Aufzeichnung den Meetingnamen beinhaltet), Kalendereintrag (bitte auf 2-3 Stunden händisch erweitern) hier.
Themen, @bjoerrrrn hat ja schon angefangen, sammeln wir hier im Thread — bis kommenden Freitag wäre schön, eine Liste zu haben, dann kann ich ggf. was vorbereiten.
(FTR: @Cord und @bjoerrrrn Admin-Zugriff auf github- und gitlab-Repos gewährt.)
Ohne dem nächsten Treffen vorgreifen zu wollen: vgl. Technik und Infrastruktur – Freifunk Ingolstadt — FFIN setzt, wie ›FFOWL‹, auf den Münsteraner Ansible-Rollen auf, daher paßt da einfach vieles und könnte ggf. für eigene Beschreibungen übernommen werden.
Bekannte Unterschiede:
Wir setzen in der 4830-FW OWE/Enhanced Open nicht im Transition Mode ein — ältere Clients haben lt. Berichten im Forum damit ggf. Probleme, daher senden wir 2 SSIDs: die klassische, unverschlüsselte und owe.$SSID für eine Verbindung gezielt mit Opportunistic Wireless Encryption, wenn dies die HW zuläßt.
Latürnich nutzen wir keine FFRL-Exit-IP bzw. -Tunnel mehr, das fällt alles direkt am jeweiligen GW in unser AS206813 und geht von dort aus weiter
Unser Setup für den Firmware-Server (fw.4830.org, firmware.4830.org) unterscheidet sich ebenfalls; unter firmware haben wir ›alle‹ Releases, also grob seit 2014, (noch(?)) verfügbar — der Firmwareselector (fw) bricht bei der Datenmenge dann sehr blaß ins Essen. Daher sorgen ein Cronjob und das da aufgerufene Script dafür, daß der Firmwareselector nur mit genau 1 Version je Branch umgehen muß — damit ist für den Normalanwender ein komfortabler Weg eröffnet und wer meint, müssen zu müssen, kann sich dem Thema auch per Directory-Listing unter firmware.4830.org nähern
Docker nutzen wir (hier) nicht, Webserver sind VMs, ggf. mit so Diensten wie influx lokal — Hinergrund: wir betreiben >1 Handvoll Bare Metal Server, da können wir uns eine VM je Dienst leisten
Unsere Firmware verfolgt einen anderen Ansatz als die im nativen Gluon:
Als Knoten mit Uplink arbeitet das Gerät eh’ als Client im LAN, ergo wird auch im Config Mode eine IPv4-Adresse über den WAN-Port angefragt — kein Umstecken von Kabeln mehr
Wenn der Knoten eh’ online ist, kann dieser auch Dienste im Internet selbst nutzen
Ohne WAN wird Adresse aus TEST-NET-3 konfiguriert — die Erst-Konfiguration ist dann technisch nicht möglich
Unser Config-Mode fragt die relevanten Punkte – Aufstellort, Email-Kontaktadresse (zwingend) – gezielt ab, verlinkt am Ende direkt auf die Configseiten zu den einzelnen Einstellungen
4830 setzt auf Funktionalität statt auf Aktualität; neue Gluon-Versionen lassen wir erst ›im Feld‹ ausgiebig testen; nicht selten überspringen wir auch einzelne Gluon-Releases
Wir sind in den meisten Punkten ähnlicher Ansicht. Alles, was ich anders sah, ergibt mit den Erklärungen zum Kontext Sinn. Ich verlasse mich hier auf eure/deine Erfahrung und lasse mich gerne überzeugen.
FTR, ich habe hier in ~700 MB .webm die Aufzeichnung der Session — @kurt, Du erwähntest, Du hättest Dir für die Transkription schon 'ne Pipeline gebaut?
Ich wollte gestern noch diese Bilder gezeigt haben, um die Verbindungen der Gateways untereinander (per Batman-Bridge) bzw. zu den ICVPN-Gateways (per L2TP-L3-Tunnel und eBGP-Sessions) zu besprechen ⇒ am Sonntag dann
Im Vorgriff auf Sonntag möchte ich auch auf diese ältere Grafik aus 2015 verweisen, die die verschiedenen Netzwerkebenen und den Datenfluß aus dem Mesh ins Internet zum damaligen Zeitpunkt zu visualisieren versucht. Am Prinzip hat sich nichts geändert; wir haben nun ca. drölfzig Meshes statt einem, die Gateways bedienen i. d. R. mehrere Meshes (u. a. weil L2TP massiv weniger ›teuer‹ ist verglichen mit fastd damals), die damals vier BGP-sprechenden Systeme sind nun 9 und nicht auf zwei (DUS, FKS) sondern drei (BER, FRA, HAM) Standorte verteilt, die Gateway-VMs leiten direkt ins AS206813 aus (bei IPv4 mit NAT auf die IP des Gateways, bei IPv6 durch normales Layer-3-Routing — unsere Meshes haben /64 aus 2001:bf7::/32 vom Berliner Förderverein) und der ICVPN-Layer hängt nicht mehr auf der Ebene des AS206813-BGP sondern ist auf die Gateway-Ebene gewandert (einerseits Zielkonflikt: in der DFZ, der ›default-free zone‹, werden private oder nicht für die öffentliche Nutzung vorgesehene Netze oder AS-Nummern aktiv herausgefiltert — im ICVPN werden praktisch nur private AS-Nummern und Netze verwendet. Andererseits auch logischer: wir wollen Kommunikation zwischen Teilnehmern in Meshes ermöglichen, daher gehört das ICVPN direkt mit den Gateways verbunden).
Hellblauer Knotenlayer, unten:
Die Knoten mit WAN-Zugang bauen einen (heute: L2TP-)Tunnel zu einem Gateway auf; in dem Tunnel wird das »B.A.T.M.A.N. Advanced«-Protokoll (Protokollversion 15) gesprochen. Etwaige LAN- und WLAN-Interfaces werden mit dem Batman-Interface in einer Bridge zusammengefaßt. Batman bildet die Layer-2-Wolke.
Dunkelblauer Gateway-Layer:
Die Gateways sind (x64-) VMs, die gen Internet öffentliche IPv4- und IPv6-Adressen erhalten. Ferner haben die Gateways das batman_adv-Kernelmodul geladen und 1-n bat0x-Interfaces konfiguriert — Mesh [0]1 entspricht bat01, Mesh 66 entsprechend bat66. Weiterhin ist ein VPN-Dienst für eingehende Verbindungen konfiguriert, bei uns derzeit Tunneldigger; dieser lauscht auf (IPv4-) UDP-Port 10000+${meshid}, verbindende Clients (also Freifunk-Knoten) werden ins entsprechende Batman-Interface (printf "bat%02d" ${meshid}) bridged.
Die Knoten verbinden sich entsprechend zur öffentlichen (IPv4-) Adresse des Gateways und dort einem UDP-Port, gemäß in der Firmware hinterlegter site.conf-Einträge (siehe Gluon). Aus $Gründen nutzen wir max. 6 GW-Einträge und diese in der Form printf "g%02dm%02.4830.org" $gwnum $meshid — das sind dann im DNS CNAMEs mit kurzer TTL (normalerweise 3600 Sekunden, also 1 Stunde).
Die Gateways haben einen lokalen (ISC-DHCP-) Server, i. d. R. hat jedes Mesh ein /20 IPv4-Adressen (4096 fortlaufende Adresses) aus unseren ICVPN-Pools und ein IPv6-/64; wir verteilen die Clients je Mesh üblicherweise auf 4 Gateways, sodaß jedes GW rd. 1000 IPv4-Adressen per DHCP vergeben kann. Lessons learned: Clients verlassen das Mesh, sie melden sich nicht aktiv ab. Daher müssen Anzahl IP-Adressen und übliche Anzahl Clients sowie die Leasetime vergebener IPs pro Gateway in einem ›gesunden‹ Verhältnis stehen. Zu kurze Leasetime bei zu kleinem Pool: Adresswechsel während der Nutzung == sporadischer Abbruch aller (IPv4-)Verbindugen. Zu hohe Leasetime bei zu kleinem Pool: keine freien IPs == neue Clients bekommen keine IPv4-Adressen. Zu kurze Leasetime bei ausreichendem Pool: im WLAN roamende Clients bekommen – da Batman IPv4-Broadcasts in Unicasts zum nächsten Batman-GW umschreibt – vom neuen GW eine neue IPv4-Adresse == sporadischer Abbruch aller (IPv4-)Verbindugen. Alles tricky; aber der Ansatz mit DHCPRELAY auf den GWs zu einem zentralen DHCP-Server (die gelben Links im Bild) – der entsprechend für das gesamte Mesh IPs vergibt – war auch nicht das Gelbe vom Ei und im heutigen Setup wäre das deutlich unhandlich. Daher verbraten wir zwar relativ viel »Freifunk-ICVPN-Space« — aus 10.0.0.0/8 belegen wir – und nutzen teilweise – derzeit 10.26.0.0/16 und 10.29.0.0/16 (Ex-FFBI), 10.169.0.0/16 (Müritz), 10.234.0.0/15 und 10.255.0.0/16 (Ex-FFGT). Zukünftig würden wir dann noch Lippes Adressen (10.15.0.0/18) als Reserve übernehmen, ebenso 10.134.0.0/16 von Uelzen. Hernach käme dann perspektivisch eine Konsolidierungsphase und Freigabe nicht benötiger Bereiche.
IPv6 nehmen sich die Clients selbst per SLAAC, ggf. mehrere IPs via Privacy Extensions. Die Knoten announcen per RA ein ULA-Prefix per Mesh, die Gateways ein Public-v6-Prefix per Mesh.
Die IPv4-Adresse eines Clients wird, wenn sie das Gateway gen Internet (und nicht in ein anderes eigenes oder, via ICVPN, entferntes Mesh) passiert, auf ›die‹ IPv4-Adresse des Gateways geNATet — IPv6 wird hingegen geroutet.
Schließlich gibt es, damit die Meshes untereinander verbunden sind, Layer-2-Tunnel zwischen den batXX-Interfaces der verschiedenen Gateways sowie Layer-3-Tunnel zwischen den Gateways für das korrekte interne Routing per iBGP bzw. OSPF. Ferner gibt es Layer-2-Tunnel für die Verbindung der Map-Server in die Meshes …
Alle unsere GWs befinden sich auf Hypervisoren im AS206813 und machen, wie gesagt, IPv4-Exit direkt mit AS206813-Adressen, sowohl bei IPv4 als auch bei IPv6. Auch fast alle anderen (Hilfs-) Systeme laufen in unserem AS; Ausnahmen sind u. a. unser Mailserver (läuft auf meinem Server in ›HAM1‹ im AS49745) und unser Uptime-Kuma-Server (läuft – für die ›Sicht von außen‹ – auf meinem Hetzner-Server in Helsinki, im Hetzner-AS; dies wäre allerdings auch ein System, was in einer public Cloud laufen könnte oder sonstwo außerhab unseres Netzes).
Vielleicht hilft das Bild zusammen mit dieser Beschreibung ja, konkretere Fragen für nächsten Sonntag zu formulieren, ohne daß ich das noch mal aktuell aufmalen muß Oder jemand anders versucht mal eine Visualisierung anhand obiger Beschreibung, die wir dann Sonntag besprechen oder verfeinern können?
DNS, Firmware-Bau sind weitere, schon genannte Themen, ich versuche dazu noch was vorzubereiten.
Mapserver sind relativ langweilig (JS-Anwendug pullt .json und stellt es dar; .json wird entweder von HopGlassServer oder yanic aus der Batman-Verbindung in die Meshes per Multicast-Anfrage eingesammelt bzw. aus den respondd-Daten erzeugt), Longtermstorage für Grafana ist ein weites Feld — das würde ich fast gerne in einem Workshop behandeln, in dem man auch brainstormed (nach Vorbereitung ;-)), ob yanic oder HopGlassServer wer Weg vorwärts sein sollte, analog auch, ob es Hopglass oder Meshviewer als Frontend (beide bzgl. Weiterentwicklung IIRC 'ne Baustelle) sein sollte.
