Neu auftretende Fehler mit apt kann man wie folgt beheben:
- Schlüssel abgelaufen: Komische Dinge auf Greyworm-1
- Fehlendes apt-transport-https: Komische Dinge auf Greyworm-1
Neu auftretende Fehler mit apt kann man wie folgt beheben:
Mit Unterstützung von @MPW ein bisschen Serverwartung gemacht:
Auf allen fanlin-Maschinen Sicherheitsupdates für Bind9 und Linux eingespielt.
DSA-3448 & DSA3449
Reboot VirtHost heute um 24:00.
Backup-VM ist voll gelaufen. Hatte meine Kalender-Erinnerung für das manuelle Löschen alter Sicherungen übersehen.
Alles bereinigt, Backups manuell gestartet und auf dem ToDo-Zettel Anpassung Backup-Skript fett unterstrichen
Auf dem Webserver wurde jetzt der alte Docker-Container entfernt, dieser wurde nicht mehr gebraucht da die Karte jetzt auf https://service.freifunk-muensterland.de/maps/map/ bereitgestellt wird.
Für die alte Karte, also alle URLs die auf https://freifunk-muesterland.de/map/ verweisen habe ich eine Weiterleitung auf die neue Karet eingerichtet so dass diese Links auch weiterhin funktionieren.
Grafana ist jetzt auf die Version 2.6.0 aktualisiert.
Zudem habe ich die Übersicht der Knoten und Clients mal etwas aufgebohrt um die Verteilung der Clients auf die Domänen besser darzustellen: https://freifunk-muensterland.de/grafana/dashboard/db/knoten-und-clients
Wieder Lebenserhaltende Maßnahmen für die Münsterland-Domäne, auf beiden Gateways:
Rebootfestigkeit habe ich nicht getestet.
Sicherheistupdates auf Commander1024 aufgespielt. Reboot heute 23:00.
Hoffe da ist jetzt alles rebootfest.
Nope. Ging nichts mehr durch.
Folgendes war zu tun:
root@c1024:~# ip -6 rule add iif tun-ffrl-fra table ffnet
root@c1024:~# ip -6 rule add iif tun-ffrl-dus table ffnet
root@c1024:~# ip rule add iif tun-ffrl-dus table ffnet
root@c1024:~# ip rule add iif tun-ffrl-fra table ffnet
Sollten wir unbedingt mal in Ansible gießen, da:
und
…
Hallo,
@Parad0x und ich haben gerade die von @Fungur und mir gebaute Rolle zur Vernetzung des Backbones ausgerollt. Somit hat jede Backbone-VM jetzt zu jeder einen GRE-Tunnel.
Darüber wird aber noch nicht geroutet, das kommt erst im nächsten Schritt.
Die von @descilla angesprochenen IP Regeln sind eigentlich im Ansible vorhanden, scheinbar sind die nie korrekt ausgerollt worden.
Es ist aufgefallen, dass die Ansible-Rolle die auf den Backbones den Kernel aktualisieren soll, nicht aktiv ist. Das müssen wir alle bald nochmal ausrollen.
Grüße
Matthias
ffms-ansible: Updates installiert und Upgrade von ansible auf Version 2.0.0.2
Commander-Backbone:
Ansible-VM:
In /etc/ansible/ansible.cfg
inventory = /root/ffms-ansible/hosts
gesetzt, dann brauchen wir das nicht immer mit -i hosts dazuschreiben.
Fixed. apt-transport-https
musste installiert werden. wollte erst nicht, habe dann alle repos außer die hetzner deaktiviert, ging dann, dann wollte http://repo.universe-factory.net noch einen neuen key haben, jetzt alles wunderbar.
Habe gerade die Knoten gleichmäßig(er) auf die Server verteilt. Dabei gab es Probleme. service fastd restart
scheint wohl nicht ganz sauber zu laufen. Außerdem braucht er ewig, bis er wieder Verbindungen aufbaut.
Daher wie folgt:
echo "peer limit 75;" >> /etc/fastd/vpn/fastd.conf && sleep 1 && service fastd stop && sleep 2 && service fastd start && sleep 2 && service fastd status
Die sleep’s kann man ggf. weglassen. Wollte aber nicht ein weiteres mal daneben landen und die Sekunden hatte ich dann noch.
Edit: Limit nach erfolgreicher Verteilung natürlich wieder entfernt:
sed -i '$ d' /etc/fastd/vpn/fastd.conf && sleep 1 && service fastd stop && sleep 2 && service fastd start && sleep 2 && service fastd status
auf c1024
und fanlin
kam sowas:
Jan 28 19:02:45 c1024 kernel: [155005.551278] nf_conntrack: table full, dropping packet
Jan 28 19:02:45 c1024 kernel: [155005.551564] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.558042] net_ratelimit: 3483 callbacks suppressed
Jan 28 19:02:50 c1024 kernel: [155010.558066] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.568828] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.570022] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.572894] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.573704] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.573901] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.574166] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.574432] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.574439] nf_conntrack: table full, dropping packet
net.netfilter.nf_conntrack_max
war in /etc/sysctl.conf
korrekt gesetzt, jedoch war ein viel geringerer Wert (32k) in Verwendung. Das lag vermutlich daran, dass der Wert Hash-Wert (warum auch immer) zu klein gesetzt war/wurde. Wert in /sys/module/nf_conntrack/parameters/hashsize
neu gesetzt und Einstellungen mit /sbin/sysctl -p
neu geladen. Nun glühen die Leitungen wieder.
Der Hash Wert ist nur Optimierung, das sind IMHO die Zahl der Hash Buckets.
Ich glaube nf_conntrack_max ist der falsche Parameter?
Abstimmungsergebnis umgesetzt und den Link zum Firmware-Download-Assistenten umgelenkt: Neuer Firmwaredownloader
@MPW und ich haben die Firmware-Download-Umgebung angepasst:
Zusammen mit @Parad0x habe ich gerade die Domäne-14 ins Ansible gesteckt und auf Remue-07 ausgerollt. Zusätzlich wurden für ffwaf-srv4 Tunnel auf Fanlin angelegt.
Zu meinem Bedauern hat sich @paulinsche für Ubuntu statt Debian entschieden, sodass er diesen Host alleine aufsetzen und verwalten muss. Die Tunnel stehen jedenfalls bereit.