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.
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.
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.
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.
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:
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.
Heute Nachmittag um 17:06 ist die Netzwerkverbindung auf altneckar.ffrn.de abgebrochen und das Teil war nicht mehr erreichbar. Um 18:02 habe ich einen manuellen Reset des Servers bei Hetzner beauftragt (manuell damit ein Techniker mal vor dem Neustart schaut ob da was auffälliges steht). Um 18:32 wurde der Reset dann durchgeführt und ich habe dann um 19:00 die VMs die dort laufen gestartet.
Ursache dürfte vermutlich ein Treiber/Firmware Problem mit der Netzwerkkarte zu sein.
Mal schauen ob und wie man das beheben kann.
Jun 17 15:56:25 altneckar kernel: [130799.804952] e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jun 17 15:56:25 altneckar kernel: [130799.804952] TDH <ad>
Jun 17 15:56:25 altneckar kernel: [130799.804952] TDT <9b>
Jun 17 15:56:25 altneckar kernel: [130799.804952] next_to_use <9b>
Jun 17 15:56:25 altneckar kernel: [130799.804952] next_to_clean <ad>
Jun 17 15:56:25 altneckar kernel: [130799.804952] buffer_info[next_to_clean]:
Jun 17 15:56:25 altneckar kernel: [130799.804952] time_stamp <101f1cc3d>
Jun 17 15:56:25 altneckar kernel: [130799.804952] next_to_watch <ae>
Jun 17 15:56:25 altneckar kernel: [130799.804952] jiffies <101f1d030>
Jun 17 15:56:25 altneckar kernel: [130799.804952] next_to_watch.status <0>
Jun 17 15:56:25 altneckar kernel: [130799.804952] MAC Status <80083>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY Status <796d>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY 1000BASE-T Status <7800>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY Extended Status <3000>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PCI Status <10>
Jun 17 15:56:26 altneckar kernel: [130800.892485] e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
Jun 17 15:56:26 altneckar kernel: [130800.893533] br-mesh: port 1(eth0.4042) entered disabled state
Jun 17 15:56:30 altneckar kernel: [130804.255231] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Entsprechende Einträge im Log habe ich auch auf elsenz.ffrn.de gefunden. „Normalerweise“ scheint sich das wieder zu fangen, aber ich vermute das hat dann heute Nachmittag nicht geklappt.
Wir haben nun innerhalb der letzten 36 Stunden 4 Abuse Mitteliungen wegen P2P erhalten. Das ist zu viel. Das verursacht jedes mal Arbeit und wenn das weiterhin überhand nimmt, wird Hetzner (unser Hoster), vermutlich auch irgendwann mit mehr als einem Formular für eine Stellungsnahme (welche innerhalb einer immer kürzer werdenden Frist beantwortet werden muss) reagieren. Klärt die Leute bitte auf das es auch legale, günstige Angebote gibt und sie kein P2P für illegale Aktivitäten verwenden sollen.
Das komisch ist ja auch, das es bei diesen 4 Abuse Mitteilugen nur um 3 verschiedene Filme geht. Und alle sind auf Netflix (um jetzt mal die bekannteste Firma zu nennen) verfügbar.
Es steht mit der nightly 1.5.x-20200720 nun der erste Build auf Basis des gestern veröffentlichten Gluon 2020.2 zur Verfügung.
Ich habe owe dann mal aktiviert und man kann das mal testen. Bei Freifunk Darmstadt gibt es einen Blogpost der genauer erklärt was es mit OWE auf sich hat. Als SSID habe ich erstmal owe.freifunk-rhein-neckar.de gewählt.
Da unsere stable ja noch auf Gluon 2019 basiert habe ich da auch mal eine 1.3.2-20200720 unter Verwendung von Gluon 2019.1.x bauen lassen. Da gibt es keine wirklich große Änderungen, aber es wurden nochmal ein paar Abhängigkeiten aktualisiert. Diese Firmware (oder eine ähnliche) wird vermutlich die Tage als experimental veröffentlicht werden (und sich dann langsam in Richtung Stable bewegen).
Da in der VM für dieses Forum für Docker noch der aufs Storage Driver verwendet wurde und dies mit dem neuesten Kernel Update (linux-image-4.19.0-10-amd64) nicht mehr funktionierte habe ich das Forum in eine neue VM umgezogen. Das stand sowieso mal an und bot sich daher nun an.
Dadurch dürften alle einmal abgemeldet worden sein. Das sollte aber (abgesehen von der Downtime) die einzige Folge sein.
Die letzten Tage mussten wir die Gateways leider häufiger neustarten. Grund war CVE-2020-27638. Dieses Memory Leak bei invaliden fastd Paketen wurde glücklicherweise durch fastd v21 sehr zeitnah geschlossen. Damit sollten die Reboots nun auch wieder seltener werden.
Beobachtet hat dieses Verhalten hexa bei Freifunk Darmstadt (unsere fastd Instanzen sind zwar vorher gecrasht, aber ich konnte es nicht zuordnen), geschlossen wurde es von dem fastd Entwickler NeoRaider und ecsv hat sich nun darum gekümmert das es zeitnah in die für uns relevanten buster-backports kommt und ist dran das es auch Point Releases für den Rest gibt.
Die Grundlagen für Multidomain wurden nun erfolgreich gelegt. Hintergrund ist das aktuell unser FFRN Netz ein großes Layer 2 Netz (Wikipedia) bilden mit allen Knoten. Das führt dazu das es im Netz relativ „laut“ ist.
Die aktuelle nightly enthält bereits für Testzwecke Testdomains, die endgültigen Grenzen müssen aber noch gelegt werden. Wer es mal testen will kann die gerne tun. Wechseln kann man seine Domain per SSH oder aber über den Config Mode.
Unsere Webseite wird nun mit dem Static Website Generator Hugo gebaut. Vorher waren das alles einzelne HTML Dateien wo man dann auf jeder Seite beispielsweise einzeln das Menü anpassen musste. Das war einfach sehr nervig und hat einen vor Änderungen abgeschreckt.
Ein großer Vorteil ist das der Inhalt (content) nun auch in Markdown erstellt wird und nicht mehr in HTML.
Markdown ist das was man beispielsweise hier im Forum, oder aber auch in Element (Matrix) für die Textformatierung einsetzen kann. Das wird es in Zukunft auch erlauben den Blog auf unsere Webseite umzuziehen. Damit soll es einfach etwas übersichtlicher werden. Wir brauchen einfach nicht Webseite, Blog, Forum und Wiki. Das macht es nur unübersichtlich und manche Informationen sind dadurch redundant und manche einfach falsch oder veraltet.
Die Commits im default Branch (main) werden über Github Actions automatisch gebaut und dann in den gh-pages Branch automatisch von der CI committet.
Unser Webserver lädt diesen dann alle 5 Minuten herunter (PR dafür).
Wenn also nun jemand Änderungen machen möchte kann man einfach einen Pull Request erstellen. Ich hoffe diese Möglichkeit wird auch etwas genutzt
Im Zuge dieser Änderungen wurde der Inhalt und das Design noch nicht angefasst, das ist dann eine Aufgabe für die nächste Zeit.
Der Buildprozess für die nightly 1.6.x-20210629 ist gerade fertig geworden. Das ist die erste Firmware welche auf Gluon 2021.1 basiert. Die auffälligste Neuerung ist wohl das die Statusseite ein paar mehr Informationen bekommen hat. Und ein paar neue Geräte gibt es auch noch dazu.
Ich werde dann die Tage auch noch eine darauf aufbauende potentielle neue stable bauen welche dann erstmal im experimental Branch getestet werden kann.
Die Gluon Releases aus 2021.1.x werden die letzten sein welche noch auf den Geräten mit nur 4 MB und 32 MB RAM laufen. Das betrifft als bekanntes und verbreitetes Gerät den TP-Link TL-WR841N. Ab Gluon 2021.2 wird es keine neue Firmware für diese Geräte mehr geben können.
Geräte auf Gluon 2020 zu updaten.
