Bericht zum Ausfall von LDAP am 5.5.

Daniel Baumann daniel.baumann at bfh.ch
Mon May 8 10:08:26 CEST 2023


Hallo zusammen

Wir wurden gebeten, einen Bericht zum Ausfall von LDAP am
5.5. von ~4:00 bis 09:03 Uhr zu schreiben.


1. Ausgangslage LDAP
====================

  * unsere LDAP Server sind von 2009 und laufen noch mit Debian 10
    (buster). Sie sind die letzten noch laufenden, alten Server unserer
    alten Infrastruktur.

  * aus Zeitmangel haben wir Anfang Jahr die alten LDAP Server der alten
    Science DMZ (die bis auf Ceph vollstaendig abgebaut ist) nur ins
    neue Netz verschoben und die Hostnames ensprechend angepasst.

  * eine Erneuerung der LDAP Server braucht etwas Engineering fuer
    Anpassungen und Optimierungen fuer neueres OpenLDAP. Ausserdem sind
    nachdem die alten BFH.ch LDAP Server nun weg sind, einige
    Aufraeumarbeiten zu machen im Zusammenspiel mit IDM, welches die
    LDAP Server mit Inhalt versorgt, sowie entfernen von alten nicht-IDM
    Accounts.

  * solche "groesseren" Aenderungen die Abhaengigkeiten zu anderen
    (Quell-)Systemen ausserhalb unseres ansonsten self-contained
    Service-Stacks haben, brauchen Koordination, Vorlauf und
    gleichzeitige Umsetzung damit ein reibungsloser Betrieb garantiert
    werden kann. IDM Lifecycle (Debian 8 auf Debian 12) ist fuer Ende
    Mai geplant, d.h. wir haben den LDAP Lifecycle fuer kurz-nach-IDM
    vorgesehen.


2. Ausgangslage dehydrated
==========================

  * zur automatischen Letsencrypt-Zertifikatserneuerung verwenden wir
    dehydrated mit hooks fuer nsupdate zur DNS Verifikation.

  * da die LDAP Server so alt sind, haben sie noch eine andere, nicht
    korrekte Implementierung[1] der Letsencrypt DNS Verifikation (die
    einzig auf den LDAP Servern und nextcloud je in Verwendung war),
    d.h. ein Fail-weil-kein-CNAME-da wird nicht reported (mehr dazu
    weiter unten).

  * wie in [1] dokumentiert und erklaert, wird fuer DNS Verification
    ein CNAME verwendet. Wir machen das innerhalb der _acme.bfh.info
    Subzone.

  * auf node1.acme.bfh.info und node2.acme.bfh.info laeuft via
    pacemaker/corosync acme.bfh.info, welcher der HA authoritative
    Nameserver fuer _acme.bfh.info ist.

  * weil acme.bfh.info als Service "mandantenfaehig" ist via
    Subzonen innerhalb von _acme.bfh.info mit jeweils eigenen TSIGs,
    koennen weiterer Systeme in ihre jeweiligen Subzonen schreiben.

  * weil wir die verwendeten Implemementierungen auf Drittsystemen
    nicht beinflussen koennen (d.h. nicht alle loeschen die TXT Records
    korrekt nach Validierungslauf), flushen wir die Zonen einmal pro
    Tag, so dass sich nutzlose Records nicht anhaeufen und die
    Validierung schnell bleibt (Letsencrypt prueft grundsaetzlich alle
    TXT Records die es finden kann, gibt nach einer bestimmten nicht
    dokumentierten Anzahl Misserfolge dann aber auf).

  * das Flushen der Zonen geschieht dadurch, dass Knot (der NS Server)
    gestoppt wird, alle Zonen auf den Git-Stand zurueckgesetzt werden,
    sowie alle Timers und das Journal geloescht werden. Danach wird Knot
    wieder gestartet.

  * weil acme.bfh.info als HA Konstrukt auf node1 und node2 laeuft,
    passiert das Flushen korrekterweise auf beiden Nodes, unabhaengig
    davon wo der Dienst gerade laeuft.

  * weil das Script zum Flushen der Zonen nicht prueft, ob es Knot
    starten muss (weil aktuell acme.bfh.info gerade auf dem Node laeuft)
    wie wir das sonst ueberall machen, wird somit wenn beide Nodes
    laufen nach spaetestens 24h Knot zweimal gestartet sein. Aufgrund
    der pacemaker/corosync default-Konfiguration fuer systemd Services
    werden damit beide Knots gestoppt, mit dem Effekt dass die
    _acme.bfh.info Zone nicht aufgeloest werden kann.

  * dass Nachtragen des "nur starten wenn Knot lokal laeuft" ist schon
    lange auf meiner Todo, bin aber bisher nicht dazu gekommen das von
    meinen anderen Scripts die das gleiche machen, rueber zu kopieren.
    In diesem Wissen habe ich uebergangsweise nur node1 laufen lassen,
    so dass dieses Problem nicht eintreten kann.


3. Service Ausfall wegen fehlender Zertifikatserneuerung
========================================================

  * vor ein paar Wochen wurde, wahrscheinlich nach einem Reboot des
    darunterliegenden physischen Servers fuer Kernel Security-Updates,
    node2.acme.bfh.info von jemandem gestartet der sich dem Umstand
    nicht bewusst war.

  * damit lief in der Folge wie erlaeutert acme.bfh.info nicht mehr und
    damit war _acme.bfh.info nicht mehr aufloesbar.

  * die alte, nicht korrekte Implementierung der DNS Verification auf
    den LDAP Servern prueft auf den CNAME und kriegt einen NXDOMAIN
    zurueck, parst dieses aber fehlerhaft als "leer" womit die Situation
    "kein CNAME gesetzt, es gibt nichts zu tun" innerhalb des Hooks
    eintritt. Dadurch wird kein neues Zertifikat geholt und dehydrated
    wird ohne Fehler beendet. Dadurch wird auch keine Mail-
    Benachrichtigung ausgeloest und niemand bemerkt den Fehler.

  * als die Zertifikate um ~04:00 am 5.5.2023 ausgelaufen sind, konnten
    alle Dienste welche LDAP zur Authentisierung benutzen (u.a. IS-A und
    Magnolia) die TLS Zertifikate ueberpruefen, keine Verbindungen zu
    den LDAP Servern mehr aufbauen.

  * nach Stoppen beider acme Nodes und bewusstem starten von nur einem
    Node war _acme.bfh.info wieder da, wodurch die Records geschrieben
    werden konnten und neue Zertifikate geholt wurden. Um 09:03 waren
    alle 4 LDAP Nodes wieder uneingeschraenkt benutztbar.


4. Massnahmen
=============

  * Erneuerung LDAP Server und Zone-Flush-Fix fuer
    node{1,2}.acme.bfh.info: mit aktueller Auslastung/Prioritaeten
    aktuell kein Termin zusagbar.

Gruesse,
Daniel

[1]
https://lists.bfh.science/pipermail/bfh-linux-announce/2021-September/000134.html

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science


More information about the bfh-linux-announce mailing list