Admintagebuch - Dokumentation der Admintätigkeiten

Unsere mapserver_nginx Rolle „unterstützt“ jetzt das Caching von Tiles:

Ich habe dann direkt mal die caches für unsere Map-Layer konfiguriert:

Außerdem habe ich einen neuen Layer hinzugefügt: Luftbilder (DOP20 des Landes NRW). Die haben nämlich zum 01.01.2017 ihre Kartendaten unter die Datenlizenz Deutschland - Namensnennung - Version 2.0 (www.govdata.de/dl-de/by-2-0) gestellt: http://www.bezreg-koeln.nrw.de/brk_internet/geobasis/opendata/index.html

Sieht recht hübsch aus, wie ich finde:

5 „Gefällt mir“

Kernelupgrade auf fanlin,c1024,parad0x,remue-08 und nightbounce durchgeführt. Nun laufen alle Gateways auf 4.9(.13) (ja ich weiß, 4.9.15 ist die neueste Version aber die gibts im debian repo noch nicht).

1 „Gefällt mir“

Das Problem habe ich in den letzten Tagen vermehrt gesichtet. Aktuell ist das log von parad0x voll damit. Könnte ggf. mit dieser Fehlermeldung zusammenhängen. Haben wir in der Zwischenzeit herausgefunden gehabt, was das Problem war?

Forum VM Neugestartet da Sidekiq kein lust mehr hatte Mails zu versenden…

2 „Gefällt mir“

1953 Nodes aus unserem Graphite gelöscht, die in den letzten Tagen dort gelandet sind und nicht zu uns gehören (Speicher wurde langsam knapp).

1 „Gefällt mir“

Weiss nicht ob das zählt aber: Habe die Wordpress Menüs mal entmüllt.

Ach so und Wordpress bei der Gelegenheit aktualisiert.

4 „Gefällt mir“

Forum aktualisiert.

1 „Gefällt mir“

Der Hypervisor von Parad0x wurde mit Updates versorgt und neu gestartet. Downtime ~ 12:01 bis ~ 12:08 Uhr.
Anschließend manuell (nicht Sekundengenau) die Zeit korrigiert. @descilla hier sollten wir uns nochmal über NTP gedanken machen.

läuft eigentlich auf allen gateways.

Des1 und das ganze Blech sind stehen geblieben. Resettet, auf dem Host fehlte in der rc.local der Eintrag und GRO und GSO abzuschalten. (Bin gerade zu müde, mich zu erinnern, welches der beiden die Abstürze verursacht, also beides ausgeschaltet.)

Und auch wieder in der rc.local eingetragen. Vermutlich beim letzten Kernelupdate vergessen worden.

Ein Hoch auf @wurmi s Icinga, war schneller als Graphana. Wobei, vielleicht hat AOL die Email nur wieder nicht durchgelassen :P.

5 Beiträge wurden in ein neues Thema verschoben: Monitoring: Icigna versus Grafana

Gateway parad0x auf Kernel Version 4.10.5 aktualisiert. Und es läuft jetzt auch!

Ich habe den Fehler gefunden. Und was soll ich sagen? Wir hatten den Fehler bereits Anfang Januar gefixt:

Diese Rolle wurde wohl seit dem nur nie auf Gateway parad0x ausgerollt. @Adminteam wir müssen uns überlegen, wie wir sicherstellen, dass das gesamte Playbook regelmäßig auf allen Gateways ausgerollt wird. Ich mache das gleich einmal für alle.


Hintergrund des Problems:

Wie man in dem Commit oben sieht, werden beim erstellen der Interfaces in 10_batman.cfg verschiedene post-up Befehle ausgeführt. Bei einem genaueren Blick sieht man, dass zwei von drei Befehlen für jedes Batman-Interface identisch sind.

Ab irgendeiner Kernel-Version (ich vermute jetzt mal 4.8) wir bei einem erneuten Aufruf des itentischen ip Befehls mit einem return value ungleich 0 (d. h. Programm nicht erfolgreich abgeschlossen) geantwortet (das ||: im Commit von oben sorgt dafür, dass auch im „Fehlerfall“ mit „alles ok“ weiter gemacht wird).

Das wiederum sorgt dafür, dass die batman Interfaces nicht erstellt werden (bis auf das Erste), zumindest nicht an dieser Stelle. Denn die batman Interfaces werden nun (automatisch) erstellt, wenn das erste andere Interface in das batman Interface eingehängt wird (30_gretap.cfg).

Leider fehlt hierbei mindestens die Ausführung des Befehls post-up ip rule add iif bat{{item[0]}} table ffnet pref 16000 ||:. Daher landen die Pakete nicht in der richtigen Routing Tabelle und das Routing funktioniert nicht. :open_mouth:


Das ärgerliche war, dass die batman interfaces ja doch erstellt wurden (und auch alle anderen interfaces dort korrekt eingehängt waren), nur halt nicht richtig. So bin ich leider nicht direkt auf diesen Fehler aufmerksam geworden :frowning:

3 „Gefällt mir“

