Betrieb: Signale, Neustarts und was es ausgibt

Es liest alles einmal

Die Konfigurationsdateien, jede Quelle dahinter, das TLS-Zertifikat und die Keytab werden beim Start gelesen. Es gibt kein Neuladen, und die mitgelieferte Unit hat kein ExecReload=. Nach einer Änderung an einem davon:

sudo -u authnd authnd check /etc/authnd
sudo systemctl restart authnd

Das Einzige, was im laufenden Betrieb angewendet wird, ist ein Passwort, das eine Person über authnd ändert; es liest die user-Blöcke erneut und sonst nichts.

Signale

$ authnd --config etc/authnd
ldap on 127.0.0.1:3893, serving 4 people from the configuration file, then a sqlite database
hangup: authnd does not reload; restart it to apply a changed configuration, certificate or keytab
alice's password change was refused: the old password did not verify: directory: wrong password
alice changed their own password

stopping

Das ist ein einziger Lauf: ein kill -HUP, zwei Versuche, ein Passwort zu ändern (der erste abgelehnt, der zweite angenommen), dann ein kill -TERM. Der Prozess war nach dem SIGHUP noch da.

Ein SIGHUP hat authnd früher beendet – Gos Standardverhalten für ein Signal, das niemand behandelt –, und systemd wertet einen Tod durch SIGHUP als sauberes Beenden, sodass Restart=on-failure es nicht wieder startete: Ein einziges kill -HUP oder ein einziges logrotate-postrotate legte ein Verzeichnis dauerhaft lahm. Jetzt wird es abgefangen, damit die Gewohnheit harmlos ist, und die Logzeile sagt, was stattdessen zu tun ist.

Dass auch bestehende Verbindungen geschlossen werden, nicht nur der Listener, ist Absicht: Ein Server, der keine Verbindungen mehr annimmt, seine offenen aber weiter beantwortet, sähe angehalten aus, ohne es zu sein – genau der Neustart, der nicht greift.

Was es schreibt

Alles geht auf die Standardausgabe, die unter systemd das Journal ist (journalctl -u authnd):

• beim Start, wo es lauscht und wen es bedient – ldap on …, ldaps on … oder ldap+starttls on …, dann realm EXAMPLE.ORG on … (udp and tcp) bei einem kerberos-Block;
• jeder abgelehnte Bind unter einem mfa-Block, jedes abgelehnte Token, jede abgelehnte oder abgeschlossene Passwortänderung, mit dem Grund – den der Client nie erfährt; siehe den zweiten Faktor und Tokens;
• jede Anfrage, die das KDC ablehnt, mit dem Präfix kerberos: und dem Kerberos-Fehlercode; siehe den Realm;
• das eigene Log der LDAP-Bibliothek, im slog-Textformat, auf Stufe info.

Ein schlicht falsches Passwort bei einem einfachen Bind, ohne mfa-Block, wird mit invalidCredentials beantwortet und von authnd selbst nicht protokolliert.

Wenn es nicht startet

Eine Ablehnung ist eine Zeile auf der Standardfehlerausgabe, mit dem Präfix authnd:, und Exit-Status 1; unter der Unit versucht es Restart=on-failure dann alle fünf Sekunden erneut, und die Zeile steht jedes Mal im Journal. Alles, was check ablehnt, wird auch hier abgelehnt, und das Einzige, was nur der Server findet, ist eine Adresse, auf der er nicht lauschen kann – siehe check. Der LDAP-Listener, das Zertifikat und der Realm werden alle geöffnet, bevor die erste Zeile ausgegeben wird; ein Server, der nicht starten kann, gibt daher nur die Ablehnung aus. Hier trifft eine zweite Instanz auf den Kerberos-Port der ersten:

$ authnd --config cases/realm2
authnd: kerberos udp 127.0.0.1:18388: listen udp 127.0.0.1:18388: bind: address already in use

Die Zeile ldap on … und danach realm … on … bedeuten, dass beide Hälften lauschen.

Erkennen, dass es läuft

Es gibt keinen Health-Endpunkt und keine Metriken. Was es gibt:

• den Prozess und seinen Exit-Status – unter systemd systemctl is-active authnd. Hält der LDAP-Listener oder der Realm von selbst an, endet der ganze Prozess mit diesem Fehler; ein lebender Prozess ist also einer, dessen beide Hälften antworten;
• das Root-DSE, das einem anonymen Client antwortet und sagt, mit welcher Version er spricht:

$ ldapsearch -x -LLL -H ldap://127.0.0.1:3893 -s base -b '' '+' '*'
dn:
objectClass: top
objectClass: OpenLDAProotDSE
supportedLDAPVersion: 3
namingContexts: dc=example,dc=org
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.13.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
subschemaSubentry: cn=Subschema
vendorName: go-authn/authnd
vendorVersion: v0.11.1

Auf einem StartTLS-Listener braucht diese Abfrage -ZZ. Eine Probe, die mehr beweist – dass eine Quelle noch antwortet –, ist ein Bind als eine Person oder als ein eigens dafür vorgehaltenes Lesekonto; mit einem users "ldap"-Block erreicht dieser Bind das Verzeichnis hinter diesem.

Was wo liegt und was ein Neustart verliert