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 ffnet
Ich 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.
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.
@mpw und ich haben die IP von greyworm-6.1 und greyworm-7.1 konfiguriert und den Key von @mpw drauf gehauen aber noch nicht per ansible konfiguriert -> Reserve MVs
Legacy-Backbone Parad0x und Gateway SN-parad0x-01 hatten eine kurze Down-Time:
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.
Mea culpa. Der geplante automatisierte Neustart lief nicht, da sich mein Laptop aufgehängt hatte. Also hab ich den VirtHost an besagtem Tag manuell rebootet und im Grafana danach nix auffälliges gesehen. Posting hier hab ich verduselt; sorry.
Habe grad auf allen FanLin-Büchsen, Commander1024 und Des1 u.a. das Bind9-Sicherheitsupdate DSA-3511 eingespielt. Habe grad wenig Zeit, wäre super wenn jemand™ die anderem Maschinen versorgt. @Parad0x, @descilla, @Fungur, @MPW, @FanLin, @kgbvax, @void, @paulinsche
EDITH:
sn-greyworm-1 bis -4 und sn-remue-01 bis -08 hab ich grad auch schon verarztet. Der Rest muß noch …
Nachdem mein rudimentäres Monitoring häufiger Ausfälle gemeldet hat, habe ich den ffwaf-srv4 mal gebootet in der Hoffnung, dass sich nur was verschluckt hat…
Spezifischeres Routing auf Domäne 08 ausgerollt, in der Hoffnung, dass der Durchsatz durch korrektes Routing besser wird.
@Fungur, @descilla und ich haben heute angefangen den Umbauplan für Ansible Richtung [Multidomänen-L2TP][1] umzusetzen. Wie weit wir gekommen sind, könnt ihr dem Git entnehmen:
Außerdem wurde die Installation der status.pl noch von der common-Rolle in die fastd-Rolle verschoben.
Zum Testen des Multidomänen-L2TP-Batman-Ansible haben wir die VMs Greyworm-06 und Fanlin-02, sowie die IPs der Domänen 09 und 10 genommen.
Alle Gateway-Server, die mit des1 verbunden sind hatten im syslog kontinuierlich Meldungen dieser Art stehen:
Mar 15 06:25:05 remue-01 kernel: [4165459.119802] net_ratelimit: 64 callbacks suppressed
Mar 15 06:25:05 remue-01 kernel: [4165459.119825] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.119941] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.119944] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.229973] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.230014] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.250150] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.250165] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.281930] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.415657] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:05 remue-01 kernel: [4165459.424296] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:12 remue-01 kernel: [4165466.100622] net_ratelimit: 24 callbacks suppressed
Mar 15 06:25:12 remue-01 kernel: [4165466.100627] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:12 remue-01 kernel: [4165466.342335] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:12 remue-01 kernel: [4165466.348441] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:13 remue-01 kernel: [4165467.009646] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:14 remue-01 kernel: [4165468.276497] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:16 remue-01 kernel: [4165470.878291] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:16 remue-01 kernel: [4165470.878832] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:16 remue-01 kernel: [4165470.878946] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:16 remue-01 kernel: [4165470.878953] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:16 remue-01 kernel: [4165470.888180] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:20 remue-01 kernel: [4165474.465305] net_ratelimit: 2 callbacks suppressed
Mar 15 06:25:20 remue-01 kernel: [4165474.465322] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.415861] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.785980] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.791873] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.797889] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.803754] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.840556] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.841506] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.896428] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.898563] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:35 remue-01 kernel: [4165489.288017] net_ratelimit: 9 callbacks suppressed
Mar 15 06:25:35 remue-01 kernel: [4165489.288032] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:45 remue-01 kernel: [4165499.297453] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:52 remue-01 kernel: [4165506.396447] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Nachdem ich die komplette konfiguration auf des1 geprüft habe, weder Einträge im syslog auf des1 noch Hinweise zu dem Problem im Internet gefunden habe (außer) und der Ursprung der Meldung im Linux Kernel zu finden war, habe ich ein Kernel-Downgrade von 4.3 auf 4.2 durchgeführt. Und tadaa: Fehler(-meldung) weg. (Fehler war, dass wohl ToS Flags an Pakete gesetzt wurden, das ECT Flag aber nicht gesetzt war. Außer die Quittierung im syslog hatte dieser Fehler wohl keine (großartige) Auswirkung.)
Das Problem hatte aber nicht zur Ursache, dass auf des1 vergleichsweise wenig Traffic durchgeht, da bin ich aber auch dran.
Das Remue-Blech scheint wohl gestern Morgen neu gestartet worden zu sein. Zumindest waren die fastd Connections recht ungleich verteilt. Ich habe dies ausgeglichen.