Ansible playbook komplett (bis auf backports kernel) auf (parad0x), remue-08, remue-09, des1, des2 ausgerollt. Diese Gateways im Anschluss rebootet, da sich interface namen geändert haben. Der Rest folgt in der nächsten Nacht.

3 „Gefällt mir“

Das wird mit dem ansible-hypervisor in die interfaces Datei eingetragen:

Abstürze gibt es dadurch aber auch nicht mehr. GRO war damals das Problem. Wenn dieses aktiv ist, ist es immer noch nicht problemlos. Dann gehen nur maximal 100 Mbit/s durch das Gateway. Aber auch GSO kann man abschalten, denn in unserem Setting bieten beide keinen Vorteil und typischerweise eher einen Nachteil. Respektive mehr Arbeit für das System.

Wir können den ansible-hypervisor gerne dahingehend anpassen, dass es in die rc.local geschrieben wird.


Die Abstürze in der jüngsten Vergangenheit auf des1 hingen damit zusammen, dass nach dem letzten Kernelupgrade auf dem Hypervisor wieder der r8169 anstatt des r8168 Treibers verwendet wurde. Dieser bringt genau die beobachteten Probleme mit sich: Installation des r8168 Treibers

Wir sollten dort unbedingt mal ein DKMS Paket draus bauen, sodass der Treiber bei jedem Kernelupgrade gebaut wird und wir (ich) es nicht bei jedem fünften Kernelupgrade vergessen.

Die Probleme, die wir vermeintlich mit dem 4.10er Kernel (auf des1) hatten schiebe ich ebenfalls auf dieses Problem.


4.9 oder 4.10 sollten eigentlich ein LTS Kernel werden. Wir sollten schauen, welcher von beiden es ist (oder wird) und uns dann mittelfristig auf diese Version festlegen. Dann brauchen wir auch nicht ständig der neuesten Kernel-Version hinterher jagen. Denn mit den aktuellen Versionen (ab 4.7 ?, der aber leider seit irgendwann im Oktober veraltet ist) scheint ja alles problemlos zu laufen.

Edit: 4.9 ist der neue LTS Kernel: Linux-Kernel Archive: [PATCH] 4.9 is a longterm kernel Dann werde ich GW-parad0x wieder auf 4.9 downgraden.

1 „Gefällt mir“

@MPW und ich haben angefangen die VLan-Planung der Richtfunkstrecken umzusetzen.
Dadurch gibt die Karte jetzt schonmal die Realität wieder.
Alle Infos zu den vLans stehen auf der (noch) internen Wiki-Seite https://wiki.freifunk-muensterland.de/x/E4ht

Edit: Hinweis zum screenshot: Leaflet | © OpenStreetMap

2 „Gefällt mir“

Heute Morgen um ca 9 Uhr hat sich Des1 verabschiedet.

Serielle Konsole meinte so:

[105184.183124] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [swapper/2:0]
[105184.187106] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [python:8534]
[105212.183131] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [swapper/2:0]
[105212.187106] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [python:8534]

Gegen 01 Uhr heute Nacht hat der Tunneldigger wohl wieder einen Neustart gemacht und danach stieg die Load bis zum Exitus.

Hab die VM vom Hypervisor aus resettet und den Tunneldigger auf Parad0x neu gestartet.

3 „Gefällt mir“

Den r8168 Treiber auf deshyper-01 von 8.043.01-NAPI auf 8.044.02-NAPI aktualisiert. Und das ganze gleich als DKMS Paket, sodass der Treiber jetzt bei jedem Kernelupdate für den entsprechenden Kernel gebaut wird. Im Gleichen Zuge deshyper-01 und des1 dist-upgrade gemacht. Den ganzen Kram rebootet und l2tp “rebalancing” gemacht.

Ich hoffe, dass des1 jetzt mal stabiler läuft. -.-

3 „Gefällt mir“

Linux Kernel von Hand gebaut. Version 4.9.18 (von kernel.org, kernel signaturen verifiziert). Config von Debian (jessie-backports, amd64, repo) verwendet, bzw. gebaut. Mit zwei Änderungen: B.A.T.M.A.N V Routing Algo mit einkompiliert (ist aber nicht bei default aktiv), B.A.T.M.A.N. debugging mit einkompiliert.

Kernel auf des2 installiert.

1 „Gefällt mir“

ansible-hypervisor angepasst, sodass er mit dem netzwerk-setup von online.net klar kommt. Anschließend damit den hypervisor handleblech und gateway @Handle konfiguriert:

Anschließend im ansible-ffms die IP Addresse vom gw angepasst und dieses ebenfalls dort ausgerollt. (Es müssten abe rjetzt noch die Gegenstellen zu den Tunneln angepasst werden).

1 „Gefällt mir“

isc-dhcp-server.service von den gateways entfernt, tmpfs für die leases ebenfalls unmounted und in der fstab auskommentiert.

Edith: dhcpd-tmpfs.service ebenfalls deaktiviert und entfernt.

2 „Gefällt mir“