Admintagebuch - Dokumentation der Admintätigkeiten

FanLin · 17. Dezember 2015 um 08:02

Ich habe gerade, auf allen FanLin-Maschinen, ein [bind9-Sicherheitsupdate][1] eingespielt.
@Parad0x @descilla @kgbvax @Fungur @MPW @void
Bitte alle anderen Maschinen ebenfalls überprüfen (apt-get update / upgrade)
[1]: https://www.debian.org/security/2015/dsa-3420

descilla · 17. Dezember 2015 um 13:08

Ein paar fastd Connections hin und her geschubst. Ich hatte auf sn-descilla-1 schon wieder ~ 200 Connections. Da aber eine weitere Maschine auf dem Blech als Backbone-Server läuft und ich in den ersten 16 Tagen des Monats schon knapp 9 TB Traffic (outgoing) auf meinem Blech hatte, muss ich etwas Traffic sparen.
Cherry picking von master nach entwicklungszweig im ansible-ffms repo bzgl. der collectd Rolle.
Collectd Rolle aktualisiert
über das Setzen einer Variable kann nun das Erfassen von Daten für DHCP und fastd deaktiviert werden
README.md mit Erklärung der Variablen für die Collectd Rolle erstellt. Die dynamisch erzeugten “managed by ansible” kommentare durch statische ersetzt in den template-files der collectd rolle.
group_vars entsprechend angepasst.
Jeden Unterpunkt in einem eigenen Commit erfasst, um cherry-picking zu vereinfachen.
Angepasste collectd-Rolle (ohne fastd und DHCP) auf die Backbone-Server des1 sowie fanlin ausgerollt. Diese landen in graphite jetzt unter dem Target backbone.*.

MPW · 17. Dezember 2015 um 14:36

Du hast auch auf alle Maschinen Zugriff ;).

Ich hab es jetzt auf allen der Domänen 1-3 eingespielt, auf Des1, Des2, Parad0x und Fussel.

Es fehlen noch die Superknoten der Münsterland-Domäne!

kgbvax · 17. Dezember 2015 um 19:52

Die Supermodels fahren kein Bind ergo gibt es hier nichts zu tun.

Fungur · 18. Dezember 2015 um 00:21

Ich habe die neue Service-VM jetzt mit gretap-Tunneln zu allen laufenden Domänen-SN angebunden. Die Kartengenerieung läuft dort jetzt auch und wird ffms-map.fungur.eu ersetzten: http://89.163.231.228/

Der Alfred-Master ist schon auf den neuen Rechner umgezogen. Zu überlegen ist noch, wie wir dauerhaft die Domänen-Einzelseiten zur Verfügung stellen wollen.

descilla · 18. Dezember 2015 um 14:32

Heute funktionierte auf einigen VMs der “neuen” Domänen der DHCP Server nicht mehr. Grund war, dass wohl kurzzeitig das Interface bat0 nicht erreichbar war. DHCP Server auf entsprechenden Maschinen neu gestartet. DHCP funktioniert nun wieder.
Auf sn-kgbvax-2 haben sich die fastd Instanzen weggehangen. Socket entfernt, neu gestartet, geht jetzt wieder.
auf GW parad0x waren die iptables voll daher wurden massenhaft Pakete gedroppt:

[...]
Dec 18 15:17:04 parad0x kernel: [2036297.188169] net_ratelimit: 11007 callbacks suppressed
Dec 18 15:17:04 parad0x kernel: [2036297.188173] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188182] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188190] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188197] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188204] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188211] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188226] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188248] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188256] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188264] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.193716] net_ratelimit: 10655 callbacks suppressed
Dec 18 15:17:09 parad0x kernel: [2036302.193720] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.194015] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.194392] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.194828] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.195164] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.195634] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.196310] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.198030] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.198056] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.199143] nf_conntrack: table full, dropping packet.
Dec 18 15:17:14 parad0x kernel: [2036307.196277] net_ratelimit: 11576 callbacks suppressed
[...]

Vorherige max-Values und in Verwendung:

root@parad0x:~# /sbin/sysctl -a|grep -i nf_conntrack_max
net.netfilter.nf_conntrack_max = 65536
net.nf_conntrack_max = 65536
root@parad0x:~# /sbin/sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 65534
root@parad0x:~# /sbin/lsmod | egrep 'ip_tables|conntrack'
nf_conntrack_ipv4      14078  3 nf_nat,iptable_nat
nf_defrag_ipv4         12483  1 nf_conntrack_ipv4
nf_conntrack           52720  3 nf_conntrack_ipv4,nf_nat,iptable_nat
ip_tables              22042  3 iptable_filter,iptable_mangle,iptable_nat
x_tables               19118  10 ip_tables,iptable_filter,iptable_mangle,xt_mark,xt_tcpudp,xt_TCPMSS,iptable_nat,ip6_tables,ip6table_filter,ip6table_mangle

