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.
Die Graphite-Statstiken für domäne-05 sind jetzt gefixt.
Fastd-Verbindungen in Domäne 03 wieder gleichmäßig verteilt.
@Fungur und ich haben heute Nacht die bind-Rolle angepackt um für freifunk-muenster.de und freifunk-muensterland.de selbst DNS-Einträge zu setzen.
Dazu haben wir zunächst die bestehende bind-Rolle in bind_services für die Service-VM und bind_gateway für den Teil, der auf den Gateways läuft, aufgeteilt und geprüft, dass alles noch läuft.
Danach haben wir die automatische Serialisierung der Zonen per Linux-Zeitstempel eingebaut. Das führt leider dazu, dass auf der Service-VM jedes mal in Ansible eine Änderung durchgeführt wird. Dies lässt sich nicht verhindern, da man nicht zuverlässig prüfen kann, ob irgendwo sich irgendwas verändert hat. Die Einträge sind also immer gelb, das ist aber auch nicht weiter schlimm.
Zuletzt haben wir angefangen die Zonen knoten, server und services jeweils für freifunk-muenster.de und freifunk-muensterland.de mit ein paar Beispieleinträgen zu füllen.
Es muss jetzt noch der Zonentransfer an die Backbone-Server konfiguriert werden, wir brauchen von @void eine Liste mit allen derzeitigen Einträgen und dann, wenn alles läuft, kann bei der domainfactory der Eintrag geändert werden.
Grüße
Matthias
