KVM startet nicht ohne LDAP

[Lookbehind]

Hallo zusammen,

ich hab mir mit meinem Home-Server scheinbar ein Ei gelegt. Man könnte auch sagen, ich habe ein Henne-Ei-Problem.

Ich habe auf meinem Home-Server (Debian Stretch) eine VM. Diese VM stellt LDAP bereit, unter anderem auch für die Host-Maschine. Das funktioniert auch so weit.
... zumindest bis zu einem Reboot!

Dann kommt nämlich libvirtd nicht hoch. Demnach kommt die VM mit dem LDAP drin auch nicht hoch, ergo keine LDAP-User auf der Host-Maschine. Der Spaß beginnt, wenn man sich anschaut, warum libvirtd nicht hoch kommt.

Code: Alles auswählen

● libvirtd.service - Virtualization daemon
   Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-01-15 21:25:45 CET; 1min 8s ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 1005 (libvirtd)
    Tasks: 17 (limit: 9830)
   CGroup: /system.slice/libvirtd.service
           └─1005 /usr/sbin/libvirtd

Jan 15 21:26:43 HomeServer libvirtd[1005]: nss_ldap: reconnecting to LDAP server...
Jan 15 21:26:46 HomeServer libvirtd[1005]: nss_ldap: could not connect to any LDAP server as <SAG_ICH_NICH> - Can
Jan 15 21:26:46 HomeServer libvirtd[1005]: nss_ldap: failed to bind to LDAP server ldaps://<SAG_ICH_NICHT>: Can't contact LD
Jan 15 21:26:46 HomeServer libvirtd[1005]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Jan 15 21:26:49 HomeServer libvirtd[1005]: nss_ldap: could not connect to any LDAP server as <SAG_ICH_NICHT> - Can
Jan 15 21:26:49 HomeServer libvirtd[1005]: nss_ldap: failed to bind to LDAP server ldaps://<SAG_ICH_NICHT>: Can't contact LD
Jan 15 21:26:49 HomeServer libvirtd[1005]: nss_ldap: could not search LDAP server - Server is unavailable
Jan 15 21:26:52 HomeServer libvirtd[1005]: nss_ldap: could not connect to any LDAP server as <SAG_ICH_NICHT> - Can
Jan 15 21:26:52 HomeServer libvirtd[1005]: nss_ldap: failed to bind to LDAP server ldaps://<SAG_ICH_NICHT>: Can't contact LD
Jan 15 21:26:52 HomeServer libvirtd[1005]: nss_ldap: reconnecting to LDAP server...

(Systemd Ausgaben kopieren ist immer ein riesen Spaß. Da kann man bald besser zu Screenshots zurück.)

Es sieht also so aus, dass libvirtd nicht startet, weil der LDAP-Server nicht erreichbar ist. Der LDAP-Server wiederum ist nicht erreichbar, weil libvirtd nicht startet. Und da beißt sich die Katze dann in den eigenen Schwanz.

Die kurzfristige Lösung für mich war nun, die /etc/nsswicht.conf zu bearbeiten, dort jegliche Referenz auf LDAP zu entfernen, dann nscd und libvirtd neu zu starten. Dann kam die VM auch problemlos hoch, und danach die nsswitch wieder an zu passen und nscd nochmal neu zu starten, damit die LDAP-User auf dem Host-System auch verfügbar sind. Das funktioniert zwar, wenn ich das allerdings bei jedem Reboot machen muss, hab ich da langfristig ein ungutes Gefühl bei.

Allerdings war ich von dem Verhalten auch etwas überrascht. Ich hätte nicht gedacht, dass libvirtd den LDAP-Zugriff braucht (bzw eigentlich braucht nscd den) um zu starten. Ich wäre jetzt davon ausgegangen, dass, solange der LDAP nicht verfügbar ist, eben nur lokale System-User verfügbar sind, und das auf den Start der VMs keinen Einfluss hat. Tja, da hab ich wohl die Rechnung ohne den Wirt gemacht.

Die Fragen die sich mir nun stellen sind:
1. Wie kann ich das Problem elegant lösen?
2. Warum ist das überhaupt so? Wie gesagt, ich hätte nicht mit einer Abhängigkeit zwischen LDAP-Zugriff und dem starten von VMs gerechnet.


Schöne Grüße

Look


Edit:
Ergänzend hier noch meine nsswitch.conf

