Admintagebuch - Dokumentation der Admintätigkeiten

deshyper-01 hatte sich heute Morgen verabschiedet. War leider den ganzen Tag unterwegs, habe ihn gerade mal restarted.

Auf fanlin läuft / voll. Um 15:00 wird das Blech kurzzeitig heruntergefahren und das Filesystem wird vergrößert.

So, nu stehen 19 GB freier Plattenplatz, auf /, zur Verfügung

4 „Gefällt mir“

Auf dem FanLin Gateway wurde nach dem Neustart der kea-dhcp4 Server nicht gestartet, da es noch ein Lock-File gab (vermutlich wurde der Dienst zuvor nicht korrekt beendet). Habe dieses entfernt und den kea-dhcp4 Server gestartet.

1 „Gefällt mir“

Gestern Abend den Kernel auf bezreg-srv von Version 4.7 auf 4.8 aktualisiert, sowie GRO und GSO auf dem Hypervisor auf den physischen Interfaces sowie den Bridges deaktiviert (bzw. Eintrag in der Interfaces-Datei hinzugefügt). Zusammen mit @Alucardo die Firmwareversion der Dom01-KVM auf Version 2.2.0 aktualisiert (dabei wieder geshreddert und neu installiert). Btw: Dabei ist mir aufgefallen, dass ich auf der Dom01 VM schon beim letzten Mal vergessen hatte eth2 in die client-bridge zu werfen.

PS: Ich habe gestern zum Testen das Kabel vom wz-uplink von wan-mesh ins lan-mesh gesteckt und vergessen es wieder umzustecken. Also @MPW bitte nicht wundern, wenn dein Script nicht funktioniert.

PPS: Flow Control auf den ToughSwitch in der oberen Ebene auf allen Ports deaktiviert.

2 Beiträge wurden in ein neues Thema verschoben: Durchsatzproblematik Domplatz

