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