Openldap Replikation geht nicht: Passwörter fehlen

lieber Frihjof,

herzlichen Dank!
LG Jesko

FINALLY!
Ich habs hinbekommen.
Ich hab gelernt:

  • Man lernt viel, wenn man sich intensiv reinwurstelt…
  • Die Lernkurve flacht ab und man wird kontraproduktiv, wenn man ZU LANGE dran sitzt
  • Eine lange Pause kann Wunder wirken

Danke @jrichter und @frithjof für die Hilfe/Vorarbeit.

Ich habe das Dockerfile und die Skripte von frithjof benutzt.
Was ich noch tun musste, damit es jetzt reibungslos läuft:

aus meinem vorhandenen Letsencrypt-Zertifikat eins für den ldaps basteln (–> cat privkey.pem cert.pem chain.pem > ldap-zertifikat.pem) und dieses noch in den Container mounten (in meinem Fall nach /etc/ssl/private/server.pem weils da auch im Original auf dem Server liegt, aber ansonsten ist der Pfad egal… muss hlat in der slapd.conf drin stehen).
Dann den slapd mit dem Parameter -h „ldaps://“ starten, damit er die Anfragen verschlüsselt annimmt. Vorher hatte ich nur „cannot bind… ldap… (-1)“ fehler.

Außerdem habe ich das Startskript leicht angepasst, um unkompliziert das Logging im ldap anzuschalten:

rm -rf /etc/ldap/slapd.d/* slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d chown -R openldap:openldap /etc/ldap/* chown -R openldap:openldap /var/lib/ldap chown -R openldap:openldap /etc/ldap while true do [ -e /var/lib/ldap/DEBUG ] && LOGLEVEL="-1" || LOGLEVEL="0" echo Logge mit Loglevel $LOGLEVEL /usr/sbin/slapd -d $LOGLEVEL -h "ldaps://" echo "slapd ist abgeraucht, warte 5 Sekunden und starte neu..." sleep 5 done

So lege ich an besagter Stelle eine Datei mit dem Namen DEBUG an und mit

~# docker exec -it ldap /usr/bin/killall slapd

lässt sich durch die Endlos-Schleife der slapd schnell neu starten.
Danach loggt das Teil seeeeehr ausführlich
mit

~# rm DEBUG
~# docker exec -it ldap /usr/bin/killall slapd

ist dann das Logging wieder aus.

In Moodle und Nextcloud lässt sich der LDAP nun als Backup-LDAP eintragen (tatsächlich hab ich ihn als primären LDAP drin und den schulinternen als Fallback…) und dann ist man nicht mehr von der Funktionstüchtigkeit der Internetverbindung der Schule abhängig :slight_smile: Sehr sehr gut :slight_smile:

Was ich noch nicht weiß (und grad isses mir wurscht) ist, wie ich bei dem tvial/mailserver einen zweiten LDAP eintragen kann.

So long…
merci nochmal und liebe Grüße
Jesko

:slight_smile: da kann ich noch einen Punkt ergänzen:

  • 4 Augen, die auf das Problem schauen, können Wunder bewirken!

Hallo Michael,

dummerweise ist man in unserem Job meist allein zugange :blush:

Viele Grüße

Alois

Hallo Jesko,

herzlichen Glühstrump :slight_smile:

Zwei Fragen hätte ich noch:

  1. du benutzt das letsencrypt Cert zum signieren des LDAP 8also des replizierten). Da das ein letzencrypt ist, mußt du dein cat drei dateien > zu einer.pem ja nach jedem neuerstellten letzencrypt cert laufen lassen, oder? Hast du das automatisiert?

  2. wo läuft den der Docker?
    Da die INternetverbindung in die Schule nicht mehr essentiell ist, nehme ich an, dass das auf einem Server bei hetzner (oder so) läuft.
    Man sollte die Tragweite des Exportierens des gesammten LDAP auf einen server außerhalb der Einrichtung, klar erwähnen.

LG

Holger

Hallo Holger,

Ja, das hab ich automatisiert. Ich hole die Zertifikate mit dehydrated und habe ein hook-Skript, was bei erfolgtem Zertifikatswechsel diese drei Dateien in eine wirft, zum LDAP kopiert und danach den Container neu startet.

Tatsächlich läuft der bei Hetzner. Auf der selben Maschine, auf der auch die Nextcloud läuft.
Da abgesehen vom Passwort-Hash keine zusätzlichen Daten exportiert werden (in der Nextcloud-DB stehen ja ohnehin die Login-Namen, Klarnamen und Schul-Emailadressen drin) habe ich da keine (zusätzlichen) Bauchschmerzen.
Aber klar:

  • der Vertrag zur Auftragsdatenverarbeitung (oder wie das mittlerweile heißt) muss natürlich da sein.
  • ins Verzeichnis der Verarbeitungstätigkeiten muss man das aufnehmen

habe ich noch was vergessen?

LG Jesko