Code: Alles auswählen

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files ldap

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Ich war auch davon ausgegangen, dass LDAP immer erst als letztes gefragt wird, da es in der Liste hinten steht. (Meine das mal irgendwo gelesen zu haben)

[bluestar]

Ergänzend hier noch meine nsswitch.conf

Code: Alles auswählen

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files ldap

Ergänze mal hinter ldap folgendes:

Code: Alles auswählen

[unavail=return]

[Lookbehind]

Jup, that did the trick.

Hatte ich gestern Nacht auch selbst gefunden. Wollte damit aber noch ein paar Tests machen, bevor ich hier was falsches als Lösung veröffentliche. Aber ja, das hilft. Außerdem habe ich in der /etc/ldap/ldap.conf noch einen Timeout gesetzt.

Gruß

Look

[Lookbehind]

Tja, wie das bei Servern so ist, die werden selten neu gestartet. Demnach fallen solche Dinge auch nicht so oft auf. Ich hatte das beim letzten mal nur mit einem Restaret der einzelnen Dienste getestet. Jetzt gab es mal einen kompletten Reboot. ... Das Problem ist leider noch nicht so ganz gelöst.

Bei einem Reboot laufe ich trotzdem in das gleiche Problem. libvirtd kommt mit der gleichen Fehlermeldung nicht hoch. Anders als vorher reicht es jetzt aber libvirtd kurz neu zu starten. systemctl restart libvirtd.service
Klingt so ein bisschen nach einer Racing-Condition, was systemd ja, im Gegensatz zu systemV-init, durch sein Abhängigkeits-Modell eigentlich verhindern soll. Aber eigentlich ist eigentlich auch ein blödes Wort.

Logs lesen ist hier leider nur bedingt hilfreich, weil es problemlos läuft, bis oben genannte Fehlermeldung auftaucht, aber nicht ganz klar ist, welche Komponente fehlt oder zu früh kommt. Oder ich bin zu doof die Logs zu interpretieren. (Was nicht unwahrscheinlich ist)

Hat jemand nen Tipp wie man das ganze weiter debuggen könnte? (Ich muss mal schauen wo ich ne KVM fähige Kiste zum experimentieren her bekomme).

[bluestar]

Ich habe auf meinem Home-Server (Debian Stretch) eine VM. Diese VM stellt LDAP bereit, unter anderem auch für die Host-Maschine. Das funktioniert auch so weit.
... zumindest bis zu einem Reboot!

Ich stell erst mal, bevor wir hier Ewigkeiten an deinem Problem dran sind, folgende Frage: Warum ist dein System-Design so „kaputt“?

Lösungsansatz:
- LDAP Dienst direkt auf dem KVM Host installieren

[Lookbehind]

...
Lösungsansatz:
- LDAP Dienst direkt auf dem KVM Host installieren

Aus Sicherheitsgründen eher ungern. Da würde ich lieber versuchen die restlichen Dienste noch in weitere VMs um zu ziehen. Da muss ich mir dann nur überlegen, wie ich das mit dem teilweise benötigten Shared-Storage verheirate. NFS wollte ich eigentlich vermeiden. Insbesondere weil eine Anwendung eben auch Block-Storage braucht.

Was man aber machen könnte, dass man den LDAP auf ein separat stehendes RasPi umzieht oder zumindest dort hin replizieren lässt. Die beiden werden wohl eher unwahrscheinlich gleichzeitig neu starten. Und selbst wenn wäre der Deadlock weg, weil sie unabhängig starten.

Dennoch will mir immer noch nicht ganz ins Hirn wofür libvirt das LDAP überhaupt braucht. Mir fällt höchstens ein, dass es evtl nachschauen möchte, welche User Berechtigungen haben mit libvirt zu reden. Aber die relevanten Gruppen kvm, libvirt und libvirt-qemu sind lokal, nicht im LDAP und auch lokal auflösbar. Die Abfrage sollte er also eigentlich machen können. Aber selbst das wäre ja nicht nötig um den Dienst an sich und die VMs im Autostart zu starten.

Sprich es gibt da einen Deadlock auf Grund einer Abhängigkeit, für die ich keine Notwendigkeit sehe und die Abhängigkeit eigentlich am liebsten auflösen würde.

[bluestar]

Brauchst du auf dem Host denn die User aus dem LDAP Server?