Habe den Hop Penalty gemäß http://gluon-gateway-doku.readthedocs.org/de/latest/configuration/basics.html#sysfs-parameter mit einem echo 60 > xxx hochgesetzt, nachdem ich gesehen habe, dass ich einen Knoten C, der so mesht A -> B -> C doch tatsächlich über das mesh-vpn erreicht habe.
Würde vorschlagen das mal genauer zu untersuchen und vielleicht noch einen deutlich höheren Eintrag machen.
Die beiden anderen Backbones stehen bei Hetzner. Nur Fanlin steht auch bei Myloc.
Die VM sn-fanlin-1 und sn-fanlin-2 (Legacy-Domäne) wurden heruntergefahren.
Frische und jungfräuliche (Debian jessie) VM sn-fanlin-1 und sn-fanlin-2 wurden gestartet.
IP-Adressen sind gleich geblieben, aktuelle Updates wurden installiert, SSH ist eingerichtet.
Wenn ich nichts gegenteiliges höre, werde ich die Images der alten sn-fanlin-x am Wochenende löschen.
EDITH: An der Verwaltung (starten, stoppen, restarten) der VM hat sich nix geändert, funktioniert also wie gehabt.
Auf Fusselkater dhcp und dhcp6 gestartet. Aus irgendeinen Grund waren die gestoppt.
Habe im Wiki alle Plugins auf aktuellen Stand gebracht.
Nachtrag Wiki:
Nachtrag Backup:
Gestern Abend haben wir als Schulung begonnen die Domäne 08 auf Fanlin-01 und Dray-01 zu bauen. Diese soll für Stadtlohn sein.
Habe den Bereich in Kreis Coesfeld umbenannt.
@dippydipp hättest du auch selbst machen können 
Die erste Überschrift der Bereichs-Seite definiert den Namen. https://freifunk-muensterland.de/wiki/doku.php?id=intern:coesfeld:start
Den Inhalt des Bereichs kannst du und die anderen Mitglieder natürlich nach belieben für euch passend ändern. It’s a wiki. Viel Spaß
Kernel-Sicherheitsupdate DSA-3503 eingespielt auf: FanLin-VirtHost und allen FanLin-Büchsen, Commander1024, Des1, sn-greyworm-1 bis sn-greyworm-4 und sn-remue-01 bis sn-remue-08.
Außerdem wurden die abgelaufenen deb-Repository-Keys aktuallisiert auf: sn-greyworm-1 bis sn-greyworm-4, sn-remue-02 bis sn-remue-04.
@Parad0x gw-parad0x und sn-parad0x-01 konnte ich grad leider nicht versorgen. Machst Du bitte?
Die Virtualisierungshosts greyworm, remue usw. sollten sinnvollerweise auch das Kernelupdate bekommen (ich habe die SN deswegen noch nicht rebootet; passiert ja automatich wenn das Blech neu startet). Bitte kümmert euch darum.
Reboot von VirtHost-FanLin und damit aller dazugehörigen Kisten, Commander1024 und Des1 erfolgt am 05.03.2016 zwischen 05:00 und 05:30,
Mein Kollege hat gerade versehentlich beim aufräumen den Server ffwaf-srv4 rebootet. Der war fast reboot sicher. Die fehlenden Befehle habe ich eingearbeitet, Da da gerade dann recht wenige User druff warfen, habe ich noch ein apt-get update/upgrade hinterher geschmissen. Läuft!
bgp auf c1024 ist down. Als Umgehungslösung habe ich statische routen via fanlin gesetzt:
ip -6 r add default via fe80::200:5efe:59a3:dd7d dev bck-fanlin metric 10000 table ffnet
ip -4 r add default via 192.168.0.49 dev bck-fanlin metric 10000 table ffnetIch habe soeben das Plugin “WP to Twitter” in unserer WordPress-Installation von Version 3.2.4 auf Version 3.2.5 aktualisiert. Bei Unstimmigkeiten bitte mit einem verlinkten Thema antworten!
IPv4 auf Des1 repariert. Vermutlich wurde am Mittwoch nicht aufgepasst und es wurde aus Ansible wieder die falsche Subnetzmaske für das lo-Interface geschrieben. Da die Kiste heute morgen neu gestartet wurde (warum auch immer, ich lese hier nichts dazu?), war es danach kaputt.
Ich hab es jetzt auch im Ansible geändert.
Die IPv4-Nat-IP 185.66.193.52 ist aber nicht von außen pingbar, warum auch immer. Die Pakete kommen an und werden einfach nicht beantwortet. Ich erstelle dazu mal ein separates Thema.
Ich habe gerade in Ansible die AS-Nummern aus den Domänen rausgeschmissen, da werden die nicht gebraucht und stattdessen ins Backbone geschrieben. In der Hostvariablendatei zu Des1 wird diese dann nochmal überschrieben, da sie dort anders ist.
Und dann hab ich alles ausgerollt, ich hoffe, dass ich nichts kaputt gemacht habe. Alle Backbones sind jetzt wieder komplett auf dem Stand von Ansible.
Grüße
Matthias
Updates auf des-blech, sn-descilla-1, des1-bb, des2-test ausgeführt und den scheiß einmal neu gestartet.
PS: Es sind einige Umstellungen in Planung.
Ich habe bei Hetzner ein /29 Subnetz bestellt. D. h. die bestehenden Adressen werden bald irgendwann ausgetauscht.
Außerdem werden sn-descilla-1 und des2-test bald ausgeschaltet. Dafür kommen 4 neue VMs, die für Gateways in den Domänen genutzt werden sollen. Außerdem ggf. zwei zusätzliche Test-VMs für Spiel, Spaß und Freude.
zwei neue vms auf greyworm erstellt:
greyworm-61, greyworm-71.
IP muss noch zugewiesen werden, dediziert sind
greyworm-6.kgbvax.net
greyworm-7.kgbavx.net
Nacktes Debian 8 mit opem-vm-tools. Root bei @mpw und @Parad0x
Bird-Routing auf Gateways überarbeitet:
Bisher nur auf Domäne-01 ausgerollt.
Seit etwa einer Stunde ging über bb c1024 fast nichts mehr:
Mar 10 18:01:10 c1024 kernel: [377276.164041] net_ratelimit: 4865 callbacks suppressed
Mar 10 18:01:10 c1024 kernel: [377276.164069] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.164639] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.166826] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.168354] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.170623] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.170634] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.171267] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.172330] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.172756] nf_conntrack: table full, dropping packet
Mar 10 18:01:10 c1024 kernel: [377276.174245] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.172122] net_ratelimit: 5410 callbacks suppressed
Mar 10 18:01:15 c1024 kernel: [377281.172127] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.172392] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.172400] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.172403] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.172406] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.172738] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.172746] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.172748] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.173234] nf_conntrack: table full, dropping packet
Mar 10 18:01:15 c1024 kernel: [377281.173241] nf_conntrack: table full, dropping packet
Obwohl die Werte richtig gesetzt waren:
root@c1024:~# /sbin/sysctl -a|grep -i nf_conntrack_max
net.netfilter.nf_conntrack_max = 131072
net.nf_conntrack_max = 131072
War das Teil voll:
root@c1024:~# /sbin/sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 131072
Habe es noch mal verdoppelt. Ich glabe man kann den conntrack count irgedwo auch ganz abschalten, sollten wir uns mal überlegen.
Ich habe die fastd-Verbindungen etwas gleichmäßiger auf die VMs verteilt, dabei ist die ein oder andere VM hängen geblieben, könnte also hier und da etwas geruckelt haben. Jetzt sollte aber alles wieder laufen.