Ich habe die Tatsache, dass der kea-dhcp4 Server auf nightbounce folgendes sagte: Active: failed (Result: exit-code) since Mon 2016-12-26 20:06:47 CET; 6 days ago, und wir nur hierdurch darauf aufmerksam geworden sind, mal zum Anlass genommen das Alerting für Prozesse zu erstellen (die Metriken liegen schon etwas länger vor, ich bin nur nicht dazu gekommen sie auch zu nutzen.

Kurzum: Die Prozesse für

  • keadhcp4
  • bird
  • bird6
  • named
  • tunneldigger

wird geschaut, ob mindestens ein Prozess läuft, andernfalls wird ein Alert ausgelöst und wir bekommen ne mail.

Hinweis: Prozess läuft != Prozess tut. Daher könnte man das sicherlich optimieren. Den Status von systemd auszulsesen wäre z. B. eine Möglichkeit. Es gibt durchaus Szenarien in denen der Prozess noch läuft (aber nicht mehr reagiert), aber systemd schon “weiß”, dass der Prozess kaputt ist. Hätte, könnte, würde, … für die allermeisten Fälle bekommen wir allerdings jetzt ein Alert.

2 „Gefällt mir“

Gateway fanlin hatte seit Tagen quasi keine l2tp Verbindungen mehr angenommen. Es scheint so, dass der tunneldigger Patch dort nicht ausgerollt wurde. Leider ließ sich der Patch auch nicht applizieren. Daher habe ich das Verzeichnis verschoben und die l2tp rolle erneut ausgerollt. Jetzt scheint es wieder zu funktionieren.

2 „Gefällt mir“

@corny456 ist jetzt Vollmitglied im Adminteam. Herzlich Willkommen und Danke für deine viele Arbeit, die du bisher schon gemacht hast.

7 „Gefällt mir“

Knoten und Client Status im Wordpress gefixt.

\o/

5 „Gefällt mir“

kea-dhcp4 war auf des1 abgeraucht, Monitoring hat es erkannt (nach 3 Minuten Mail erhalten) und ich habe ihn gerade neu gestartet (nach 3 Stunden), da ich eher keine Zeit hatte.

Möchte jemand aus dem @Adminteam (oder sonst jemand) die Alert-Mails erhalten? Dann geht das vielleicht schneller. :stuck_out_tongue:

2 „Gefällt mir“

Trag mich bitte mal mit meiner AOL-Adresse dafür ein.

1 „Gefällt mir“

Gestern Abend auf allen Gateways ein dist-upgrade durchgeführt. Dadurch wird sich der Kernel nach dem nächsten reboot auf Version 4.8 aktualisieren. Auf nightbounce konnte dkms die Virtualisierungsmodule für Kernel 4.8 nicht bauen. Falls du die also brauchst, @kgbvax, sollten wir die in einer neueren Version installieren.

Auf des1 hatte sich vorhin der tunneldigger restarted. Ich habe die Gunst der Stunde genutzt und die VM, sowie den Hypervisor neu zu starten. Ich habe auf des1 den Kernel 4.9.1 installiert. Ich bin mal gespannt, wie der so läuft.

Auf Des2 teste ich jetzt feste Mac-Adressen für die Brücken, in die die L2TP-Verbindungen gehängt werden.

Details: Designfehler: dynamische Macadresse der Brücken auf den Gateways

PS: Zusätzlich gerade die Gretap-Rolle auf alle Gateways ausgerollt, dadurch kriegt der neue Kartenserver jetzt alle Kartendaten.

Mal sehen, ob das eine sichtbare Zäsur in den Statistiken gibt.

hypervisor von des2 (und somit auch des2) neu gestartet, da upgrades durchgeführt werden mussten. Vorher noch die von @Fungur angepasste batman rolle ausgerollt. Die interfaces kamen erfolgreich mit ipv6 wieder hoch.

Auf Des1 Kerneldowngrade von 4.9 auf 4.7.

Das Batman aus Kernel 4.9 mag nicht arbeiten:

# batctl -m bat12 o
Error - mesh has not been enabled yet
Activate your mesh by adding interfaces to batman-adv

Auf des1 schien das Problem ein Anderes zu sein. Siehe Kommentar zu:

  • Logfile-Einstellungen von kea-dhcp4 geändert (von INFO auf WARN umgestellt)
  • logrotate angepasst
    • jetzt wird auch das kea-dhcp4 logfile rotiert
    • außerdem wurden die rotate und count Einstellungen nicht auf die einträge in /etc/logrotate.d/ angewandt.
  • Außerdem habe ich die tasks zum bauen von batctl angepasst
    • ab batadv 2016.3 fallen die einträge im debugfs weg und es muss über netlink/ioctl gearbeitet werden. Das konnte die bisherige batctl Version (2015.1) nicht. batctl 2016.4 (was nun installiert wird) funktioniert aber auch noch mit dem 4.7er Kerneln, respektive batadv 2016.2 (getestet).
    • es wird nun geprüft ob die passende Version installiert ist, ansonsten wird neu gebaut.
    • Erforderliche Pakete zum bauen hinzugefügt (libnl-genl-3-dev)
  • respondd Rolle aktualisiert und auf allen Gateways ausgerollt
    • repos von nodejs (und key) werden hinzugefügt
    • abhängigkeit nodejs wird nun installiert
    • die node-respondd-* services werden nun auch aktiviert
  • “networking restart” Handler angepasst (überall werden nun die selben Aufrufe durchgeführt)
    • es wird nun auch der kea-dhcp-server restartet
  • tunearpcache dem services playbook hinzugefügt und auf karteneu ausgerollt. Dort ist der ndisc cache vollgelaufen (respondd geht ja über ipv6 multicast).
  • hopglass server
    • Daten werden nun über nginx reverse-proxy ausgeliefert
    • dadurch ist die nodes.json ist 403 kb anstatt 2,6 mb groß
    • Auf den Detailseiten zu den Nodes werden die Statistiken jetzt als Grafana-Iframe eingeblendet (schön interaktiv)
    • Auf der globalen Statusseite findet sich jetzt der Status aller Grafana-Alerts.
    • Pull-Request von @Handle muss noch gemerged werden (da sollte das alles drin sein, aber @Handle hat noch einiges mehr gemacht).
  • und bestimmt 1000 Sachen, die ich vergessen habe.
5 „Gefällt mir“

Forum aktualisiert:

3 „Gefällt mir“
  • node-respondd wieder deaktiviert, da es einen zu großen Ressourcenbedarf hatte.
  • logging für named angepasst
    • es wird nun in ein eigenes logfile geschrieben
    • es wird jetzt nur noch ab der stufe “error” geloggt
  • logrotate für named und tunneldigger-broker konfiguriert
1 „Gefällt mir“