map.ffrn.de sollte sich nun ohne große Bedenken neustarten lassen. Vorher kam ein Netzwerkinterface nicht richtig hoch, da es nicht in der richtigen Reihenfolge gestartet wurde.
Nun wird sollte durch folgendes sichergestellt sein, das die ffrn-br vor dem ffrn-bat Interface gestartet wird und der brctl Befehl nicht mehr fehlschlägt, da die ffrn-br noch nicht gestartet wurde.
Okay, ganz schön ist die Lösung nicht, da aktuell dann trotzdem Fehler im Log stehen (es wird zweimal versucht die ffrn-br zu starten), aber immerhin funktioniert es so nun scheinbar.
Die Gateways geben nun korrekt auf der Karte wieder, das sie der FFRN Domain angehören. Das ist möglich durch eine Änderung bei mesh-announce (dem repsondd Client für beispielsweise Gateways).
Wir haben in den letzten Tagen und Wochen vermehrt Abusemitteilungen von Hetzner bekommen aufgrund wiederholter Netscans, die von Freifunknutzern ausgingen. Das Protokoll ist überwiegend UDP und es werden zufällige(?) Ports > 50000 als Ziel verwendet.
Daher haben wir momentan UDP Zielport 56093 auf allen Gateways gesperrt. Das ist der momentan verwendete Port und sollte für den normalen Netzbetrieb keinen Einfluss haben, auf Dauer müssen wir uns aber noch was überlegen.
Weiterhin läuft jetzt auf allen Gateways chrony statt ntpd als Zeitserver. Dieser wird ohnehin nur für die Zeitsynchronisierung der Gateway-VMs verwendet. Die Nodes verwenden 1.ntp.ffrn.de, welcher aber schon seit längerem „powered by chrony“ ist. Der Grund: ntpd bietet zwar tolle Funktionalität, die wir aber nicht brauchen. Sicherheit und Funktionalität geht vor, siehe https://www.coreinfrastructure.org/blogs/securing-network-time/
Morgen wird wohl der letzte Tag von unserem vmhost vm03.ffrn.de (Wiki Eintrag) sein. Es wurden alle VMs abgeschaltet und die Dienste auf die anderen Server migriert. Durch das Firmwareupdate sind wir nun auch nicht mehr auf das /64 aus dessen Bereich eine der hartkodierten IPv6 von einem der DNS Resolver stammte angewiesen. Das war die letze Sache die da noch fehlte für die Kündigung.
Wir tauchen übrigens nun auf der freifunk-karte.de auf. Ich musste länger rätseln warum das nicht klappte, aber der Grund war, das im Freifunk API File die Knotendaten im falschen Format verlinkt waren. Das habe ich gestern Abend angepasst, und nun klappt es.
Ich habe die DMARC Records der Domains ffrn.de und freifunk-rhein-neckar.de mal auf reject gestellt.
Ich gehe zwar eigentlich nicht davon aus das es zu Problemen kommen wird, aber meldet euch bitte wenn dem doch so wäre.
Dann habe ich mal die Delegierung der Zone rhein-neckar.freifunk.net angefragt und eine Weiterleitung auf unsere Webseite eingerichtet.
Und dann habe ich noch für die meisten Domains und Subdomains eine security.txt hinterlegt. Das ist zwar noch kein Standard, wurde aber als solcher vorgeschlagen und scheint mir eine sinnvolle Sache zu sein.
Und es haben auch durchaus schon ein paar Größere Unternehmen wie Google adaptiert.
Über Nacht wurde tickets.ffrn.de auf Debian 10 geupdated sowie stats.ffrn.de auf Debian 9 und dann 10. Bei der Umstellung auf 10 hat es ein paar Probleme bei graphite gegeben. Zwecks einfacherer Handhabung durch die vielen Pfade wird gerade auf Docker umgestellt, daher kann es kurzfristige Ausfälle bei den Stats geben.
Edit: Ich musste ein Rollback von dem Statsserver machen und probiere es jetzt erneut. Ziel ist weiterhin in Zukunft Dockercontainer zu nutzen.
Edit2: Nach ein paar Versuchen läuft jetzt endlich Debian 10 und die Daten kommen noch an. Es scheint einiges an versteckten Abhängigkeiten zu geben, so dass ein Entfernen nicht benötigter Pakete nach dem Update bereits die Datensammlung verhindert. Damit das in Zukunft nicht passiert, soll wie geplant auf Docker umgestellt werden. Immerhin haben wir jetzt eine Basis zum Experimentieren. TLS 1.3 für stats.ffrn.de folgt morgen.
Edit3: Ich bastel noch, da Punkt Mitternacht die Datensammlung am 9.4. aufgehört hat ohne ersichtlichen Grund. In Zukunft wird Influxdb zum Einsatz kommen, später mehr.
Seit gut einem Jahr liefen die FFRN Domains auf den Nameservern von Hetznern (nachdem sie wohl vorher auf Leahs liefen). Diese Dienstleistung von Hetzner kostete bislang 0,59 € pro Domain und Jahr. Dafür bekam man ein einfaches E-Mail Interface an welches man die PGP signierten Änderungen schicken konnte und ein Formular in deren Verwaltungsoberfläche, welches diese E-Mail Schnittstelle bediente.
Das hat sich nun mit deren neuer DNS Console geändert. Nun ist die Dienstleistung (ohne Ankündigung an die zahlenden Kunden ). Als bisheriger Kunde wurde man auch umgestellt und muss immerhin nicht mehr zahlen, musste sich aber eben auch mit den Startschwierigkeiten (siehe Twitter, welche meines Erachtens nach wie vor nicht komplett behoben sind), herumärgern.
Lange Rede, kurzer Sinn: während ich die Neuerungen grundsätzlich begrüße hat es mich so sehr genervt, das die Domains nun von eigenen Nameservern (auf denen Knot läuft) bedient werden.
Das war zwar perspektivisch eh von mir angedacht, aber das wurde nun etwas beschleunigt.
Die Änderung hat aber auch den Hintergrund den Domain Registrar zu wechseln (aktuell Hetzner) um die Zonen ffrn.de und freifunk-rhein-neckar.de künftig per DNSSEC signieren zu können, was bei Hetzner nicht möglich ist, da sich dort der Public Key für Domains nicht hinterlegen lässt.
Ich habe nun die letzten Tage ein paar Reports bekommen, das Mails abglehnt wurde, da sie von den falschen IPs kamen (SPF) und zusätzlich die DKIM Signatur im Header nicht passte. Das würde ich mal als Erfolg bewerten. Die IPs, welche in diesen DMARC Reports aufgelistet wurden, stehen auch nicht im Bezug zum FFRN. Das waren also keine False Positives.
Ich habe vor etwa einer Stunde den VM Host altneckar.ffrn.de (Wiki) neugestartet. Darauf laufen dieses Forum, die Karte und ein paar GWs. Das hatte den etwa 25 minütigen Ausfall von diesen Sachen zur Folge. Die anderen GWs waren dadurch nicht beeinträchtigt. Grund für die ganze Aktion war, das sich, nachdem ich map.ffrn.de heruntergefahren hatte, diese VM nicht mehr starten ließ, da libvirt nicht mehr geantwortet hat. Und da die Kiste eh einen Reboot brauchte, habe ich das dann gemacht.
Edit: map.ffrn.de wird nochmal ausfallen, da dort noch Debian 10 installiert werden soll
Das Nodedashboard auf stats.ffrn.de wurde auf NodeIDs umgestellt statt Hostnames. Dadurch funktioniert jetzt die Anzeige auf map.ffrn.de auch für Nodes mit Sonder- oder Leerzeichen.
Konzeptbedingt ist es allerdings nicht möglich, sich die Stats von mehreren Nodes gleichzeitig anzeigen zu lassen. Wenn ich da doch noch eine Möglichkeit finde (oder ihr eine Idee habt), setze ich es um.
Wenn jemand Lust hat Dashboards in Grafana zu erstellen, dann wäre es sicherlich auch kein Problem demjenigen einen Account im Grafana zu erstellen. Meldet euch einfach
Das VPS auf dem stats.ffrn.de (Wiki) läuft wurde auf den aktuellen Tarif umgestellt. Das machte eine Neuinstallation des Servers nötig, da ein Umzug des existierenden Servers extra gekostet hätte. Doch durch die Vorarbeiten von @JevermeisteR (Grafana läuft seitdem in einem docker-compose Setup) und durch die Hilfe von Saltstack, war der neue Server zum Glück sehr schnell eingerichtet. So schnell, das ich für die Zeit des Umzuges Grafana in einer VM auf itter.ffrn.de (Wiki) laufen lassen konnte und es dadurch zu keinem allzu langen Ausfall kam.
Nun läuft stats.ffrn.de aber wieder auf dem externen Server und das Monitoring funktioniert dadurch wieder unabhängig von den 3 Hetzner Servern.
Unabhängig davon war ich aber doch etwas verwundert, das bei dem Anbieter IPv6 im Jahre 2020 nicht standardmäßig aktiviert ist. Das Leute IPv6 abschalten, ja mag vorkommen, auch wenn das wohl der falsche Weg ist. Aber das man es erst aktivieren muss, definitiv interessant.
Naja, wir beim FFRN überlegen jedenfalls eifrig, ob wir nicht die ersten sein wollen, die IPv4+ einführen.
Ich habe gerade mal in der nginx Konfiguration von fw.gluon.ffrn.de ein geo Konstrukt hinterlegt.
Damit ist es möglich eine Variable basierend auf der IP Adresse des anfragenden Clients zu setzten. Dadurch ist es nun möglich die IPv6 Addressen von Freifunk Routern auf eine Liste zu setzen und diese auf eine andere Firmware Seite umzuleiten.
Dies ermöglicht es nun Knoten welche länger nicht am Netz waren und welche daher die Firmware Signatur von uns neuen Admins nicht hinterlegt haben trotzdem auf die aktuelle Firmware zu updaten. Diese bekommen dann erst die 1.2.3-20191229 (welche von @NurticVibe signiert worden ist) und dann die aktuelle.
Wir haben da aktuell zwar keine Verbindung, aber falls das doch noch mal wieder verbunden werden soll ist es sicherlich besser, wenn die Daten halbwegs aktuell sind.
). Als bisheriger Kunde wurde man auch umgestellt und muss immerhin nicht mehr zahlen, musste sich aber eben auch mit den Startschwierigkeiten (siehe Twitter, welche meines Erachtens nach wie vor nicht komplett behoben sind), herumärgern.
