Das war mal in der Doku drin. War aber wohl nicht „genügend abgesprochen“, wurde daher wieder entfernt.
Ich habe alle Server geupdated und starte später die Bleche neu. Dadurch entsteht eine kurze downtime.
Da ich nach wie vor keinen Zugriff aufs Web-Interface für Tungsten habe, starte ich immer zuerst silver neu und warte bis dort wieder alles reibungslos läuft.
1 „Gefällt mir“
Die folgenden Domains habe ich von gl1 auf gl2 (neue service-vm) umgezogen:
https://ffgl.eu/
https://gl.wupper.ffrl.de/
https://gl.wupper.freifunk-rheinland.net/
https://images.ffgl.eu/
https://images.gl.wupper.ffrl.de/
https://images.gl.wupper.freifunk-rheinland.net/
https://firmware.ffgl.eu/
https://firmware.gl.wupper.ffrl.de/
https://firmware.gl.wupper.freifunk-rheinland.net/
Alle haben Zertifikate erhalten. Ich habe https://firmware.ffgl.eu so angepasst, dass die Links wieder stimmen.
Für images.* ist autoindex aktiviert, d.h. es gibt directory listings.
https://ffgl.eu bzw. die aliases haben momentan keinen Inhalt.
gl1 ist somit nur noch für internes DNS in gl.wupper zuständig. Das kläre ich mit den Wupper-Leuten, dann wird gl1 gekündigt. Außerdem ist die public IPv6-Konfiguration anscheinend broken, was dazu geführt hat, dass alle oben genannten Seiten mit aktiviertem IPv6 nicht erreichbar waren.
2 „Gefällt mir“
Was für eine Sammlung…
Zumindest kann es nicht mehr schlimmer werden, da keine weiteren Kombinationen aus „gl“ „firmware“ mehr frei sind…
19.10.
Neustart von gl2 (Service-VM) nach Freeze.
26.10.
Alle Server geupdated, batman-adv neu kompiliert und neu gestartet
1 „Gefällt mir“
09.11.
Neustart von gl2 (Service-VM) nach Freeze.
11.11.
Blech Tungsten wurde am 10.11.2016 um 10:28 Uhr abgeschaltet ohne vorherige Information.
@PetaByteBoy hat Ersatz-VMs für Odenthal und Burscheid auf Silver in Betrieb genommen:
- zusätzliche Ersatz-IPs von Silver den Silver-VM’s ODE0 und BCD0 zugewiesen
- IPs auf Konzentrator gepflegt
- DNS-Einträge von ODE0 und BCD0 geändert
- VMs gestartet
- Traffic und Erreichbarkeitskontrolle durchgeführt
Offen: IPv6 Erreichbarkeit VM ODE0 ist noch nicht gegeben (BCD0 läuft ohne Probleme). Dadurch können Störungen bei den Knoten, welche an IPv6 Uplinks hängen, auftreten.
Enges Monitoring läuft, nach 1 Stunde normale Anwenderzahl und Trafficaufkommen.
1 „Gefällt mir“
05.01.2017
Hardwareausfall von Silver seit 06:55, Ausfall BGL, LLN, ODE und BCD
Techniker von OVH arbeiten.
Behoben seit 08:13.
03.02.2017
Blech Silver war von 11.51 bis 12.12 Uhr down. Grund war ein Ausfall der Stromzufuhr.
12.1.17
Updates auf allen VMs, batman-adv 2016.5
3.2.17 22:00
Beim Hinzufügen des neuen Blechs „Copper“ ins PVE-Cluster kam es zu Problemen, ca. 1/2h downtime von Silver und damit gesamt GL.
08.03.2017
Keine IPv4 Vergabe, daher auf bgl0 (GW von Bergisch Gladbach)
-
Stop von dhcp-dienst (nicht möglich?)
-
löschen der dhcpd.leases (voll gelaufen)
-
Start von dhcp (nicht möglich?)
-
Neustart 12.10 Uhr
30.3.17
Zertifikate auf gl2 erneuert:
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/images.ffgl.eu/fullchain.pem (success)
/etc/letsencrypt/live/images.gl.wupper.freifunk-rheinland.net/fullchain.pem (success)
/etc/letsencrypt/live/firmware.gl.wupper.freifunk-rheinland.net/fullchain.pem (success)
/etc/letsencrypt/live/firmware.ffgl.eu/fullchain.pem (success)
/etc/letsencrypt/live/images.gl.wupper.ffrl.de/fullchain.pem (success)
/etc/letsencrypt/live/firmware.gl.wupper.ffrl.de/fullchain.pem (success)
/etc/letsencrypt/live/ffgl.eu/fullchain.pem (success)
/etc/letsencrypt/live/gl.wupper.ffrl.de/fullchain.pem (success)
/etc/letsencrypt/live/gl.wupper.freifunk-rheinland.net/fullchain.pem (success)
/etc/letsencrypt/live/gl2.ffgl.eu/fullchain.pem (success)
/etc/letsencrypt/live/fflln.net/fullchain.pem (success)
/etc/letsencrypt/live/freifunk-leichlingen.net/fullchain.pem (success)
/etc/letsencrypt/live/www.fflln.net/fullchain.pem (success)
/etc/letsencrypt/live/www.ffgl.eu/fullchain.pem (success)
/etc/letsencrypt/live/www.freifunk-leichlingen.net/fullchain.pem (success)
/etc/letsencrypt/live/www.freifunk-bergischgladbach.de/fullchain.pem (success)
/etc/letsencrypt/live/freifunk-bergischgladbach.de/fullchain.pem (success)
/etc/letsencrypt/live/leichlingen.freifunk.net/fullchain.pem (success)rrh0.ffgl.eu ist schon seit einigen Wochen eingerichtet, IPv6 macht noch Probleme
Hallo, vielleicht nicht die richtige „Meldestelle“ hier im Forum 
aber:
Hat noch jemand einen DNS-Ausfall auf IPv4?
Ich kriege seit einigen Stunden keine IPv4-Adressen auf den Clients zugewiesen, entsprechend funktionieren einige Dinge nicht (z.B. WhatsApp, aber auch die Eulenfunk-Map lädt nicht, bricht mit Network Error ab). Logge ich mich per SSH auf meine Nodes ein und pinge von dort beispielsweise www.google.de an, so bekomme ich per IPv6 überall Antwort, aber der IPv4-Ping funktioniert nur auf dem Uplink- / Mesh-VPN-Node. Neustarts (mehrmals, sowohl soft- als auch hardwaremäßig) helfen nicht weiter. Ich habe auch den Uplink-Node alleine probiert, auch dann bekommt der Client keine IPv4 zugewiesen. Seitenaufrufe scheitern unter Chrome (aktuellstes Update) auf Android 5.1 mit der Meldung, die Adresse könne nicht per DNS aufgelöst werden.
Edit: auch aktuellster Firefox für Android meldet DNS-Fehler, und Firefox 52.0.2 unter Windows 10 meldet ebenfalls Fehler.
Seiten die per IPv6 erreichbar sind, funktionieren aber, zum Beispiel dieses Forum!
Firmwares auf allen Nodes ist die neueste für BGL (20170314) auf ArcherC7v2 und 841Nv10
Ping @PetaByteBoy und @Frank
Wir haben offensichtlich die Anzahl der Clients durchbrochen bei der dir DHCP-leases und alte Kernel die Platte nach einigen Tagen voll beanspruchen. Ich werde mir das Problem heute mal in seiner Gesmtheit angucken und eine dauerhafte Lösung ausarbeiten.
Update 20160412:
Auf allen Servern Updates gemacht, rebooted, neues batman-adv, batctl usw…:
Hier mal zur Dokumentation der gewöhnliche Updateprozess für einen Supernode:
# systemupdate
sudo apt update
sudo apt dist-upgrade -y
sudo apt-get autoremove -y # alte kernel entfernen
# dhcp leases resetten damit die platte nicht voll laeuft
sudo service isc-dhcp-server stop
sudo rm /var/lib/dhcp/dhcpd.leases
sudo reboot
# nach reboot
# batman-adv update
wget https://downloads.open-mesh.org/batman/releases/batman-adv-2017.0.1/batman-adv-2017.0.1.tar.gz
tar xf batman-adv-2017.0.1.tar.gz
cd batman-adv-2017.0.1
make
sudo make install
cd ..
# batctl updaten
wget https://downloads.open-mesh.org/batman/releases/batman-adv-2017.0.1/batctl-2017.0.tar.gz
tar xf batctl-2017.0.tar.gz
cd batctl-2017.0
make
sudo make install
sudo reboot
Da unsere leases-Dateien öfter mal mehrere GB groß werden, was größer als ein /16-er-Netz ist, muss irgendwas beim isc-dhcp-server falsch laufen sodass das lease rotating nicht läuft. Dazu habe ich diesen Bug gefunden. Ich habe mal dem dhcpd-Benutzer die Rechte zur leases-Datei gegeben:
sudo chown dhcpd:dhcpd /var/lib/dhcp/dhcpd.leases
Jetzt heißt es schön die Festplatten im Blick behalten…
2 „Gefällt mir“
in welchen Abständen startest Du denn den isc-dhcpd neu?
ja, der isc-dhcpd ist etwa so modern wie ein uucico.
nur die alternative in Form des isc-kea(?) ist völlig „over the top“, und der DNsmasq ist schlicht mit grossen Netzen überfordert, selbst wenn man das leasefile auf eine Ramdisk legt.
Es fehlt schlicht ein isc-dhcpd fork mit leases in einer sqlite und garbage collection.
1 „Gefällt mir“
Gerade nochmal ausprobiert, jetzt läuft es wieder. 
Gleiche Symptomatik heute erneut.
Ping @PetaByteBoy @adorfer @Frank
Edit: ca. 3 Stunden später hat es sich von selbst kuriert, war vielleicht nur ein Fehlalarm? Nachdem wieder Neustarts aller Router keine Besserung brachten, habe ich einfach erstmal nur hier gepostet. Jetzt geht es wieder.
P.S.: Ist es eigentlich normal, dass ich vom reinen Mesh-Node aus keine IPv4-Adressen im Web anpingen kann? Das geht nämlich nach wie vor nicht.