Auf c1024 die FFNW Tunnel deaktivert.
Da das Gateway eine FFRL NAT-IP hat versucht es über den FFNW-Tunnel zu NATten.
Ich habe den Freifunkbot hier im Forum aktiviert 
3 „Gefällt mir“
Reboot von fanlin-Blech u.a. wegen DSA-4484.
Die fanlin-VM habe ich vorher auch mit Updates versorgt.
2 „Gefällt mir“
Im Zuge des Tickets: https://ticket.freifunk-muensterland.de/scp/tickets.php?id=6929
Das ganze FFNW IPv4 jetzt persistent in der bird-Konfiguration bei rowe, c1024 und des1 deaktiviert.
3 „Gefällt mir“
Reboot von fanlin-Blech u.a. wegen DSA-4497 .
Die fanlin-VM habe ich vorher auch mit Updates versorgt.
2 „Gefällt mir“
Blech unter TJ01 gekündigt.
es geht weiter …
das blech unter tj01 macht gerade updates und dann einen reboot
„Gelöst“ Plugin in den Kategorien Communities sowie Technik und allen Unterkategorien Aktiviert.
Der Hypervisor vom Gateway Parad0x hat Updates bekommen. Daher war Gateway Parad0x kurz offline. Updates am Gateway sind noch nicht erfolgt.
1 „Gefällt mir“
Hypervisor vom Gateway rowe kriegt Updates und wird auf Persistenz geprüft.
2 „Gefällt mir“
Das Blech unter corny bekommt grade Updates und startet dann neu.
3 „Gefällt mir“
Hier auch nochmal n paar updates gemacht…
- deshyper-01
- wiki
- ticket
- ldap
- webserver
- streamer
- mumble
- zulip
- unifi-legacy
- ansible
4 „Gefällt mir“
Auf dem Firmware-Server den crontab-Eintrag für das acme-Script gefixt und manuell ausgeführt.
2 „Gefällt mir“
- Webserver upgedatet
- Webserver PHP auf 7.3 umgestellt
- Wordpress aktualisiert
- projekt.ffmsl.de für @P4w eingerichtet
2 „Gefällt mir“
@commander hat erfolgreich gegen sein Gateway getreten weil wegen eines 503.
Löppt wieder…
OS der Foren VM und Discourse aktualisiert.
2 „Gefällt mir“
tj01 vorbereitet.
1 „Gefällt mir“
Auf tj01 rpcbind disabled und gestoppt, da wir Post vom BSI bekommen haben: https://ticket.freifunk-muensterland.de/scp/tickets.php?id=7019
1 „Gefällt mir“
Gateways ausgerollt und Admintagebuch - Dokumentation der Admintätigkeiten nochmal gemacht.
tj01 befindet sich nun auf dem neuen Blech. FFRL Tunnel fehlen allerdings noch.
3 „Gefällt mir“
Die interne Nummerierung der l2tp interfaces hat beim slovenija Tunneldigger zu ünberschneidungen geführt wenn auf einem Gateway zwei Domänen vorhanden sind die dicht beieinander liegen.
Als Basis für die Nummerierung wurde 100+DOMID genommen was zum Beispiel bei Dom01 und Dom02 auf einem Gateway dazu führt das der Tunneldigger von Dom01 das erste Interfaces für eine eingehende VPN Verbindung l2tp101-101 nennt und der Tunneldigger von Dom02 das erste Interface l2tp102-102.
Kommt jetzt ein weiterer Knoten in Dom01 und möchte eine Verbindung so legt sich der Tunneldigger von Dom01 auf die Fresse und probiert so lange bis er irgendwas findet das frei ist. Maximal jedoch 100+DOMID+1024 da max_tunnels auf 1024 begrenzt ist. Im schlimmsten Fall findet er also keine freie ID und sucht bis in alle Ewigkeit.
Mit der „Algorithmus“ zur Berechnung der Basis ist jetzt so abgeändert das er einfach für jede Domäne auf einem Gateway um 1000 hochzählt.
Bedeutet:
Hat ein Gateway die Domänen 10 12 23 28 40 55 70 dann haben diese Folgende Basis
10 -> 1000
12 -> 2000
23 -> 3000
28 -> 4000
40 -> 5000
55 -> 6000
70 -> 7000
usw.
die Überschneidung beträgt also „nur“ noch 24. Auf dauer wäre noch zu überlegen das auf 500 oder so zu senken da es in einer Domäne vermutlich nicht mehr als 500 Knoten geben sollte die einen VPN Tunnel aufbauen und es mit 1000 eine Harte grenze von 65 Domänen Pro Gateway gibt da der Wert für die ID ein Integer sein muss und dieser ansonsten überläuft. Zu erkennen an OverflowError: getsockaddrarg: port must be 0-65535. im Syslog. Oder man verknüppelt es mit max_tunnels. Dann gibt es auch keine Überschneidungen mehr. Also Zähle um max_tunnels für jede Domäne hoch.
3 „Gefällt mir“