Das Problem mit s.ffrn.de wurde sich nochmal angeschaut. Das Problem ist, das aufgrund eines ausufernden Datensatzes für Grafana innerhalb von 20 Minuten 100 GB an Daten anfallen und damit die 200 GB SSD im VPS bis zum letzten Byte gefüllt ist. Ist noch nicht behoben.
netcheck.ffrn.de von Python und einem extra Webserver auf eine Lösung komplett per NGINX scripting umgestellt. Falls irgendwer aus welchen Gründen auch immer direkt auf http://netcheck.ffrn.de:8123 zugegriffen hat, das geht jetzt nicht mehr. Bitte testen, lief in meinen Tests einwandfrei.
overview.ffrn.de wurde statisch mit einem Script aus der Knotenkarte von map.ffrn.de generiert. Das Format hat sich geändert und die dargestellten Knotendaten waren daher von 2018. Die neue Übersicht direkt unter ffrn.de ersetzt damit overview.ffrn.de, welches abgeschaltet wird. Wenn ihr Ideen habt wie sich das reparieren ließe, meldet euch trotzdem.
Dem „s.ffrn.de füllt sich in Windeseile“-Problem sollte nun ein Würgaround entgegenwirken, sprich: die virtuelle „Festplatte“ dort sollte nicht mehr überlaufen. Falls doch, bitte entsprechend hervorheben, danke!
Umsetzung meiner Idee auf fw.ffrn.de alles was nicht unter fw.ffrn.de/images/ liegt nach https umzuleiten. Somit ist weiterhin ein Download der Firmware auf einem Knoten über die URL möglich, aber beispielsweise in Browsern wird nun standardmäßig https verwendet.
Ich habe in nginx dafür die folgende Konfiguration vorgenommen, welche das gewünschte Resultat zu bringen scheint:
server {
listen 80;
server_name fw.ffrn.de;
server_name fw.freifunk-rhein-neckar.de;
# more directives
location /images {
autoindex on;
}
location / {
return 301 https://$host$request_uri;
}
# even more directives
}
Einrichtung einer neuen Kategorie Firmware hier im Forum in welcher von nun an die Hinweise auf neu veröffentlichte Firmware Versionen veröffentlicht werden. Dieses Kategorie kann abonniert werden und man ist immer informiert wenn eine neue Version der Firmware erscheint. Es gibt oben rechts beim Aufruf der Kategorie ein rundes Icon unter welchem man auswählen kann wie die Benachrichtigung aussehen soll.
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.