Admintagebuch - Dokumentation der Admintätigkeiten

FanLin · 19. Januar 2017 um 07:12

Blech fanlin ist wieder up.
Leider nur mit einem CPU-Kern, obwohl ich ihm im virt-manager zwei Kerne zugewiesen habe.

descilla · 19. Januar 2017 um 08:26

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.

MPW · 19. Januar 2017 um 08:33

Das wird es sein.

descilla · 19. Januar 2017 um 10:37

Auf GW @FanLin sind nun zwei CPU Cores aktiviert

descilla · 19. Januar 2017 um 14:24

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

descilla · 19. Januar 2017 um 14:27

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.

corny456 · 19. Januar 2017 um 15:53

node-respondd auf Fanlin gestoppt und deaktiviert.

Parad0x · 21. Januar 2017 um 11:56

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

corny456 · 23. Januar 2017 um 07:54

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…

descilla · 24. Januar 2017 um 01:27

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
Grafana von Version 4.0.2 auf Version 4.1.1 upgegradet
Mail-Einstellungen fürs alerting angepasst

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.