Security Updates auf Nightbounce eingespielt, reboot.
Ich habe mir jetzt mal angeschaut, warum die iptables regeln nie nach einem neustart laden:
netfilter-persistent.service (welches die iptables regeln lädt) wird von systemd nicht gestartet, da es abhängigkeitsprobleme gibt, die dadurch entstehen, dass zuvor das laden eines kernelmoduls fehlschlägt, das laden des kernelmoduls schlägt fehl, weil zwar ein neuer kernel (4.7) installiert wurde aber nicht die passenden headers dazu.
Da 4.7 nicht mehr supportet ist und ich auch gerade nicht die headers zur hand hatte, habe ich kurzerhand kernel in version 4.9.4 installiert. Nun läuft alles wie es soll.
Wegen geplanter Wartungsarbeiten an der Stromversorgung werde ich das fanlin-Blech, heute um 22:55, herunterfahren.
Es soll nur ein Ausfall von ca. 20 Minuten entstehen, aber im Zeitraum von 23:00 bis 07:00 des Folgetages. Servdiscount - Status - Webseite
Des1 neugestartet da sich in Dom25 das batman auf die Nase gelegt hat.
Anschließend auf Parad0x den Tunneldigger neugestartet zum Knoten verteilen.
Auf Des2 und Nightbounce IPV6 repariert, dazu Ansible gateways_batman und gateway_l2tp ausgerollt.
Blech fanlin ist wieder up.
Leider nur mit einem CPU-Kern, obwohl ich ihm im virt-manager zwei Kerne zugewiesen habe.
Möglicherweise ist der noch im grub deaktiviert. Da hatten wir mal eine zeitlang nr ansible rolle die das gemacht hat. Ich schaue nachher mal.
Das wird es sein.
Auf GW @FanLin sind nun zwei CPU Cores aktiviert
Batman DAT für alle Domänen auf des2 und parad0x zu Testzwecken deaktiviert:
for i in $(netstat -i | grep -oE "bat[0-9]{2}" | tr '\n' ' '); do batctl -m $i dat 0; done
Die alten Kartendaten waren in fast allen Domänen kaputt. Habe sie gelöscht, damit sie wieder neu erstellt werden. Die Karte geht nun zwar wieder, aber die History ist weg. Ich habe die alten Daten im Unterordner “backup” gesichert.
node-respondd auf Fanlin gestoppt und deaktiviert.
Am Domplatz war die 5GHz-Outdoor-Nanostation nicht mehr erreichbar. Ursache unbekannt. Das 2,4 GHz-Band war entsprechend überfüllt. Nur 50-200 kbps overall. Bei 300 Clients am Markt ging also nichts mehr.
Habe am Switch (Port 8) einen Power-Cycle durchgeführt. Die Nanostation ist wieder hochgefahren und die Clients wandern langsam ins 5HGz-Band. Und schwups sind es ein paar mbps overall.
Das ist mal wieder eine Erinnerung vom Schicksal, das wir das AirControl für Monitoring der Stock-Firmware weiter voran treiben sollten
Edit: Bild hinzugefügt. Der Sprung von 200 auf 250 war das Reaktivieren von 5GHz
Heute morgen um 6:36 Uhr hat sich bind auf Des1 hingelegt.
Jan 23 06:36:38 des1 kernel: [420709.697776] named[9337]: segfault at 1000000 ip 00007f0f34fd8005 sp 00007f0f308724a0 error 4 in libdns.so.100.2.2[7f0f34f83000+1d3000]
Grade neu gestartet.
Dabei ist mir aufgefallen das named noch nicht in ein eigenes Logfile schreibt. @descilla hattest du da nicht was geändert? Muss das vlt. noch ausgerollt werden?
PS: Das Alerting hat Top Funktioniert…
- KSM auf remue aktiviert und > 4 GB RAM “eingespart” (temporär, muss noch ein startscript bauen -> ansible)
- VM für Mailserver auf remue installiert
- ansible-hypervisor angepasst
- diverse kleine Änderungen
- console im grub aktivieren (dadurch geht dann die “vga” (vnc) ausgabe nicht mehr, mmhpf, muss da noch mal ran)
- workaround für “vm-subnetz außerhalb des host-netzes” eingebaut
- initiale version der rolle mailcow gebaut
- den mailserver für freifunk-muensterland.org konfiguriert
- ansible-hypervisor angepasst
- Grafana von Version 4.0.2 auf Version 4.1.1 upgegradet
- Mail-Einstellungen fürs alerting angepasst
Gateway des1
hat sich heute Morgen auf den Bart gelegt (und unser Monitoring hat es erkannt, tadaa). Ließ sich zwar noch pingen, sonst ging aber nicht mehr viel.
Es scheint so, dass er sich beim Entfernen eines Knoten eines Rot-Schwarz-Baumes auf die Nase gelegt hat, was von sysctl initiiert wurde, was von l2tp (Entfernen eines Tunnels) aufgerufen wurde. Sollte es erneut auftreten, sollten wir mal schauen, wo die Datenstruktur für den Knoten/Baum alloziert wird. Ich halte es eher für unwahrscheinlich, dass der Fehler direkt aus dem redblack-tree-Code kommt. Möglicherweise war es aber auch nur ein Seiteneffekt und es wurde einfach an ganz anderer Stelle im Kernel Speicherbereiche illegal überschrieben.
Nun denn, hier der Auszug aus dem syslog:
Jan 24 09:01:41 des1 kernel: [515812.155329] BUG: unable to handle kernel paging request at 0000000001000000
Jan 24 09:01:41 des1 kernel: [515812.155427] IP: [<ffffffffb0723379>] rb_erase+0x299/0x380
Jan 24 09:01:41 des1 kernel: [515812.155511] PGD 0
Jan 24 09:01:41 des1 kernel: [515812.155568] Oops: 0002 [#1] SMP
Jan 24 09:01:41 des1 kernel: [515812.155630] Modules linked in: binfmt_misc(E) ip_gre(E) ip_tunnel(E) gre(E) ebtable_filter(E) ebtables(E) bridge(E) stp(E) llc(E) batman_adv(E) libcrc32c(E) crc32c_generic(E) ip6table_mangle(E) ip6table_filter(E) ip6_tables(E) xt_TCPMSS(E) xt_tcpmss(E) xt_tcpudp(E) iptable_mangle(E) xt_nat(E) iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) iptable_filter(E) ip_tables(E) x_tables(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) jitterentropy_rng(E) hmac(E) drbg(E) ansi_cprng(E) aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) joydev(E) evdev(E) cirrus(E) i2c_piix4(E) ppdev(E) ttm(E) parport_pc(E) drm_kms_helper(E) serio_raw(E) pcspkr(E) acpi_cpufreq(E) drm(E) parport(E) button(E) virtio_balloon(E) tpm_tis(E) tpm(E) l2tp_eth(E) l2tp_netlink(E) l2tp_core(E) ip6_udp_tunnel(E) udp_tunnel(E) nf_conntrack_netlink(E) nfnetlink(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_conntrack(E) autofs4(E) hid_generic(E) usbhid(E) hid(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_mod(E) ata_generic(E) virtio_blk(E) virtio_net(E) ata_piix(E) crc32c_intel(E) libata(E) psmouse(E) scsi_mod(E) ehci_pci(E) uhci_hcd(E) ehci_hcd(E) virtio_pci(E) usbcore(E) virtio_ring(E) virtio(E) usb_common(E) floppy(E)
Jan 24 09:01:41 des1 kernel: [515812.156791] CPU: 0 PID: 9275 Comm: python Tainted: G W E 4.7.0-0.bpo.1-amd64 #1 Debian 4.7.8-1~bpo8+1
Jan 24 09:01:41 des1 kernel: [515812.156888] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
Jan 24 09:01:41 des1 kernel: [515812.156974] task: ffff880036b000c0 ti: ffff8800b9ad4000 task.ti: ffff8800b9ad4000
Jan 24 09:01:41 des1 kernel: [515812.157053] RIP: 0010:[<ffffffffb0723379>] [<ffffffffb0723379>] rb_erase+0x299/0x380
Jan 24 09:01:41 des1 kernel: [515812.157136] RSP: 0018:ffff8800b9ad7988 EFLAGS: 00010206
Jan 24 09:01:41 des1 kernel: [515812.157234] RAX: ffff8800b97e3bc8 RBX: ffff8800b9016380 RCX: ffff8800b97e3bc8
Jan 24 09:01:41 des1 kernel: [515812.157344] RDX: ffff8800b97e3bc8 RSI: ffff8800a3c53848 RDI: ffff8800b97e39e8
Jan 24 09:01:41 des1 kernel: [515812.157420] RBP: ffff8800b97e3800 R08: 0000000001000000 R09: 0000000000000000
Jan 24 09:01:41 des1 kernel: [515812.157497] R10: ffff8800b97e39c8 R11: 000000000000000c R12: ffffffffb11233c0
Jan 24 09:01:41 des1 kernel: [515812.157572] R13: ffff8800b9ad79b0 R14: ffff8800966b7000 R15: ffff8800a3ea5000
Jan 24 09:01:41 des1 kernel: [515812.157649] FS: 00007f2bf7528700(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
Jan 24 09:01:41 des1 kernel: [515812.157737] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 24 09:01:41 des1 kernel: [515812.157835] CR2: 0000000001000000 CR3: 000000013997d000 CR4: 00000000001406f0
Jan 24 09:01:41 des1 kernel: [515812.157943] Stack:
Jan 24 09:01:41 des1 kernel: [515812.158020] ffffffffb066ed5f ffff8800b97e3800 ffff8800a3c53800 ffffffffb066fae2
Jan 24 09:01:41 des1 kernel: [515812.158133] ffff8800a3ea4f28 000000002a957a6c 0000000000000286 ffff88013a70c600
Jan 24 09:01:41 des1 kernel: [515812.158258] 000000002a957a6c ffff8800a3ea52a0 ffff8800b97e3800 ffff8800a3ea5008
Jan 24 09:01:41 des1 kernel: [515812.158338] Call Trace:
Jan 24 09:01:41 des1 kernel: [515812.158404] [<ffffffffb066ed5f>] ? erase_header+0x3f/0x50
Jan 24 09:01:41 des1 kernel: [515812.158474] [<ffffffffb066fae2>] ? drop_sysctl_table+0x72/0xf0
Jan 24 09:01:41 des1 kernel: [515812.158545] [<ffffffffb066fcb8>] ? unregister_sysctl_table+0x38/0x80
Jan 24 09:01:41 des1 kernel: [515812.158627] [<ffffffffb098be7e>] ? __addrconf_sysctl_unregister.isra.42+0x1e/0x40
Jan 24 09:01:41 des1 kernel: [515812.158727] [<ffffffffb098fb9b>] ? addrconf_ifdown+0x47b/0x5a0
Jan 24 09:01:41 des1 kernel: [515812.158844] [<ffffffffb0993249>] ? addrconf_notify+0x1d9/0xb90
Jan 24 09:01:41 des1 kernel: [515812.158944] [<ffffffffb08c9612>] ? skb_dequeue+0x52/0x60
Jan 24 09:01:41 des1 kernel: [515812.159024] [<ffffffffb08e9f99>] ? pneigh_queue_purge+0x29/0x30
Jan 24 09:01:41 des1 kernel: [515812.159098] [<ffffffffb091c7da>] ? rt_flush_dev+0x3a/0xc0
Jan 24 09:01:41 des1 kernel: [515812.159179] [<ffffffffb09ba3fa>] ? ip6mr_device_event+0xaa/0xc0
Jan 24 09:01:41 des1 kernel: [515812.159298] [<ffffffffb049c895>] ? notifier_call_chain+0x45/0x70
Jan 24 09:01:41 des1 kernel: [515812.159375] [<ffffffffb08dab9f>] ? rollback_registered_many+0x1ff/0x300
Jan 24 09:01:41 des1 kernel: [515812.159451] [<ffffffffb08dacd9>] ? rollback_registered+0x39/0x60
Jan 24 09:01:41 des1 kernel: [515812.160867] [<ffffffffb08dbd00>] ? unregister_netdevice_queue+0x40/0x70
Jan 24 09:01:41 des1 kernel: [515812.162057] [<ffffffffb08dbd48>] ? unregister_netdev+0x18/0x20
Jan 24 09:01:41 des1 kernel: [515812.163204] [<ffffffffc01dd0c2>] ? l2tp_eth_delete+0x22/0x40 [l2tp_eth]
Jan 24 09:01:41 des1 kernel: [515812.164422] [<ffffffffc01d07e1>] ? l2tp_tunnel_closeall+0xb1/0x140 [l2tp_core]
Jan 24 09:01:41 des1 kernel: [515812.165527] [<ffffffffc01d0a21>] ? l2tp_udp_encap_destroy+0x31/0x60 [l2tp_core]
Jan 24 09:01:41 des1 kernel: [515812.166663] [<ffffffffb08c7ee9>] ? sk_common_release+0x19/0x110
Jan 24 09:01:41 des1 kernel: [515812.167783] [<ffffffffb09572e6>] ? inet_release+0x36/0x60
Jan 24 09:01:41 des1 kernel: [515812.168929] [<ffffffffb08c170a>] ? sock_release+0x1a/0x70
Jan 24 09:01:41 des1 kernel: [515812.169959] [<ffffffffb08c176e>] ? sock_close+0xe/0x20
Jan 24 09:01:41 des1 kernel: [515812.170956] [<ffffffffb05fbd5d>] ? __fput+0xcd/0x1e0
Jan 24 09:01:41 des1 kernel: [515812.171943] [<ffffffffb0499fa5>] ? task_work_run+0x75/0x90
Jan 24 09:01:41 des1 kernel: [515812.172894] [<ffffffffb048064e>] ? do_exit+0x39e/0xb60
Jan 24 09:01:41 des1 kernel: [515812.173860] [<ffffffffb0480e89>] ? do_group_exit+0x39/0xb0
Jan 24 09:01:41 des1 kernel: [515812.174722] [<ffffffffb048bd8b>] ? get_signal+0x2bb/0x6b0
Jan 24 09:01:41 des1 kernel: [515812.175573] [<ffffffffb042c446>] ? do_signal+0x36/0x750
Jan 24 09:01:41 des1 kernel: [515812.176456] [<ffffffffb04896da>] ? signal_wake_up_state+0x1a/0x30
Jan 24 09:01:41 des1 kernel: [515812.177256] [<ffffffffb0489e88>] ? __send_signal+0x178/0x470
Jan 24 09:01:41 des1 kernel: [515812.178034] [<ffffffffb048aa5f>] ? force_sig_info+0xbf/0xd0
Jan 24 09:01:41 des1 kernel: [515812.178812] [<ffffffffb0464a09>] ? force_sig_info_fault+0x99/0x100
Jan 24 09:01:41 des1 kernel: [515812.179501] [<ffffffffb04032e5>] ? exit_to_usermode_loop+0x85/0xc0
Jan 24 09:01:41 des1 kernel: [515812.180179] [<ffffffffb0403b01>] ? prepare_exit_to_usermode+0x21/0x30
Jan 24 09:01:41 des1 kernel: [515812.180893] [<ffffffffb09dff65>] ? retint_user+0x8/0x13
Jan 24 09:01:41 des1 kernel: [515812.181577] Code: 0f 48 89 ca 48 83 e2 fc 48 85 d2 48 89 d0 0f 84 d4 00 00 00 48 3b 7a 10 0f 84 d2 00 00 00 4c 89 42 08 4d 85 c0 0f 84 b6 00 00 00 <49> 89 08 c3 48 8b 07 48 89 01 48 83 e0 fc 0f 84 9e 00 00 00 48
Jan 24 09:01:41 des1 kernel: [515812.183074] RIP [<ffffffffb0723379>] rb_erase+0x299/0x380
Jan 24 09:01:41 des1 kernel: [515812.183779] RSP <ffff8800b9ad7988>
Jan 24 09:01:41 des1 kernel: [515812.184482] CR2: 0000000001000000
Jan 24 09:01:41 des1 kernel: [515812.187275] ---[ end trace 3b0565b1defcbe32 ]---
Jan 24 09:01:41 des1 kernel: [515812.187989] Fixing recursive fault but reboot is needed!
Im Ansible die Rolle für bird angepasst.
Mit bgp_local_pref
lässt sich ein bgp link priorisieren. Wir nutzen das, um einen der Tunnel zum FFRL zu bevorzugen (betrifft nur ausgehende Datenpakete, wir nutzen es nur bei IPv4). Bei uns wurde dazu einfach immer der erste Tunnel aus der Liste in der Config bevorzugt. Bei Tests zu “dem Twitter Problem” ist mir aufgefallen, dass das GW nightbounce
den “falschen” Tunnel verwendet.
Ich hätte natürlich auch die Reihenfolge in den host_vars ändern können. Aber da das nirgends dokumentiert ist und generell nicht die feine Art ist, habe ich stattdessen eine weitere (optionale) Variable “erfunden”. Für jeden Tunnel kann man nun mittels bgp_local_pref
die Preferenz des spezifischen Tunnels anpassen. Wir verwenden im Template (als “default” für die FFRL Tunnel den Wert 200; um so größer, desto eher bevorzugt).
Außerdem habe ich noch ein paar kleinere kosmetische Änderungen an der Rolle durchgeführt.
Btw: Was ist eigentlich mit der Rolle gateways_bird
kann die weg? @Adminteam
Der bind9.service hatte sich soeben auf des1
auf den Bart gelegt. Ein hoch auf das Monitoring; die Downtime des bind9.service lag bei 28 Minuten (ich sollte echt mal öfters in meine Emails gucken ).
Wir sollten des1
mal im Auge behalten, in den letzten Tagen läuft dieser nicht wirklich rund.
Temporär das Routing auf des1 und des2 so geändert, dass er bei v4 über dus anstatt ber raus geht, da es im ber-routing aktuell Probleme gibt. Siehe:
Alle Komponenten der Richtfunkstrecken und alle AccessPoints am Domplatz haben eine aktuelle Firmware erhalten.
Zudem habe ich angefangen die Geokoordinaten und Hostnames bei den Komponenten zu korrigieren.