[freifunk-do-infra] Dokumentation übergabesessi... Betreff: [freifunk-do-infra] Dokumentation übergabesession Supernodes Von: Markus Lindenberg <[email protected]> Datum: 09.05.2015 20:51 An: [email protected] Kopie (CC): [email protected], [email protected] Hi zusammen, ich habe meine Notizen von gestern und 'nen Braindump zusammengeführt und angehängt, jetzt ist 'ne Art Anfang einer Infrastruktur-Doku draus geworden. Es ist noch ein wenig roh, insbesondere möchte ich noch das bisher gneutzte IP-Adressschema dokumentieren. Ich lerne gerade erst Routing für Erwachsene, also falls ich mit der Lingo teilweise nicht so getroffen habe verbessert einfach. Auch ist sicher nicht alles zu 100% korrekt. Ich möchte das natürlich noch im Wiki hochladen, kommt später. Erstmal wollte ich's so schnell wie möglich verteilen ohne mich in Tools einzudenken. lg, m. supernodes.md # Freifunk Dortmund Infrastruktur ## Ist-Zustand FFRUHR-Supernodes Die vier Supernodes für Freifunk Dortmund werden auf dem verteilten VMware-Cluster von FFRUHR betrieben. Die Standard-Installation basiert auf Debian 7.0, neue Instanzen werden von alten Servern geklont und dann umkonfiguriert. Die in diesem Abschnitt gesammelten Informationen stammen von unseren Mitschriften einer mehrstündigen Übergabe-Session im Mumble und gemeinsamer Screen-Session mit Chris am 8.5.2015. ### Software-Komponenten #### Fastd *Fast and Secure Tunneling Daemon.* Es gibt zwei [Fastd](https://projects.universe-factory.net/projects/fastd/wiki)Instanzen, eine für Nodes (Port 10000) und eine für Supernodes untereinander (Port 10001). Ein Fastd-Prozess kann nur eine CPU nutzen, deshalb ist Fastd der limitierende Faktor für die Skalierbarkeit von Supernodes. Fastd performt auf Blech nicht viel besser als virtualisiert, aus nicht ersichtlichen Gründen hat man nur 5% mehr Clients als in den jetztigen VMs hingekriegt, danach wurde das System spürbar beeinträchtigt. Deshalb wurde die Entscheidung getroffen, Supernodes zu virtualisieren um die Hardware besser auslasten zu können. 1 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... Über ein Status-Socket können Zustand und Statistiken eines laufenden Fastd abgefragt werden. Dies wird derzeit nur manuell durch Scripte zum Debuggen genutzt. Eine Statistik über Auslastungen und andere ausgespuckte Metriken erzeugen zu können wäre schön, hat aber noch niemand realisiert bisher. Bei Konfigurationsänderungen an der `fastd.conf` einer Instanz muss der Fastd durchgestartet werden und die Clients verlieren die Verbindung, das gilt aber nicht für per `include`-Anweisung eingebundene Fragmente, die über ein `SIGHUP` neu eingelesen werden können. ##### Client-Instanz (Port 10000) * Diese Instanz wird von den Nodes genutzt, Konfiguration liegt in `/etc/fastd /ruhrgebiet/`. * Verschlüsselung: `salsa2012+umac`, momentan ist noch `null` erlaubt, aber die Nodes erzwingen Verschlüsselung. `null` kann also eigentlich raus und war nur aus Kompatibilitätsgründen eingetragen. * Das bereitgestellte Interface `tap0` nimmt am B.A.T.M.A.N. Mesh teil. * Bei jedem eingehenden Verbindungsaufbau wird von Fastd ein Shell-Script aufgerufen, welches den Fingerprint (?) des Client-Keys übergeben bekommt. Anhand des Rückgabewertes des Scriptes wird entschieden, ob die Verbindung zugelassen wird. * Das Script prüft lediglich gegen eine Blacklist, ob ein Client explizit gesperrt ist, alle anderen Verbindungen werden zugelassen. * Die Blacklist wird alle 5 Minuten durch einen Cron-Job mit `wget` von https://github.com/ffruhr/fastdbl aktualisiert. * Früher war hier ein Verzeichnis mit Keys eingetragen. Da Fastd nicht startet, wenn kein Key-Verzeichnis angegeben wird, ist immernoch ein Dummy-Verzeichnis vorhanden und in die Konfiguration eingetragen. * Durch die Option `hide ip addresses yes` wird das Logging der Quell-IPs von verbundenen Clients zwecks Datensparsamkeit verhindert. * Der Status Socket reicht auf Anfrage trotzdem die IPs von aktuell verbundenen Clients mit raus. * MTU im Tunnel ist 1364 entspricht Transport-MTU 1450 ##### Supernode-Instanz (Port 10001) * Hier ist die Liste der Peers auf jedem Supernode fest eingetragen und besteht aus den anderen Dortmund-Supernodes und dem Map-Server. Andere Peers werden nicht zugelassen. Jeder Server hat eine Verbindung mit jedem anderen Server. * Dass hier Fastd genutzt wird ist historisch so entstanden aber kein muss. Hauptsache, wir haben ein Layer 2 zwischen den geographisch verteilten Supernodes. * Die Datenübertragung erfolgt Unverschlüsselt (`method "null"`). * Das bereitgestellte Interface `tap1` bildet effektiv ein Layer 2 zwischen den betiligten Supernodes/Map-Server und nimmt am B.A.T.M.A.N. Mesh teil. * BGP-Sessions zwischen allen Servern werden über diese Verbindung (bzw. das hindurch laufende B.A.T.M.A.N.) gefahren. * In der `on up`-Anweisung dieser Instanz wird fast die gesamte FF-spezifische Netzwerkkonfiguration durchgeführt. * Einiges wurde schon nach `/etc/network/interfaces` migriert, es sind aber trotzdem noch Anweisungen drin, die woanders besser aufgehoben sind oder gar nicht vom Status des Interfaces `tap1` abhängen. * `alfred` und `batadv-vis` müssen eigentlich nicht mehr von Fastd gestartet werden, das war so weil die `br0` früher auch von Fastd angelegt wurde. 2 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... #### B.A.T.M.A.N. [B.A.T.M.A.N.](http://www.open-mesh.org/projects/open-mesh/wiki) * Benötigt Kernelmodul * Sorgt gern mal für Abstürze -> Watchdog (systctl) * Kompatibilitätsmodus 14 (`bat14`) wird genutzt. * Momentan wird die "gepatchte Legacy-Version 2013.4 aus dem Gluon-Repository verwendet. Es kann auch eine neuere, ungepatchte Version verwendet werden, sofern dort auch `bat14` genutzt wird. * Man befolgt i.d.R. die Empfehlungen der Gluon-Entwickler. * `echo 120 > /sys/class/net/bat0/mesh/hop_penalty` ist wichtig, damit die VPN-Links von B.A.T.M.A.N. benachteiligt werden. * B.A.T.M.A.N. bewertet Paket Loss als Metrik, ohne Anpassung würde B.A.T.M.A.N. lieber über den Supernode schicken als direkt zwischen meshenden Nodes weil das VPN weniger Packet loss als WiFi hat. * Vorsicht vor einer Mißbrauchsmöglichkeit: Wenn die Nextnode-Mac nicht die eigene ist, ist ein Mesh-Node fehlkonfiguriert und zieht den Traffic an sich. (?) * Bandbreite in B.A.T.M.A.N. muss auf allen Supernodes exakt gleich konfiguriert sein damit die Metrik identisch ist. * Wenn Fastd abstürzt wird manchmal auch `bat0` unbrauchbar, deshalb wird es im Fastd `on up` Script von beiden Fastd-Instanzen (identisch) neu konfiguriert. * B.A.T.M.A.N. sieht zwar nach Layer 2 aus, routet aber faktisch und ist nicht zu 100% transparent. #### Dnsmasq [Dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) * DNS-Cache/Forwarder * Forwarded aus Performance-Gründen nicht durch FF sondern fällt beim Hoster ins Internet auf zwei FF-DNS-Server, die Colocated mit den Supernodes sind. * Beide Upstreams werden immer parallel angefragt damit's schneller geht. * DHCPv4-Server * Es somd Ranges, keine Subnetze konfiguriert, weil im selben `/16` mehrere DHCP-Servern (mit unterschiedlichen Ranges) betrieben werden. * Jeder Supernode teilt Adressen aus einem anderen Range aus, die aber alle im selben `/16` liegen. Es laufen also vier DHCP-Server im selben Pseudo-Layer2 des Meshs. Damit ist es möglich, zwischen Nodes zu roamen, die unterschiedliche Supernodes nutzen. Falls man vom Node wegroamt auf einen Node, der mit einem anderen Supernode verbunden ist werden die Daten in B.A.T.M.A.N vom den Tunnel terminierenden weitergericht an den Supernode, der Default-Gatway für den Client ist. Das geschieht transparent in B.A.T.M.A.N.'s' "Layer 2". * Alle Interfaces, von denen clients kommen sind in `Snsmasq` kofiguriert, weil die `bat0` keine transparente Bridge ist. * Lease Time steht im Ruhrgebiet auf fünf Minuten, können wir im kleineren Dortmund-Mesh aber wieder auf zwei Stunden setzen. #### radvd [radvd](http://www.litech.org/radvd/) * Kündigt IPv6 Prefix und Router an. 3 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... * Die Intervalle weichen vom Standard ab, sonst ist nichts besonderes konfiguriert. * Einige Communities teilen `fe80::1` als Gateway aus, wir teilen die normale Link-Local Adresse des Interfaces aus. * ToDo: Best Practices überprüfen und ggf. einsetzen. * RDNSS Es müssen nicht zwingend auf allen Supernodes `radvd` und ein DHCP-Server laufen, im Ruhrgebiet gibt's nur zwei RA/DHCP-Server. Alle DHCP und RA laufen im selben Layer 2. Die RAs anderer Supernodes werden durch `ebtables` gefiltert, somit gelangen nur die RAs vom verbundenen Supernode durchs VPN zum Node. Auf DHCP-Requests antworten aber alle DHCP-Server (???). #### BIRD [BIRD](http://bird.network.cz/) * bird für IPv4 und bird6 für IPv6 sind zwei unterschiedliche Prozesse mit jeweils eigenen Konfigurationsdateien. * BIRD kann alternative Routingtabellen für Policy-Based Routing, Quagga nicht. Deshalb BIRD. * BIRD arbeitet *nur* auf der Routing-Tabelle 42. * Alle Supernodes untereinander und mit dem Mapserver haben BGP-Sessions. * Es wird nicht immer automatisch die optimale Route gewählt, bei Performance-Problemen Routing checken. * Prioritäten (aufgeschnappt, ToDo: Richtig dokumentieren.) * prefer routes with the highest local preference attribute * ...shortest as path * ...igp origin over ... intern/extern oder pfad kaputt intern vor extern, extern vor kaputt * Keine Full-Table auf den Supernodes, deshalb werden Daten nicht unbedingt zum idealen Backbone-Router geschickt. Das Backbone schiebt die Daten in dem Fall zum richtigen Router. Erklärungen zur Konfigurationdatei: * `template bgp ibgp`: "ibgp" ist hier nur der Name des Templates und hat sonst keine Bedeutung. * Namen dürfen keine Bindestriche enthalten, das mag BIRD nicht. ### Interfaces * Die MAC-Adressen von `bat0`, `tap0` und `tap1` sind manuell gesetzt, da die FFMAP statische Mac-Adressen für die Anzeige der Supernodes benötigt. #### eth0 * Hostinterface * P2P-Route gesetzt, keine Default-Route (?) #### br-ffrg Brücke in die Domäne, die einen `gretap`-Tunnel zu den Routern aufbaut. Hier laufen BIRD's BGP-Sessions zu den Routern. 4 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... #### br0 Bridge, an die `bat0` gehängt ist. Hierüber wird vom Host mit dem Mesh kommuniziert. #### bat0 B.A.T.M.A.N-Interface. #### tap0 L2-Fastd-VPN von den Nodes. Nimmt an B.A.T.M.A.N. teil. ### tap1 L2-Fastd-VPN zwischen allen Dortmunder Supernodes + Map-Server. ### eth1 `eth1` war ein über VMWare realisiertes Layer 2 zwischen unseren Supernodes und sollte die Funktionalität das Backbone-Fastd ersetzen. Das hat aber nicht korrekt funktioniert (Paketverlust), so dass die Idee fallen gelassen wurde. Das Interface ist noch da, kann aber ignoriert werden. ### Routing Es wird Policy-Based Routing verwendet. Sämtlicher Traffic von Interfaces die am Mesh teilnehmen wird auf die Table 42 gezogen, die das Routing innerhalb des FFRL-Netzes enthält. Die Default-Routingtable wird nur für die Konnektivität des Supernodes nach außen verwendet. Das Policy-Routing ist teilweise doppelt und dreifach eingetragen und wird über die `on up`-Anweisung der Backbone-Instanz von Fastd eingerichtet. Es hat aber wohl öfters Probleme gegeben, dass Pakete nicht richig erfasst wurden, deshalb sind jetzt ggf. redundante Regeln vorhanden. ### Adressen Das hier dokumentierte Schema wird derzeit in FF Ruhr umgesetzt. #### MAC-Adressen * ToDo: Manuell konfigurierte Macs. * tap1 steht im Dokument, tap0 und bat0 sind abgeleitet. #### IP-Adressen **To be documented** * Die IPv6-Adresse eines Interfaces endet mit dem vorletzten Oketet der IPv4-Adresse auf dem selben Interface. ### iptables / ebtables * Im PREROUTING werden Pakete von Mesh-Interfaces markiert um auf die Routing-Tabelle 42 gelegt zu werden. * Im POSTROUTING wird MSS-Clamping auf die MTU betrieben. 5 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... * Eigentlich wollen wir ja nicht an den Paketen rumdoktorn und es sollte das Problem der Gegenseite sein, aber wenn Facebook nicht geht sind die Leute auch nicht glücklich oder so... * ebtables droppt durchfliegede RAs auf `bat0` ### Systemeinstellungen * Hauptsächlich einige wichtige `systctl`-Einstellungen, to be documented. ## Map-Server * Es gibt ein neueres `ffmap`-Backend, mit dem aber die merging/filtering-Scripte nicht laufen. * Neues Backend gibt die Daten in `nodes.json` und `graph.json` getrennt aus. * `alfred`-Master ist nur der Mapserver, es gibt Probleme wenn im Mesh ein weiterer Master gestartet wird. * Konfiguration in `/etc/ffmap` ## Zukünftige Entwicklung / TODOs ### Kurzfristig #### Bereitzustellende Dienste * NTP: Es können auch externe NTP-Server im DHCP angegeben werden, aber selbst auf den Supernodes NTPDs zu betreiben dürfte am günstigsten sein. * Neue Version von B.A.T.M.A.N. * Momentan wird eine Legacy-Version verwendet, es kann eine neue Version genutzt werden, wenn diese im "Kompatibilitätsmodus 14" laufen kann. #### Härtung Es sind überflüssige/ungenutzte Pakete und Komponenten auf den Supernodes installiert. Diese sollten überprüft und entfernt werden. U.a. habe ich bei kurzer Durchsicht gefunden: * Exim, auf Loopback gebunden * Nginx und PHP, ohne Funktion * RPCBIND etc. sind aktiv, obwohl kein NFS genutzt wird. ### Mittelfristig & Langfristig Wir können komplette Supernode-Cluster z.B. über GRE-Tunnel und BGP an unsere produktiven Supernodes anbinden und ihnen somit Zugang zum Freifunk-Netz geben. Damit können wir z.B. Neuentwicklungen als Sandbox aufsetzen und sie technisch wie eine Domäne als "Subdomäne" betreiben. Es muss also nicht in der Produktivumgebung experimentiert werden. Auch können einzelne Supernodes, die am B.A.T.M.A.N. teilehmen aber keinen eigenen Uplink ins Backbone haben problemlos angeschlossen werden. Diese dürfen aber in B.A.T.M.A.N. nicht als Gateway konfiguriert werden. *Anmerkung:* Hier habe ich (Markus) meine subjektive Meinung notiert, bitte beliebig ergänzen / wiedersprechen / diskutieren, es ist sicher nicht vollständig... 6 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... #### Monitoring Es gibt keinerlei Monitoring, sowohl was Alarmierung als auch Metriken angeht. Graphen zum anstarren fänden auch andere Communities interessant, es gibt aber zumindest in FFRUHR momentan noch nichts. Mögliche Buzzwords: * [InfluxDB](http://influxdb.com/) und [Grafana](http://grafana.org/) * [Prometheus](http://prometheus.io/) * [Check_MK](https://mathias-kettner.de/check_mk.html) #### Neuaufbau / Formalisierung Ein Neuaufbau auf Debian 8 und mit Ansible formalisiert ist geplant. #### Überprüfung / Tausch von genutzten Komponenten Bitte immer auf das Prinzip Datensparsamkeit achten. `dnsmasq` ist z.B. so konfiguriert, dass es von DHCP-Clients mitgesendete Client-Namen nicht loggt. * DNS und DHCP für die Supernodes werden über `dnsmasq` bereitgestellt. * Nutzung von [Unbound](https://www.unbound.net/), [PowerDNS] (https://www.powerdns.com/) o.ä. als Cachender DNS-Resolver * DHCP durch ISC-DHCPD? Weiterhin dnsmasq? * Einige Dienste und Netzwerk-Konfiguratonsschritte werden durch Scripte von Fastd getriggert gestartet. Dies ist weitgehend nicht mehr notwendig * Überführung der Netzwerkkonfiguration (sofern möglich) zu `systemd-networkd` * Abbildung der gesamten Abhängigkeitsstruktur zwischen Diensten, Interfaces und dynamisch getriggerten Konfigurationsschritten durch Systemd-Units anstatt an verschiedenen Stellen z.B. durch Fastd getriggerte Scripte. * Bereinigung von `/etc/sysctl.conf`, Freifunk-spezifische Settings nach `/etc/sysctl.d/` * Einige Sysctl-Settings werden durch Scripte gesetzt, diese ebenfalls beachten. ### Research-Themen #### Skalierung von Fastd Fastd kann nur auf einer CPU rechnen. Dies ist der limitierende Faktor bei der Skalierung von Supernodes. Momentan wird skaliert, indem mehr (virtuelle) Supernodes auf der selben Hardware betrieben werden. Es könnte aber auch versucht werden, mehrere Fastd-Prozesse (Anzahl der Kerne) auf unterschiedlichen Ports eingesetzt werden und in die Clients konfiguriert werden um vorhandene Ressourcen besser zu nutzen. #### Technologie für Transfernetz zwischen den Supernodes Alle Supernodes der Community untereinander benötigen ein geteiltes L2-Netz. Um dieses über die Server-Standorte zu realisieren wird momentan eine Fastd-Instanz ("Backbone") ohne Verschlüsselung genutzt, die ein M:N-Netz zwischen unseren Supernodes darstellt. Ggf. kann man hier eine modernere, im Kernel implementierte Technik verwenden (Mögliche Buzzwords: Gretap? Open vSwitch? VXLAN?). Schwierigkeit ist, dass die Supernodes auf verschiedene Hostern/RZs verteilt sind und das virtuelle Layer 2-Netz ohne SPOF auskommen 7 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... sollte. ## Ressourcen bei Freifunk Dortmund Hier sind die Dortmund-spezifischen Ressourcen dokumentiert. ### Zugeteilte Adressen / ASNs Die gesamten Supernodes von FFRUHR sind in einem [Google Docs-Spreadsheet] (https://docs.google.com/spreadsheets/d/1PQnZoToxBJaIL38fFZGFNMa4r57MwbOX6hXI_RwdQIw /edit#gid=1364818031) von Chris dokumentiert. Die Infos aller Communities dort sind als verbindlich anzusehen und werden laufend aktualisiert. ### DNS | Domain | Registrant | |----------------------|---------------| | freifunk-dortmund.de | Sven B. | | ffdo.de | Tim F. | *Vorschlag*: Wir sollten die Nutzung der beiden Domains grob unterteilen in "Auftritt" und "Infrastruktur". Für den öffentlichen Auftritt `freifunk-dortmund.de` nutzen, für die Infrastruktur wie Supernodes und Server `ffdo.de` nutzen. Dabei darauf achten, dass ### Supernodes Momentan haben die Supernodes DNS-Einträge unter `do.node.freifunk.ruhr`. Das dort vergebene Hostnamen-Schema ist historisch so gewachsen, hat aber keine technische Relevanz mehr. Wir können auch nach Belieben ein anderes Schema einführen. *Vorschlag:* Um das Schema zu vereinfachen die Nodes flach durchnummerieren und unter `ffdo.de` ansiedeln. Beispiel für mögliche Benennung: `sn1.nodes.ffdo.de`, `sn2.nodes.ffdo.de` etc. | alter Name | neuer Name | |---------------------------|--------------| | node01-1.do.freifunk.ruhr | *t.b.d.* | | node02-1.do.freifunk.ruhr | *t.b.d.* | | node01-2.do.freifunk.ruhr | *t.b.d.* | | node02-1.do.freifunk.ruhr | *t.b.d.* | #### System-Login Login ist nur mittels SSH-Keys möglich. Momentan mússen sich die berechtigten Personen als `root` einloggen. *Vorschlag:* Umstellung auf personalisierte Accounts mit `sudo`-Berechtigung. ### MAP-Server Die Communities mit eigenen Supernodes müssen auch eigene Mapserver betreiben. Die Aggregation in die große Ruhrgebietskarte ist noch WiP. Das heißt, stand Jetzt fallen die Communities, die eigene Supernodes bekommen haben aus der Ruhrgebietskarte raus. Bitte 8 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... nicht drüber im Forum beschweren, ist momentan so. An der Map-Software wird von verschiedenen seiten Entwickelt. | alter Name | neuer Name | |---------------------------|-------------------------| | map.do.freifunk.ruhr | map.ffdo.de (Vorschlag) | ### Firmware-Server Momentan werden alle über den Auto-Updater angebotenen Community-Firmwares der Domäne Ruhrgebiet zentral von Philip Berndroth gebaut. Der Firmware-Server http://images.ffdo.de zeigt auf Philip's Firmware-Repository unter `82.207.138.32`. Dieses wird automatisch von seinem Buildsystem befüllt. ### Statistiken Unter http://status.ffdo.de wird eine Visualisierung der Map-Daten erzeugt. Dies geschieht von/auf Systemen von Tim F. ### Homepage Die offizielle Homepage wird vom wird vom Wissenschaftsladen Dortmund e.V. / free.de gehostet und ist unter http://www.freifunk-dortmund.de/ erreichbar. Ebenso sind alle offiziellen Email-Adressen unter `@freifunk-dortmund.de` angelegt und bei free.de gehostet. ### Mailinglisten * Allgemein: https://list.free.de/listinfo/freifunk-do * Infrastruktur: https://list.free.de/listinfo/freifunk-do-infra * Bitte nur Themen, die sich um die Server/Netzwerk-Infrastruktur drehen. ### Orga-Redmine Unter https://orga.ffdo.regulus.uberspace.de/ wird von Ulf M. eine Redmine-Instanz zur Koordination von Rollout-Projekten betrieben. ### FF Dortmund Wiki Unter https://mesh-j-1.free.de/~freifunk/wiki/ läuft ein von Petra eingerichtetes, dezentral mit [Gitit](http://gitit.net/) gehostetes Wiki. Backup-Instanzen des selben Wikis: * https://mesh-j-2.free.de/~freifunk/wiki/ * https://mesh-j-3.free.de/~freifunk/wiki/ ### Wiki-Seite Im Freifunk-Wiki unter http://wiki.freifunk.net/Dortmund wird bisher Ad Hoc die Koordination von Terminen für Freifunk Dortmund bekanntgegeben. ### GitHub Wir haben eine Organisation unter https://github.com/ffdo 9 von 11 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... ## Externe Ressourcen ### Ansprechpartner #### FF Ruhrgebiet Philip B. & Chris B. #### Entwickler * Fastd: Matthias/Neoraider, FF Lübeck * Gluon/FFMAP/FFMAP-3D: Nils/tcatm, FF Lübeck ### Kommunikationskanäle FFRL/FFRUHR * * * * Freifunk-Forum: https://forum.freifunk.net/ Mumble: `mumble.ffrl.de` IRC: `#ffruhr` @ [freenode](https://freenode.net/) Facebook-Gruppe für Supernode-Admins Ruhrgebiet (ja, sowas gibt's wirklich...) ### GitHub * https://github.com/ffruhr/ * https://github.com/ffruhr/site-ffdo/blob/master/site.conf ## Zukünftige Entwicklung Von Chris gab's folgende noch inoffizielle Info zur momentanen Entwicklung bei Gluon: Eine neue, in Entwicklung befindliche Gluon-Version baut auf eine geänderte Netzwerkstruktur. Im VPN soll von Layer 2 auf Layer 3 umgestellt werden, so dass die vorhandenen Skalierungsprobleme verschwinden. * Fastd soll von `tun` auf `tap` umgestellt werden. * Nodes machen selbst DHCP-Server, die Ranges werden über ein [neues Protokoll] (https://gist.github.com/tcatm/2dd0e6699f2a153505d0) von den Supernodes ausgegeben. * Das Mesh wird auf OLSR umgestellt, B.A.T.M.A.N. wird nicht mehr verwendet. * Das gesamte Netz wird IPv6-only, IPv4-Zugang wird über IPv6 getunnelt. Als Zeitrahmen wird eine Realisierung bis Q4/2015 angestrebt. -Liste zur Infrastruktur der Dortmunder Freifunk community Listenadresse: [email protected] Abo verwalten: https://list.free.de/listinfo/freifunk-do-infra Anhänge: supernodes.md 10 von 11 20,4 KB 09.05.2015 20:56 [freifunk-do-infra] Dokumentation übergabesessi... signature.asc 11 von 11 473 Bytes 09.05.2015 20:56
© Copyright 2024 ExpyDoc