Limits verdoppelt mit:

root@parad0x:~# echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
root@parad0x:~# echo 'net.netfilter.nf_conntrack_max = 131072' >> /etc/sysctl.conf
root@parad0x:~# /sbin/sysctl -p

Nun sieht es so aus (im Logfile erscheinen nun keine weiteren Meldungen):

root@parad0x:~# /sbin/sysctl -a|grep -i nf_conntrack_max
net.netfilter.nf_conntrack_max = 131072
net.nf_conntrack_max = 131072
root@parad0x:~# /sbin/sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 69898
root@parad0x:~# /sbin/lsmod | egrep 'ip_tables|conntrack'
nf_conntrack_ipv4      14078  3 nf_nat,iptable_nat
nf_defrag_ipv4         12483  1 nf_conntrack_ipv4
nf_conntrack           52720  3 nf_conntrack_ipv4,nf_nat,iptable_nat
ip_tables              22042  3 iptable_filter,iptable_mangle,iptable_nat
x_tables               19118  10 ip_tables,iptable_filter,iptable_mangle,xt_mark,xt_tcpudp,xt_TCPMSS,iptable_nat,ip6_tables,ip6table_filter,ip6table_mangle

Wir sollten ggf. überlegen die Timeout-Limits anzupassen, wenn erneut Probleme auftreten, da ja recht viele Clients NAT über wenige IP-Adressen machen:

root@parad0x:~# sysctl -a | grep conntrack | grep timeout
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30

Knoten in der legacy Domäne neu verteilt.

descilla · 18. Dezember 2015 um 15:04

Selbes Problem bei GW fussel. Dort war das Limit sogar noch geringer:

root@fussel ~ # /sbin/sysctl -a|grep -i nf_conntrack_max
net.netfilter.nf_conntrack_max = 32092
net.nf_conntrack_max = 32092

Über Fussel ging nichts mehr ins Rheinland. Es schien so, dass auch die FFRL-Tunnel nicht mehr korrekt liefen. Daher bird und bird6 anschließend neu gestartet.

Jetzt gehts wieder.

PS: Diese Seite hat mir sehr geholfen: http://pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/

kgbvax · 19. Dezember 2015 um 11:00

greyworm-4 für dom4 bereitgestellt

descilla · 19. Dezember 2015 um 17:47

Heute Nacht 8 VMs (4 für uns, 4 für Recklinghausen) für Supernodes, Gateways, what ever auf das Remü-Blech gelötet. Außerdem eine weitere VM für Ansible erstellt, die jedoch nur über ipv6 (sowie ssh auch über ipv4 nat) erreichbar ist.

Zuvor wurde das Blech Remü in der Adminrunde auf Basis von Debian jessie und libvirt neu aufgesetzt. Die VM remue-01 wurde bereits mit ansible behandelt.

FanLin · 19. Dezember 2015 um 19:54

Habe gerade auf meinem Virt-Host, auf Backofen FanLin und auf den Supernovas FanLin ein Kernel-Sicherheitsupdate eingespielt. Heute um 24:00 Uhr wird der Virt-Host, damit auch alle FanLin-Maschinen, restartet.

@void, @Fungur, @Parad0x, @kgbvax, @paulinsche, @MPW, @descilla
Bitte alle anderen Maschinen ebenfalls überprüfen (apt-get update / upgrade)

Ich weiß. Aber ich will nicht alle Maschinen „gleichzeitig“ updaten und restarten. Erst ein paar Stunden oder nen Tag laufen lassen, um zu sehen ob Probleme auftreten.
Da ich momentan unter chronischem Zeitmangel leide, wäre es super, wenn einer von euch den Rest übernehmen kann.

descilla · 24. Dezember 2015 um 20:59

Gestern ist der fastd von sn-kgbvax-2 ausgefallen. Gerade neu gestartet und Knoten rüber geschubst.

MPW · 26. Dezember 2015 um 00:15

Domäne-04 Steinfurt-Ost konfiguriert: Domäne-04 Steinfurt-Ost kann getestet werden

MPW · 26. Dezember 2015 um 20:43

