Zertifikat auf tickets.ffrn.de erneuert. Das Problem war eine veraltetet Version von dehydrated welche dazu führte, dass das Zertifikat nicht erneuert werden konnte: https://github.com/lukas2511/dehydrated/issues/684
TODO: ggf. mal überprüfen ob uns dieser Fehler noch woanders um die Ohren fliegen wird
*.nodes.ffrn.de läuft nun vorläufig erstmal wieder. Allerdings aktuell auf Servern von mir. Das wird dann noch umgezogen sobald klar ist auf welchen Server des ffrn das am besten passt.
Wichtig ist: man braucht IPv6 damit es funktioniert.
Auf nodes.ffrn.de gibt es eine Liste mit allen Adressen die verfügbar sind. Damit es funktioniert darf der Hostname eures Nodes nur die Zeichen a-Z, 0-9, äÄöÖüÜ sowie in der Mitte des Namens Bindestriche enthalten. Nodes mit doppelten Namen sind ebenfalls schlecht. Dort wird dann immer der Node genommen der zuerst mit dem Netz verbunden war. Also testet ruhig mal, bennent vielleicht mal eure Nodes mit ß, _, ., , … um und erfreut euch, das ihr euch nicht mehr die IPv6 Adresse der Nodes merken, ihr sie abtippen oder ihr sie kopieren müsst
erste Schritte in Richtung eines Mailservers auf FFRN Infrastruktur
Webseite:
fehlenden Punkt am Ende von Freifunk Rhein Neckar e.V. auf der index.html hinzugefügt
alle Verweise auf https://w.ffrn.de/kontakt von der Webseite entfernt da diese Seite im Wiki nicht existiert. (Kann gerne erstellt, mit Inhalt befüllt und problemlos wieder hinzugefügt werden.)
wir (bzw. aktuell nur ich - @JevermeisteR und @wusel bekommen dann von mir noch die Tage Zugriff) sollten nun wirklich auf alle Sachen Zugriff haben.
Erneuerung der Zertifikate von unifi.ffrn.de und netbox.ffrn.de (sollten jetzt [hoffentlich] auch wieder automatisch erneuert werden).
bridge auf vm01.ffrn.de kaputt konfiguriert und anschließend durch einen Neustart von vm01.ffrn.de es wieder zum laufen gebracht. Es gab dadurch leider eine unangekündigte etwa 30 minütige Downtime von allem auf vm01. Unter anderem war deshalb leider im FFRN-Client Netz kein IPv6 Uplink vorhanden.
Aktualiserung des Forums von 2.4.0.beta8 auf 2.4.0.beta9
resolver1.ffrn.de sollte jetzt wieder per IPv6 ereichbar sein und wurde geupdatet.
der Würgaround wurde als schneller fix so erweitert das er auch das aktuelle Problem auf s.ffrn.de erfasst (okay gleiches Problem aber anders Gateway auf dem die massive Anzahl Logs auftritt)
auf fw.ffrn.de sind die 4/32 Geräte nun schwerer zu finden da für diese in absehbarer Zeit (nächste Gluon Version) kein Support mehr bestehen wird.
blog.ffrn.de wurde nach einem reboot von tools.ffrn.de (der letzte lag 500+ Tage zurück) bisher nicht wieder zum laufen gebracht. Die Frage ist aber auch stark ob sich die Mühe lohnt. Der Rest auf dem Server sollte aber wieder laufen.
Für ffrn.de und freifunk-rhein-neckar.de wurden nun noch die DNS Einträge für DMARC, DKIM und SPF vorgenommen. Vorher hatte es Probleme mit gmail gegeben, da dort zugegebenerweise für einen SPAM Filter sehr nach SPAM aussehende Mails vom Ticketsystem abgelehnt wurden. Bisher wurden nun keine Mails mehr abgelehnt. Das muss aber natürlich nichts heißen.
Es wurden paar Bilder (GL-AR150, GL-AR300M, GL-MT300a, GL-MT300n und GL-AR750) im Firmware Selector ergänzt https://fw.ffrn.de/?q=GL.iNet
gw02.ffrn.de wurde von Debian 9.8 auf 9.11 aktualisiert. Sollte es zu keinen Problemen kommen (wovon ich nicht ausgehe und wonach es aktuell auch nicht aussieht) werden die anderen die Tage folgen.
Und natürlich (wie paktisch immer) ein paar weitere Kleinigkeiten die es jetzt nicht in die Zusammenfassung der Tätigkeiten des Tages geschafft haben.
Auf chat.ffrn.de wurde Rocket.Chat auf die aktuelle Version 2.3.1 geupdated sowie auf die Verwendung von docker-compose umgestellt damit ein einfacher Aufstart ohne Angabe von Parametern möglich wird sowie das Updaten deutlich vereinfacht.
Dabei wurde die MongoDB von 3.2.5 auf 4.0 geupdated. Das muss in mehreren Schritten über 3.4 -> 3.6 -> 4.0 erfolgen, da beim direkten Update auf 4.0 die Datenbank als zu alt zurückgewiesen wird. Dazu das DB Volume in einen 3.4 Container eingehängt hochfahren, per Bash einloggen, per mongo den Client öffnen, db.adminCommand( { setFeatureCompatibilityVersion: „3.4“ } ) eingeben, per quit() wieder raus, danach Mongo sanft (also kein -9) killen. Danach das gleiche Spiel nochmal mit 3.6 und db.adminCommand( { setFeatureCompatibilityVersion: „3.6“ } ), danach fährt die DB auch mit Mongo 4.0 hoch und Rocket.Chat migriert die Datenbank automatisch. Wichtig ist, dass FFRN zumindest MONGO_URL=mongodb://mongo:27017/meteor verwendet und nicht wie per default /rocketchat. Hat mich einige Lebenszeit gekostet.
blog.ffrn.de auf aktuelle Version von Ghost geupdated sowie auf die Verwendung von docker-compose umgestellt. Da das default theme Casper genutzt wurde, sieht dieses mittlerweile etwas anders aus und dementsprechend auch das Blog.
map.ffrn.de auf das aktuelle ffrgb develop von Github umgestellt, da das letzte stable Release im Dezember 2018 war. Look’N’Feel sollte gleich sein, neu sind u.a. die globale Übersicht ganz unten bei „Statistiken“. Falls ihr Vorschläge habt was wir noch anzeigen sollten, ganz allgemeine Verbesserungsvorschläge oder irgendwas nicht so läuft wie es sollte, schreibt uns.
es fand das erste (von nun an erstmal monatlich angedachte) Admin-Vorstand Gespräch statt.
07.01.2019
pads.ffrn.de (eine Etherpad-Lite Installation) läuft nun in einem Docker Container auf tools2.ffrn.de (natürlich in der neuesten Version)
08.01.2019
Die Behauptung
stimmt leider nicht. Das Wechseln des Gluon Branches hat irgendwie nicht geklappt. Es wird aber demnächst (falls der Buildjob endlich mal durchläuft) eine Experimental welche auf Gluon 2018.2.4 aufsetzt veröffentlicht.
Unterdessen wurde aber schon mal 1.3.x-20200108 als Nightly veröffentlicht (welches auf Gluon 2019.1.1 basiert). Die genutzte site findet sich im Branch ffrn-v.1.3.x auf GitHub.
Der letzte Eintrag liegt zwar schon etwas zurück, aber hier mal eine kurze Zusammenfassung was so passiert ist: Wir haben einen neuen Server in Betrieb genommen (itter.ffrn.de [wir haben uns auf Flüsse in der Region für die Servernamen geeinigt]). Auf diesem läuft aktuell schon gw02.ffrn.de und gw04.ffrn.de. Ansonsten läuft auf diesem auch tools-itter.ffrn.de. Hierbei handelt es sich um den Ersatz für tools.ffrn.de (die VM auf der bisher chat.ffrn.de, wiki.ffrn.de, fw.ffrn.de, blog.ffrn.de, … liefen). Das meiste wurde schon migriert. gw05.ffrn.de wird auch noch ein neues Zuhause finden.
Damit ist vm03.ffrn.de (der Server der etwa alle n * 7 Tage ausfällt) so gut wie leer.
Was auf diesem aktuell noch läuft und für das eine Lösung gefunden werden muss ist der resolver2.ffrn.de. Hierbei handelt es unglücklicherweise um eine VM deren IPv6 (welche an den spezifischen Server geknüpft ist) in der Firmware fest verankert ist. Es gibt zwar noch den resolver1.ffrn.de auf vm02.ffrn.de, aber da wir diesen perspektivisch auch austauschen oder abschalten wollen muss ein Firmware Update her welches einerseits die Redundanz sicherstellt und andererseits eben möglichst dafür sogen soll, das es dieses Problem möglichst nicht nochmal gibt.
Dieses Update wird demnächst veröffentlicht werden und vermutlich auf Gluon 2019.1.2 basieren. Allerdings ist noch nicht ganz ausgetüftelt wie wir das DNS Problem am besten lösen.
Dieses Update sollte dann definitiv auch auf allen Knoten eingespielt werden. Auch auf denen wo das Autoupdate irgendwie nicht geklappt hat, da sie möglicherweise sehr lange im Schrank lagen und das Update nun nicht mehr klappt oder dergleichen. Aber auch auf Knoten mit deaktiviertem Autoupdater sollte diese Update dann eingespielt werden.
Dazu kommen aber noch Informationen wenn das geklärt ist.
Eine eher kleinere Sache vielleicht noch. Wir haben das wiki.ffrn.de auf ein MediaWiki (das Grundystem welches auch Wikipedia verwendet) umgestellt.
Aktuell ist es aber noch nicht möglich dort Sachen zu bearbeiten, da wir das anonyme Bearbeiten und die Account Erstellung aktuell abgeschaltet haben. Eventuell wollen wir den Forums-Login mit dem Wiki verknüpfen. Das ist aber noch nicht sicher.
Auch sind ein paar Tabellen noch nicht richtig konvertiert worden.
Im Wiki wurde bereits einmal der Dienste-Artikel etwas vervollständigt und aktualisiert (ist aber noch nicht ganz vollständig, jedoch besser als vorher ) und andererseits haben wir mal einen Wiki-Artikel erstellt in dem die technischen Daten der Server des FFRN aufgelistet sind. Vielleicht interessiert sich ja jemand dafür.
Und dann fand letzen Sonntag noch das zweite Admin-Vorstand-Gespräch statt.
Das sind so die wichtigsten Punkte im letzten Monat gewesen. Irgendwie ließ sich das nicht so gut in einzelnen „Tagebuch-Einträgen“ unterbringen. Jetzt also hier einen etwas längeren Text
Heute Nacht/Morgen wurde bei vm02 (Technische Daten) durch Hetzner der CPU Lüfter ausgetauscht. Der Grund waren die CPU Temperaturen leicht über 90 °C. Um dies zu erledigen musste der Server kurz ausgeschaltet werden. Da der Server leider eine etwas hohe Uptime (608 Tage) hatte waren die Bedenken vor einem Reboot recht groß. Doch erfreulicherweise gab es scheinbar nur geringe Auswirkungen. Lediglich IPv6 auf den VMs war anschließend kaputt, da die Konfiguration auf vm02 wohl nie persistent eingerechtet wurde. Dies ist nun erledigt. Und ein Reboot ist nun auch kein großes Abenteuer mehr (gerade habe ich noch mal die neuen Updates für das Debian 9 auf dem Host eingespielt und rebootet).
Die Aktion hat eine deutliche Besserung gebracht. Die CPU hat nun eine Temperatur von um die 30 °C.
Betroffen von diesen Arbeiten waren dieses Forum, die Karte, resolver1, sowie die Gateways gw06 und gw08. Im FFRN-Netz sollte das aber eigentlich nicht zu spüren gewesen sein.
Update 17:00 Uhr: Es gab nochmal etwas Downtime, da ich die Netzwerkkonfiguration auf den Hosts angefangen habe zu vereinheitlichen. In Zukunft können wir dann beispielsweise per OpenNebula neue VMs erstellen.
Wir sind nun bei 5 neuen Gateways (gw02, gw04, gw05, gw06, gw08) angekommen. Diese zeichnen sich dadurch aus, das sie auf Debian 10 setzen und von uns ohne größere Bedenken per Ansible Änderungen ausgerollt werden können.
In diesem Zuge wurden die Hosts so umgestellt, das neue VMs per Open Nebula sehr sehr einfach erstellt werden können. Deswegen gab es auch in letzter Zeit leider öfters Ausfälle.
Die verbleibenden 2 Gateways liegen auf vmhost1. Da über diesen Host IPv6 ausgeleitet wird ist die Umstellung etwas risikoreicher, da es dafür leider keine Redundanz gibt. Hier wird es leider zu einem Ausfall von IPv6 kommen.
Im besten Fall nur 10 Minuten, aber es gibt eben unbekannte Variablen.