21.12.2019
- die Gateways tauchen nun wieder auf map.ffrn.de auf
- stats.ffrn.de bzw. s.ffrn.de hat eine 301 Weiterleitung von http auf https bekommen
3 „Gefällt mir“
26.12.2019
- git.ffrn.de läuft nun mit aktueller gitlab Version und der Rest wurde auch aktualisiert
- Die nachfolgenden Server/Dienste versenden nun ihre Mails über mail.ffrn.de
Sollte etwas nicht klappen meldet euch bitte. - 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.
TODO:
Mail Empfang auf mail.ffrn.de umstellen.
2 „Gefällt mir“
27.12.2019
- Die mx Records wurden nun angepasst und der Mail Empfang läuft nun über mail.ffrn.de
3 „Gefällt mir“
28.12.2019
- 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.
3 „Gefällt mir“
03.01.2020
- 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.
3 „Gefällt mir“
03.01.2020
- mehr Backups
- Serverausfall am 03.01.2020
- nightly ab 1.2.x-20200104 basiert auf Gluon 2018.2.4
1 „Gefällt mir“
04.01.2020
- 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.
2 „Gefällt mir“
07.01.2020
- 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.
4 „Gefällt mir“
05.01.2019
- 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.
03.02.2019
- Grafana und InfluxDB wurden auf das neuste Release geupdated auf dem Stats-VPS s.ffrn.de
2 „Gefällt mir“
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 
6 „Gefällt mir“
19.02.2020
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.
6 „Gefällt mir“
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.
3 „Gefällt mir“
Alle Gateways laufen nun mit Debian 10.
3 „Gefällt mir“
Die Forums VM hat nun endlich mal ein Update von Debian 8 auf Debian 10 bekommen. Daher war das Forum vorhin längere Zeit nicht erreichbar.
2 „Gefällt mir“
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.
allow-hotplug ffrn-bat
iface ffrn-bat inet6 manual
pre-up /sbin/ifup ffrn-br || true
post-up /sbin/brctl addif ffrn-br $IFACE
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.
1 „Gefällt mir“
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).
08.03.2020
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.
4 „Gefällt mir“
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.
4 „Gefällt mir“