Wir haben jetzt Autoupdates in der Domäne-01. @descilla hat vorhin die bind9-Konfiguration angepasst, sodass wir node.ffms in der Domäne-01 jetzt auf 10.43.8.1 und firmware.ffms auf 2a01:4f8:191:21e1::23 schicken. Dies ist eine VM auf Remü, auf der dann ein nginx läuft.

Dieser kann wiederrum nach Quellipbereich verschiedene Firmwares ausliefern. Dazu sind folgende Blöcke in der Konfiguration nötig:

geo $domaene01 {
  default 0;
  2a03:2260:115:100::/64 1;
}

Und dann im server-Abschnitt:

if ($domaene01) {
    rewrite ^/site-ffms/(.*)$ /domaene01/$1;
}

Klappt! Ich habe jetzt mal ein Autoupdate auf Version 0.1.2 eingestellt und wir schauen mal, wie sich die Knoten verhalten und ob es überall klappt.

Parad0x · 28. Dezember 2015 um 22:31

Heute gegen Mitternacht werde ich Gateway Parad0x updaten, herunterfahren, die virtuelle Festplatte an andere Stelle verschieben und wieder starten. Damit dürfte das von @FanLin genannte Kernel-Problem (THX für dein waches Auge zum Thema Sicherheit) und das langsame-Festplatten-Problem behoben sein. Melde mich, wenn wir die Maßnahme abgeschlossen haben.

Zwischenstand: big bada boom → Raid-Probleme am Gateway Parad0x

Endstand: Server läuft im Moment auf defektem Raid. Sicherung der virtuellen HDD führt zu Absturz. Vorerst ist das System dennoch lauffähig. Neu Aufsetzen leider noch nicht durch ansible möglich. Morgen geht es weiter.

FanLin · 29. Dezember 2015 um 08:09

Habe auf Backbone fanlin einen Fehler in der bird.conf behoben.

Ursprüngliche Konfiguration:

protocol bgp ffrl_dus1 from uplink {
        source address 100.64.1.101;
        neighbor 100.64.1.100 as 201701;
};

Korrigierte Konfiguration:

protocol bgp ffrl_dus1 from uplink {
        source address 100.64.1.101;
        neighbor 100.64.0.100 as 201701;
};

Der Tunnel nach Düsseldorf ist jetzt wieder funktionsfähig. (Im Ansible ist es schon korrekt drin.)

MPW · 29. Dezember 2015 um 08:17

Kann es sein, dass das du von unten nach oben statt andersherum korrigiert hast?

Die IPs sind doch aufeinanderfolgend…

FanLin · 29. Dezember 2015 um 08:42

Du hast Recht.

Manchmal bin ich Blind …

Weiteren Fehler korrigiert:

protocol bgp ffrl_dus1 from uplink {
        source address 100.64.0.101;
        neighbor 100.64.0.100 as 201701;
};

descilla · 29. Dezember 2015 um 12:55

Gestern bind9 mit erweiterter Ansible-Rolle auf allen neuen Domänen ausgerollt.
Zweck ist die Erweiterung der zone “ffms.”. Testweise wurde hierzu auf remue-01 (soll demnächst auf Service-VM o. Ä. wandern) die zone “ffms.” als Master konfiguriert. Alle anderen Gateway-Server wurden als Slave auf diese Zone konfiguriert.

Es wurde für jede Domäne ein eigener View angelegt, sodass z. B. node.ffms je nach Domäne anders aufgelöst werden kann.

Außerdem lassen sich Gateways nun über [name].gw.ffms und Backbone-Server über [name].bb.ffms (hier sind jedoch öffentlichen Adressen hinterlegt) erreichen. Für gw.ffms. und bb.ffms. werde ich in Zukunft noch eine eigene Zone anlegen, sodass diese nicht für jede Domaene erneut generiert werden müssen (sind ja identisch). Aber praktisch hat das keien Auswirkungen; mit Ansible hat das bisherige keinen Mehraufwand.

Fungur · 29. Dezember 2015 um 17:53

Die neuen Domänen 4-6 sind jetzt auch auf der Service-VM verfügbar. Die Karten sind über http://karte.freifunk-muensterland.org/ erreichbar. Dafür gibt es den alten Prototyp-Server unter http://ffms-map.fungur.eu/ nicht mehr.

kgbvax · 30. Dezember 2015 um 12:52

Musste gerade die Anzahl der fastd Connections auf kgbvax02 drastisch reduzieren da die Kiste droht ins Throtteling zu laufen (9,7TB outbound Traffic diesen Monat).

Sind jetzt so wenige das es auch throttled noch funktionieren sollte.
Ich bestelle jetzt die Aufhebung des Limits und werde das dann wieder hochsetzen.