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“
Ich habe die DMARC Records der Domains ffrn.de und freifunk-rhein-neckar.de mal auf reject gestellt.
Ich gehe zwar eigentlich nicht davon aus das es zu Problemen kommen wird, aber meldet euch bitte wenn dem doch so wäre.
Dann habe ich mal die Delegierung der Zone rhein-neckar.freifunk.net angefragt und eine Weiterleitung auf unsere Webseite eingerichtet.
Und dann habe ich noch für die meisten Domains und Subdomains eine security.txt hinterlegt. Das ist zwar noch kein Standard, wurde aber als solcher vorgeschlagen und scheint mir eine sinnvolle Sache zu sein.
Und es haben auch durchaus schon ein paar Größere Unternehmen wie Google adaptiert.
2 „Gefällt mir“
08.04.2020
Über Nacht wurde tickets.ffrn.de auf Debian 10 geupdated sowie stats.ffrn.de auf Debian 9 und dann 10. Bei der Umstellung auf 10 hat es ein paar Probleme bei graphite gegeben. Zwecks einfacherer Handhabung durch die vielen Pfade wird gerade auf Docker umgestellt, daher kann es kurzfristige Ausfälle bei den Stats geben.
Edit: Ich musste ein Rollback von dem Statsserver machen und probiere es jetzt erneut. Ziel ist weiterhin in Zukunft Dockercontainer zu nutzen.
Edit2: Nach ein paar Versuchen läuft jetzt endlich Debian 10 und die Daten kommen noch an. Es scheint einiges an versteckten Abhängigkeiten zu geben, so dass ein Entfernen nicht benötigter Pakete nach dem Update bereits die Datensammlung verhindert. Damit das in Zukunft nicht passiert, soll wie geplant auf Docker umgestellt werden. Immerhin haben wir jetzt eine Basis zum Experimentieren. TLS 1.3 für stats.ffrn.de folgt morgen.
Edit3: Ich bastel noch, da Punkt Mitternacht die Datensammlung am 9.4. aufgehört hat ohne ersichtlichen Grund. In Zukunft wird Influxdb zum Einsatz kommen, später mehr.
2 „Gefällt mir“
Seit gut einem Jahr liefen die FFRN Domains auf den Nameservern von Hetznern (nachdem sie wohl vorher auf Leahs liefen). Diese Dienstleistung von Hetzner kostete bislang 0,59 € pro Domain und Jahr. Dafür bekam man ein einfaches E-Mail Interface an welches man die PGP signierten Änderungen schicken konnte und ein Formular in deren Verwaltungsoberfläche, welches diese E-Mail Schnittstelle bediente.
Das hat sich nun mit deren neuer DNS Console geändert. Nun ist die Dienstleistung (ohne Ankündigung an die zahlenden Kunden 
). Als bisheriger Kunde wurde man auch umgestellt und muss immerhin nicht mehr zahlen, musste sich aber eben auch mit den Startschwierigkeiten (siehe Twitter, welche meines Erachtens nach wie vor nicht komplett behoben sind), herumärgern.
Lange Rede, kurzer Sinn: während ich die Neuerungen grundsätzlich begrüße hat es mich so sehr genervt, das die Domains nun von eigenen Nameservern (auf denen Knot läuft) bedient werden.
Das war zwar perspektivisch eh von mir angedacht, aber das wurde nun etwas beschleunigt.
Die Änderung hat aber auch den Hintergrund den Domain Registrar zu wechseln (aktuell Hetzner) um die Zonen ffrn.de und freifunk-rhein-neckar.de künftig per DNSSEC signieren zu können, was bei Hetzner nicht möglich ist, da sich dort der Public Key für Domains nicht hinterlegen lässt.
2 „Gefällt mir“
Ich habe nun die letzten Tage ein paar Reports bekommen, das Mails abglehnt wurde, da sie von den falschen IPs kamen (SPF) und zusätzlich die DKIM Signatur im Header nicht passte. Das würde ich mal als Erfolg bewerten. Die IPs, welche in diesen DMARC Reports aufgelistet wurden, stehen auch nicht im Bezug zum FFRN. Das waren also keine False Positives.
Ich habe vor etwa einer Stunde den VM Host altneckar.ffrn.de (Wiki) neugestartet. Darauf laufen dieses Forum, die Karte und ein paar GWs. Das hatte den etwa 25 minütigen Ausfall von diesen Sachen zur Folge. Die anderen GWs waren dadurch nicht beeinträchtigt. Grund für die ganze Aktion war, das sich, nachdem ich map.ffrn.de heruntergefahren hatte, diese VM nicht mehr starten ließ, da libvirt nicht mehr geantwortet hat. Und da die Kiste eh einen Reboot brauchte, habe ich das dann gemacht.
Edit: map.ffrn.de wird nochmal ausfallen, da dort noch Debian 10 installiert werden soll
1 „Gefällt mir“