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 
2 „Gefällt mir“
Es liegt eine neue nightly (1.4.x-20200503 - buildinfo) auf Basis von Gluon v2020.1.2 auf den Servern bereit.
2 „Gefällt mir“
Das Forum wurde gerade auf die Version 2.4.3 aktualisiert.
1 „Gefällt mir“
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. 
4 „Gefällt mir“
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.
Wenigstens ist das der Plan.
Edit: Scheint zu funktionieren.
3 „Gefällt mir“
Da ich gerade das icvpn-meta Repository gefunden habe, habe ich gerade mal einen Pull Request erstellt um die Rhein-Neckar Daten zu updaten: https://github.com/freifunk/icvpn-meta/pull/603
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.
2 „Gefällt mir“
Der sync zwischen den authoritativen Nameservern (ns1.ffrn.de, ns2.ffrn.de und ns3.ffrn.de) wird nun per TSIG authentifiziert.
Seit heute Nacht setzen wir nun knot-resolver auf resolver1.ffrn.de und resolver2.ffrn.de ein. (Ein Resolver wird auch gerne allgemein „DNS Server“ genannt).
Bisher war es so, das der per DHCP verteilte „v4-resolver“ ein bind auf jedem der Gateways war. Die per Router Advertisement (IPv6) verteilen Resolver waren auch vorher schon resolver{1…2}.ffrn.de.
Da IPv6 sowieso bevorzugt wird sollte das eigentlich, bis auf die ganz paar Geräte die kein IPv6 können (wobei man mit denen vermutlich eh nicht in einem öffentlichen WLAN unterwegs sein sollte (da veraltet)), keinen Unterschied machen.
Die hauptsächliche Neuerung ist das wir nun DNSSEC überall strikt prüfen. Das bedeutet, das wenn der Eintrag nicht passt die resolver keine IP zurückliefern. Das ist aber nur relevant, wenn es einen DNSSEC Eintrag für die Domain gibt.
Beobachten kann man das ganz aktuell (wie @JevermeisteR festgestellt hat) auf cve.mitre.org. (Edit: Der Fehler wurde nun wohl behoben,)
1 „Gefällt mir“
Nachdem chat.ffrn.de nicht mehr funktionierte stellte sich heraus, dass das mit der Umstellung auf direkte nftables Regeln (Debian 10 schreibt in der Standardeinstellung alle iptables Regeln zu nftables Regeln um) auf dem Host tools-itter.ffrn.de zu tun hatte. Beim Starten des RocketChat Docker Containers mittels docker-compose up -d bekam man einen wie folgend aussehenden Fehler:
ERROR: for rocketchat Cannot start service rocketchat: driver failed programming external connectivity on endpoint rocketchat_rocketchat_1 (xxxxxxxxxxxxxxxxxxxxxxxxxxxxx): (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 127.0.0.1 --dport 3002 -j DNAT --to-destination 172.18.0.2:3000 ! -i br-4905ae49b518: iptables v1.8.2 (nf_tables): Chain 'DOCKER' does not exist
Es stellte sich heraus, das ein systemctl restart docker hier Abhilfe schaffen konnte.
1 „Gefällt mir“
Früher wurde collectd im Zusammenhang mit Graphite genutzt um ein paar Metriken zu sammeln. Doch da der Graphite Server nicht mehr verfügbar war führte das dazu das die Server beispielsweise bei Reboots erst in einen 90 Sekunden Timeout laufen mussten.
Nachdem ich auf den VM Hosts und den Gateways den Service neulich bereits deaktiviert und gestoppt hatte, habe ich nun gestern festgestellt gehabt, das auf v6upstream.ffrn.de dieser noch lief und sämtlichen RAM gefressen hatte.
Daher habe ich mittels salt '*' service.status collectd.service geprüft ob der sonst noch irgendwo läuft. Und wie sich herrausstellte lief er auch noch auf map.ffrn.de. Dort wurde er also in beiden VMs deaktiviert und gestoppt.
Leider ist v6upstream bisher nicht im Monitoring was Server Ressourcen angeht. Das werde ich nachholen. So kann ich leider nicht sagen wie lange da bereits aller RAM belegt war. Mein Eindruck war, das es keine grundsätzlichen Probleme mit IPv6 gegeben haben dürfte. Aber das ist nicht belegbar und es hat keine entsprechenden Tests gegeben.
Salt States
Inzwischen habe ich unsere Salt States mal veröffentlicht. Was da nicht enthalten ist, sind die Pillars. Das ist ein privates Repository in welchem die Konfigurationsdaten gespeichert sind. Dort stehen dann zum Beispiel die Passwörter drin. Oder aber auch die jeweiligen Werte für einzelne Konfigurationsoptionen auf den unterschiedlichen Systemen.
Das ist aber noch stark in Arbeit. Nicht enthalten sind da also zum Beispiel die Gateway Konfigurationen.
map.ffrn.de
Ich habe hier die neueste Version des Meshviewers ausgerollt (über Salt)
Firmware
Ich habe eine neue nightly auf Basis von Gluon 2020.1.3 hochgeladen.
Bei stable sind wir aktuell ja noch bei 2019.1.2. Das wird sich auch nicht unmittelbar ändern, da der aktuelle Plan nicht vorsieht Tiny Geräte (also hauptsächlich Geräte mit 4 MB RAM und 32 MB Flash - beispielsweise die „beliebten“ TP-Link 841) auf Gluon 2020 zu updaten, da sie damit nicht gut laufen. Das wird sich aufgrund der Hardware Limitierungen wohl auch nicht ändern.
Daher ist der aktuelle „Plan“ Multidomain unter Gluon 2019 einzuführen und dann die „ordentlichen“ 
Geräte auf Gluon 2020 zu updaten.
Gluon 2019 wird wohl auch noch etwas Pflege (Updats) erhalten, da vor der Problematik mit den tiny Geräten einige stehen.
Der Unterschied zwischen Gluon 2019 und 2020 ist übrigens hauptsächlich die neuere OpenWrt Version bei 2020.
Ich würde also definitiv davon abraten neue Tiny Geräte zu kaufen und sich mal darüber Gedanken zu machen, wenn man noch ein solches Gerät einsetzt), eventuell auf ein „zeitgemäßes“ Modell zu updaten.
3 „Gefällt mir“
Es gab hier im Forum ein Problem das E-Mails nicht verschickt wurden und Push Benachrichtigungen gingen auch nicht raus. Sollte nun behoben sein. Hatte mit Änderungen in der Firewall zu tun. Da war Forwarding nicht richtig erlaubt.
1 „Gefällt mir“
Weiterhin gibt es ab heute für unseren Blog unter https://blog.ffrn.de eine Kommentarfunktion. Es werden automatisch Themen im Forum für jeden Blogeintrag erstellt. Das gilt auch für ältere Blogposts.
3 „Gefällt mir“
Ich habe gerade alle FFRN Systeme rebootet. Gab für Debian Kernel Updates.
Auf stats.ffrn.de kann man ganz schön sehen wie die Nodes dabei von Gateway zu Gateway wechseln mussten:
2 „Gefällt mir“
Ich plane übrigens aktuell die Abschaltung von chat.ffrn.de. Sobald es soweit ist wird es aber nochmal eine größere Nachricht geben. Wirklich genutzt wird das meines Wissens aber eh nicht.
Wir Admins nutzen aktuell Matrix für unsere Kommunikation. Und es wurden auch schon mal öffentliche Räume eingerichtet:
- #ffrn:ffrn.de (Allgemein)
- #technik:ffrn.de (Technik)
Wie das alles ganz genau aussehen soll ist auch noch nicht klar. Und auch ob Matrix wirklich die Antwort auf die Frage ist wie wir leichtgewichtigere Kommunikation innerhalb der Community ermöglichen können ist nicht geklärt.
Dazu gehört auch ob wir öffentliche Accounts bereitstellen wollenn, können, … Da gibt es noch viele ungeklärte Fragen.
Aber wer einen Matrix Account hat kann ja mal joinen.
Noch ein Kommentar zu Matrix Accounts:
Ich persönlich würde eher von matrix.org abraten. Einerseits aus ideologischer Sicht, da es sich nun mal um eine sehr zentrale Instanz handelt, andererseits aber auch, da es (wenigstens in letzter Zeit) nicht ganz so stabil zu funktionieren scheint. Aber eine direkte Empfehlung (außer selber hosten), habe ich aktuell leider auch nicht. Ich habe nur beim kurzen Googlen gerade diese Liste mit öffentlichen Matrix Servern gefunden. Aber ob da wirklich eine ordentliche Alternative dabei ist weiß ich auch nicht.
Über die in der security.txt hinterlegte E-Mail Addresse hat sich Gaurav Popalghat (LinkedIn Profil) bei uns gemeldet und darauf hingewiesen, das wir bisher sehr großzügig mit einigen Versionsinformationen der verwendeten Software waren.
Während ich nicht viel von „Security through Obscouruty“ halte, so mag es eben vielleicht doch helfen, da bei einer neu bekanntgewordenen Sicherheitslücke ein Angreifer (bei beschränkten Ressourcen) sich vielleicht erst auf die Ziele konzentriert welche in Versionsdatenbanken mit der betroffenen Version gelistet sind. Das ist aber natürlich (falls überhaupt) nur ein minimaler zeitlicher Vorteil.
Da uns jedocch aktuell keine Nachteile bekannt sind (also zum Beispiel Software welche die Versionsinformation dafür braucht um zu entscheiden ob ein Workarround angewendet werden muss oder nicht), habe ich die Infos für ssh, knot (autoritativer nameserver) und nginx (Webserver) mal etwas eingeschränkt.
Heute in der Früh (03:00 - 03:45) habe ich altneckar.ffrn.de (Wiki) auf Debian 10 geupdatet (von Debian 9). Es war eine sehr kurzfristige Entscheidung, daher gab es keine Ankündigung.
Die Auswirkungen sollten sich um die Uhrzeit aber auch in Grenzen gehalten haben. Dieses Forum, die Karte, resolver1, gw05, gw06 und gw08 waren währenddessen nicht erreichbar. Das Netz als solches sollte aber nicht wirklich beeinträchtigt gewesen sein.
2 „Gefällt mir“