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. done

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, 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 batman-adv teilehmen aber keinen eigenen Uplink ins Backbone haben problemlos angeschlossen werden. Diese dürfen aber in batman-adv 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…

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, PowerDNS o.ä. als Cachender DNS-Resolver
  • DHCP durch ISC-DHCPD? Weiterhin dnsmasq?
  • done es wird Unbound benutzt.
• 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.

done Auf Port 10000 und 10001 läuft jeweils eine Fastd-Instanz für die Clients

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 die Fastd-Instanz backbone ohne Verschlüsselung genutzt, die ein M:N-Netz zwischen unseren Supernodes darstellt.

Ggf. kann man hier zukünftig auf vxlan setzen. Dabei wird kein statischer Peer oder Mulitcast-Gruppe angegeben, sondern die Peers explizit mit bridge fdb add in die Forwarding-DB des virtuellen Switches eingetragen. Es muss die IP-Adresse sowie MAC-Adresse jedes Peers bekannt sein.

Umbenennung der Nodes

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.