Admintagebuch - Dokumentation der Admintätigkeiten

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/

greyworm-4 für dom4 bereitgestellt

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.

2 Like

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.

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

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

2 Like

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.

4 Like

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.

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.)

3 Like

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

Die IPs sind doch aufeinanderfolgend…

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;
};
1 Like

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.:slight_smile:

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.

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.

3 Like

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). :frowning:

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

3 Like

kgbvax02 wieder nominal

2 Like

des1 (Testdomäne) hatte heute Morgen gegen 09:15 einen besorgten Kernel. Gegen 12:20 neu durchgestartet (habe lange geschlafen :D).

Commander hat uns seine VM frisch mit Debian 8 Jessie aufgespielt. @descilla und ich planen anhand der VM jetzt die Ansible-Rollen für das Backbone fertig zu stellen.

Das Backbone in der hosts-Datei wird dann vorläufig Fanlin, Commander und Des1 enthalten. Die anderen werden wir in eine Gruppe legacy-Backbone oder so ausgliedern.

4 Like

Heute ist gegen 04:02 Uhr ffwaf-srv3 mir kernel-panic gestorben. Damit ist der Server tapfer seit dem Sat Dec 19 21:32 durchgelaufen. Der Kernel ist im batman_adv gestorben.

Gegen 16:28 Uhr wurde der Server rebootet. Allerdings war der „plötzlich“ nicht mehr reboot-fest:

  • die Interface-MTU zu fanlin musste von 1280 auf default (1476) angepasst werden
  • die interface.d Skripte für das mesh-interface haben angenommen, dass bird6 schon läuft. Das ist nach einem Reboot nicht der Fall. Damit war das interface nicht vollständig im up Status. In die entsprechende Zeile habe ich ein „|| true“ eingefügt.
  • tunneldigger.service war nicht enabled und musste von Hand gestartet werden.

Die Redundanz hat insgesamt gegriffen. Es kann jedoch sein, dass es zwischen 16:28 Uhr (reboot) und 17:07 Uhr (Abschluss der Tätigkeiten oben) zu Störungen gekommen ist: von meinem Freifunk-Knoten aus, der mit ffwaf-srv2 verbunden war habe ich zwar nichts festgestellt, jedoch hab ich in einem Smoke-Ping von ffwaf-srv1 in dem Zeitraum Lücken.

2 Like

Gesten Abend habe ich auf ffwaf-srv2/3 jeweils einen caching DNS installiert (bind9). DHCP/radv(bird) verteilen die neuen Dienste.

In dem Zusammenhang fiel auf, dass Clients an srv3 die public IPv6 Adresse des srv2 nicht erreichen konnten. IPv4 sowie IPv6 Link-Lokal waren ok. Von srv3 aus war die public IPv6 Adresse von srv2 zunächst auch nicht zu erreichen. Nach einem erfolgreichen Ping von srv2 -> srv3 war der Teil des Problems behoben. Ich habe das insgesamt mit tcpdump und Co nicht weiter einkreisen können. Nach einem reboot von srv2 trat das Problem bisher nicht wieder auf.

Im Gegensatz zu den anderen Test-Domänen sind srv2/3 über eine bridge verbunden, nicht direkt über das batman-Interface. Dabei setze ich auch das Feature bridge loop avoidance.

Die VM sn-descilla-1 hat wohl einen übern Durst getrunken und Panik bekommen. Läuft jetzt wieder.