Gibt es einen besonderen Grund warum ihr KEA mit dem Postgres-Backend und nicht mit Memfile verwendet?
Falls(!) ich die KEA-Doku richtig verstehe wäre Memfile schneller obwohl es die Leases ganz normal auf Platte schreibt, und ein Datenbank-Backend sei dann interessant, wenn man mehrere DHCP-Server für den gleichen IP-Adressbereich betreibt und dann die Postgres-Datenbanken synchronisiert. Was bei euch ja nicht der Fall ist.
Dann noch eine Frage zur Lease-Time:
Wir in Ingolstadt verwenden, wohl aus Tradition, eine sehr kurze Lease Time von 5 Minuten, ihr seid auf 24 Stunden hochgegangen. Die Frage nach der optimalen Lease-Time wurde im Freifunk-Forum vor ein paar Jahren diskutiert, jedoch scheinbar ohne abschließendes Ergebnis. Was hat euch dazu bewogen? Haben sich die 24 Stunden bewährt?
In unserer Community gibt’s grad Überlegungen, keinen extra internen Domänennamen mehr zu vergeben, sondern überall nur den externen. Ich hab mir deswegen mal angesehen was wo in Ansible als Domainname benutzt wird:
„freifunk.domain“ ist der Name der externen Domäne („freifunk-musterstadt.de“). Das scheint immer und überall zu gelten.
Dann gibt’s noch:
„dhcp_global.domain_search“ (in gateways_dhcp)
was wohl gleichbedeutend ist mit
„kea.global.search_domain“ (aus gateways_key_configure), das bei euch verweist auf die Variable
„freifunk.search_domain“
das wiederum den selben Wert hat wie
„freifunk.kurzname“ (wird in gateways_bind/dienste_bind benutzt)
und der Name der intern verwendeten Domäne ist („ffms“ <- Musterstadt, nicht Münster…)
Kommt das ungefähr hin?
es gab damals Bedenken, dass es Konflikte gibt, falls mal ein Gateway neu gestartet wird. In der Zeit, aus der der Code stammt, hat sich Batman noch regelmäßig auf die Nase gelegt.
Zumindest damals hatten viele Android-Telefone im Standby die Leases nicht erneuert und waren dann offline, ohne es zu merken.
Wenn man viel durch die Luft mescht, ist DHCP auch ein wunder Punkt.
Ne, ffms steht für Freifunk Münster. MS ist das Autokennzeichen von Münster und .ms als TLD ist hier auch unter Nerds ganz beliebt. Die Verallgemeinerung ist freifunk.kurzname. Die Variable kann man für andere Communities anders setzen.
Wir nutzen eigentlich nur knoten.ffms, um zu prüfen, an welchem Knoten man hängt. Das geht nicht mit einer öffentlichen Domain, weil das je nach Quell-IP anders aufgelöst werden muss, weil es in jeder Domäne ein anderer A/AAAA ist.
Dieser ganze restliche interne Domain-Quatsch könnte eigentlich weg. Das verkompliziert die Sache nur. Niemand aus dem Team hier benutzt das meines Wissens nach.
Die Searchdomain braucht man im Kea bzw. DHCP-Server, damit Unifi-Geräte mit Originalfirmware den von uns betriebenen Unifi-Controller finden. Die suchen von sich aus nach unifi.searchdomain. Aber auch das könnte man mit einer öffentlichen Domain realisieren.
Das etwas undurchsichtige ist, dass wir nicht verstanden haben, wie man Bind verschiedene Zonen je nach Quell-IP zurückgeben lässt.
Daher wird .ffms auch nicht vom DNS-Master sondern von den Gateways aufgelöst.
Ich kann nicht für Münsterland sprechen, aber bei uns (Nachbarkreis) sind Ubuntu 16.04 und 18.04 im Einsatz (wobei Neuinstallationen, und nur da käme Ansible statt Puppet zum tragen, nur noch mit 18.04 geschehen).
Das war geht und funktioniert, kann man noch für 16.04 drinlassen. Alles, was man jetzt an Code neu baut, muss nur zu 18.04 passen. 16.04 ist doch schon arg abgegangen inzwischen. Bald kommt schon 20.04.
Wegen Canonicals Irrwegen mit Snap und Netplan sind wir aber gerade wieder voll auf Debian umgeschwenkt.
FTR, da wir aktuell auf das Münsteraner Ansible setzen: Snap kann man IMHO noch ignorieren, netplan ist aber no-go (daher bei uns auch 18.04 einzig als Upgrade von 16.04 mit deinstalliertem netplan.io), insofern wird es bei uns im Nachbarkreis Gütersloh eher keine Ubuntu-VMs neuer als 18.04 LTS geben – Ausnahme: Ubuntu rudert in 20.04 LTS wieder mal zurück – und zukünftig wieder mehr auf Basis von Debian 10+ gebaut.
Wir benutzen in Ingolstadt zwar durchgehend Debian 10, aber wie der Zufall so spielt hab ich heute Vormittag einen entsprechenden Pull Request zu dem Thema gestellt
