Ucs

Univention liefert univention-policy-tools 11.0.4-4 mit AddressSanitizer aus. In LXC-Containern fuehrt das zu einer 8GB RAM-Explosion beim Boot. Diagnose und Workaround.

univention-policy-update-config-registry frisst bis zu 1.8 GB RAM pro Lauf und loest den OOM-Killer aus. Kein Upstream-Fix verfuegbar. So ersetzt du den Cron-Job durch einen systemd Timer mit cgroup-basiertem Memory-Limit.

Der S4-Connector läuft, pollt brav — aber UDM-Änderungen kommen nie in Samba an. Ursache: Nach einer DC-Migration fehlt eine einzige UCR-Variable. Ohne sie ist der gesamte Listener/Notifier-Pfad tot.

Winbind gibt WBC_ERR_DOMAIN_NOT_FOUND zurück — egal ob nss, ad oder rid Backend. Alle drei scheitern identisch. Die Root Cause: ein separates LDAP-Bind-Passwort in secrets.tdb, das bei Machine-Account-Rotation nicht aktualisiert wird.

Nach dem Demote eines UCS Domain Controllers zeigen UCR-Variablen auf Member-Servern weiterhin auf den toten DC. Fällt erst auf wenn Kerberos-Tickets auslaufen — Tage oder Wochen später. Dann bricht SMB auf einmal zusammen.

ldapwhoami bindet erfolgreich, Python ldap3 liefert invalidCredentials — mit identischen Credentials. Die Ursache: Sonderzeichen (@, !) im Passwort. libldap überträgt sie korrekt, ldap3 nicht.

Nach einem UCS DC-Demote zeigen alle Member Server weiterhin auf den toten DC. ucr set ldap/server/name hilft nicht — ‘overridden by scope ldap’. Der echte Täter: Das UDM-Objekt des alten DC behält univentionServerRole=master im OpenLDAP, und der Listener-Mechanismus setzt ldap/server/name daraus.

Nach dem Demote eines UCS Domain Controllers zeigen Memberserver noch auf den alten DC. net ads join repariert nur die AD-Seite - für UCS braucht man univention-join. Plus: TLS-Fallen mit Step-CA und ein UCR-Revert den niemand erwartet.

Nach einer UCS DC-Migration funktioniert LDAP-Auth nicht mehr? Der Backup-DC verweigert Schreiboperationen mit ‘shadow context’? Das Problem: UCR und OpenLDAP wissen nicht, dass sie jetzt Master sind.