Admintagebuch - Dokumentation der Admintätigkeiten

descilla · 24. Januar 2017 um 09:46

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!

descilla · 24. Januar 2017 um 23:26

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

descilla · 24. Januar 2017 um 23:41

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.

descilla · 25. Januar 2017 um 20:37

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:

Parad0x · 26. Januar 2017 um 00:27

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.

corny456 · 26. Januar 2017 um 12:55

Heute morgen gegen 6.30 Uhr hat sich der KEA Prozess auf Des1 auf die Nase gelegt. Alerting hat nicht angeschlagen da ffein-01 das Alerting vorher schon ausgelöst hatte… (ffein-01 nerft… ) Aufgefallen ist das ganze gegen 9.00 Uhr Hier.

KEA Ließ sich nicht neustarten da das Filesystem nur noch Read-Only war.
Reboot hat sich aufgehängt. Ein anschließender Reset auf dem Blech endete im Bootloader mit der Meldung: No bootable device.

@MPW hat die VM mittels ansible-hypervisor neu aufgesetzt.

Hab dann ansible-ffms drüber laufenlassen mit dem Ergebnis das KEA sich nicht bauen lässt. Vorerst umgestellt auf ISC. @descilla guckt sich das nochmal an wenn er Zeit hat.

Kernel ist aktuell der 4.8 drauf…

Hoffe es läuft jetzt erstmal…
Mache noch ein, zwei Tests und schubse dann mal ein paar Knoten von Parad0x rüber…

MPW · 26. Januar 2017 um 20:28

Kernel auf Des1 wieder auf Version 4.9 aktualisiert. Wird aktiviert, wenn heute Nacht die Kiste automatisch neu startet.

Derzeit läuft dort noch der ISC, weil wir den KEA derzeit nicht kompiliert bekommen.

descilla · 26. Januar 2017 um 22:44

Mailserver für freifunk-muensterland.de und freifunk-muenster.de umgestellt:

descilla · 27. Januar 2017 um 00:29

Deshyper-01 neu durchgestartet und vorher natürlich upgrades durchgeführt.

descilla · 27. Januar 2017 um 01:00

service-vm mit updates versorgt und rebooted.

descilla · 27. Januar 2017 um 11:45

Nachdem ich bereits im November beantragt hatte, und am 24.11.16 die Bestätigung bekam, dass deshyper-02 nicht nach 20 TB gedrosselt wird, sondern zusätzlicher Traffic gesondert abgerechnet wird, hat sich Hetzner heute dazu entschieden davon nichts mehr zu wissen und die Anbindung trotzdem zu drosseln. Erneute Service-Anfrage hat das Problem immerhin relativ schnell gelöst.

descilla · 28. Januar 2017 um 01:07

Zweite graphite-instanz erstellt. Diese ist hier zu finden: http://148.251.101.196:8000 (guest/guest) hier werden die daten der knoten gespeichert, sodass die service-vm etwas entlastet wird (langfristig sollen die daten zu den Knoten in prometheus abgelegt werden, daher ist das nur eine temporäre Lösung).

Ein weiterer Grund der sehr hohen Last, und vermutlich auch der Grund für diverse andere Probleme, auf der Service-VM war/ist das Script zum Erzeugen der Kartendaten. Dieses hat eine Laufzeit von ~ 1.12 Minuten. Soweit so gut. Leider wird es einmal die Minute ausgeführt. Zwar verfügt die Service VM über mehrere Prozessorkerne, aber dennoch ist es sicherlich nicht sinnvoll, wenn das Script mehrfach konkurrierend läuft. Ich habe daher das Ausführungsintervall auf 2 Minuten gesetzt.

ffein-01 und einen weiteren Server, der unbekannterweise seine statistiken bei uns abgeworfen hat mittels iptables blockiert.

Wir müssen echt unsere neue Kartenlösung fertig bekommen…

descilla · 28. Januar 2017 um 01:09

isc-kea-dhcp auf des1 aktiviert, zuvor isc-dhcp-server deaktiviert.

descilla · 28. Januar 2017 um 19:14

Deshyper-01 war seit 17:49 Uhr nicht mehr erreichbar. Reset durchgeführt und l2tp Verbindungen zwischen parad0x und des1 ausgeglichen.

FanLin · 29. Januar 2017 um 13:52

Ich werde heute, ca. 24:00 versuchen die Interrupt-Queues auf fanlin auf 2 zu setzen.
Letztes mal ist das fehlgeschlagen, da wohl der zweite CPU-Kern nicht aktiviert werden konnte.
Downtime wohl unter 5 Minuten.

Edith:

Das Erhöhen der Queues ist leider fehlgeschlagen.
Fehlermeldung:
Error starting domain: unsupported configuration: vhost-net was requested for an interface, but is unavailable
In der XML-Datei für fanlin wird der Parameter queues='2' hinter driver name='vhost' immer wieder automatisch entfernt also entsprechend auch nicht aktiviert.
Wieso, weshalb und warum überhaupt … kein Plan.
Kiste läuft jedenfalls wieder, leider mit alter Konfiguration.

corny456 · 30. Januar 2017 um 14:07

Da die Node Stats jetzt auf der zweiten graphite-instanz liegen waren die Clientstatistiken in der Karte kaputt.

Im Ansible Template auf Grafana Statistik umgestellt und auf der Service VM ausgerollt.

Den PR müsste noch jemand der Commit-Rechte im Repo hat mergen.

kgbvax · 3. Februar 2017 um 12:31

Zertifikat wiki.freifunk-muensterland.de erneuert, sec patches installiert.

kgbvax · 6. Februar 2017 um 21:49

forum aktualisiert

descilla · 7. Februar 2017 um 17:00

py-respondd auf die gateways ausgerollt

descilla · 8. Februar 2017 um 12:11

dist-upgrade auf des1 und deshyper-01 gemacht. Da des1 eh über nacht massig l2tp connections abgebaut hatte. linux-image von des1 wird nun über die dist-repos installiert. Ich starte gleich noch einen “langen” smart-test auf deshyper-01.

l2tp verbindungen zwischen parad0x und des1 ausgeglichen.