Univention Bugzilla – Bug 21433
Join weiterer dc schlägt fehl, wenn opsi4ucs-ldap installiert ist _und_ opsi-pcs angelegt sind
Last modified: 2011-03-03 18:36:13 CET
Created attachment 3001 [details] Datei /var/log/univention/join.log UCS Vers. 2.4.1 Installation nach Anleitung auf http://wiki.univention.de/index.php?title=Opsi_%28open_pc_server_integration%29 1) opsi4ucs-ldap-schema auf dem Master eingespielt. 2) opsi4ucs auf einem bereits gejointend DC-Slave installiert. 3) PCs in Opsi aufgenommen und OPSI verwendet 4) Weiteren DC-Slave frisch installiert 5) Join des zweiten DC-Slave schlägt fehl. (Details weiter hinten) In der Testumgebung habe ich folgendes gemacht: 6) opsi4ucs-ldap-schema auf dem Master entfernt -> join schlägt weiter fehl 6) LDAP Container cn=OPSI,dc=domain,dc=local gelöscht. 7) im LDAP Objektklassen opsiHost und OpsiClient von allen PCs entfernt 8) Join klappt. Weitere Infos zum misslungenen Join: Ende der Konsolenausgabe: ---- snip ----- Download host certificate done Restart LDAP Server: done Sync Kerberos settings: done Configure 01univention-ldap-server-init.inst done Configure 03univention-directory-listener.inst done ************************************************************************** * Join failed! * * Contact your system administrator * ************************************************************************** * Message: FAILED: failed.ldif exists. ************************************************************************** ---- snap --- Aus /var/log/univention/join.log: --- snip ---- 02.02.11 09:59:39 LISTENER ( ERROR ) : dn=cn=hostGroups,cn=groups,cn=opsi,dc=nah,dc=local: No such object --- snap ---- Datei gesamte /var/log/univention/join.log ist dem Bugreport angehängt. Beginn der Datei failed.ldif: ---- snip ---- dn: cn=hostGroups,cn=groups,cn=opsi,dc=nah,dc=local changetype: add entryCSN: 20110128112010Z#000003#00#000000 cn: hostGroups objectClass: organizationalRole creatorsName: cn=display,cn=dc,cn=computers,dc=nah,dc=local entryUUID: 50633a5c-bf1c-102f-8a6e-9f957dbe3fe1 modifiersName: cn=display,cn=dc,cn=computers,dc=nah,dc=local createTimestamp: 20110128112010Z structuralObjectClass: organizationalRole modifyTimestamp: 20110128112010Z dn: cn=dnsupdate,cn=dhcp,cn=policies,dc=nah,dc=local changetype: add entryCSN: 20080725201827Z#000035#00#000000 cn: dnsupdate objectClass: organizationalRole creatorsName: entryUUID: 95ec22ae-eed2-102c-951e-b35c508abf53 modifiersName: createTimestamp: 20080725201827Z structuralObjectClass: organizationalRole modifyTimestamp: 20080725201827Z ---- snap ---- Sollte die gesamte failed.ldif von Interesse sein, kann ich Sie Ihnen per verschlüsselter Mail zur Verfügung stellen. Das Objekt cn=hostGroups,cn=groups,cn=opsi,dc=nah,dc=local ist auf dem Master vorhanden und enthält auch weitere Objecte. Sollten Sie weiter Infos wünschen, melden Sie sich gerne. Mit besten Grüßen Gerd Wilhelm
Interessant ist das Object cn=hostGroups auf dem DC Master: eval "$(ucr shell)" ldapsearch -x -LLL -D cn=admin,$ldap_base -w $(cat /etc/ldap.secret) cn=hostGroups Und die opsi Schema Datei. Wurde die opsi4ucs Version irgendwann aktualisiert? Wenn im Contianer cn=OPSI noch Objekte sind, die eine Schema Information benötigen, die nicht mehr vorhanden ist, dann wird die Replikation nicht funktionieren. In einer Testumgebung bitte das folgende auf dem DC Master testen: /etc/init.d/slapd stop slapcat >ldif mkdir /var/lib/univention-ldap/ldap.BACKUP mv /var/lib/univention-ldap/ldap/* /var/lib/univention-ldap/ldap.BACKUP/ ucr commit /var/lib/univention-ldap/ldap/DB_CONFIG slapadd <ldif /etc/init.d/slapd start
Hallo! Ich habe das Problem gerade nochmal in einer völlig frischen ucs2.4.0-0 Umgebung nachgestellt. 1) Opsi wurde nie aktualisiert, opsi4ucs-ldap-schema (4.0-6) wurde frisch auf dem Master installiert. 2) OPSI auf Slave1 installiert wie in Anleitung, Join-scripts auf dem Slave1 wie angegeben gestartet. -> Opsi funktioniert prina. PC in OPSI aufgenommen, Eigenschaften des PC im Opsi configed verändert. 3) Slave2 installiert, selber fehler beim join. Erstes Object aus der failed.ldif ist wieder dn=cn=hostGroups,cn=groups,cn=opsi,dc=domb,dc=local 4) Wie gewünscht auf dem Master ausgeführt: /etc/init.d/slapd stop slapcat >ldif mkdir /var/lib/univention-ldap/ldap.BACKUP mv /var/lib/univention-ldap/ldap/* /var/lib/univention-ldap/ldap.BACKUP/ ucr commit /var/lib/univention-ldap/ldap/DB_CONFIG slapadd <ldif /etc/init.d/slapd start -> Alle Befehle ohne Fehlermeldung gelaufen, slapd läuft wieder, Daten wieder drin, aber leider: 5) slave2 kann weiter nicht gejoint werden. Wie kommt denn das Opsi Schema auf den Slave2? Sollte doch auch per listener repliziert werden? Ich habe jetzt alle Schritte in einer Testumgebung ohne vertrauliche Daten, so dass ich jede Datei liefern kann. Beste Grüße Gerd Wilhelm
(In reply to comment #2) > Wie kommt denn das Opsi Schema auf den Slave2? Sollte doch auch per listener > repliziert werden? Ja, während der Replikation werden die Schema-Informationen übertragen. > Ich habe jetzt alle Schritte in einer Testumgebung ohne vertrauliche Daten, so > dass ich jede Datei liefern kann. Die slapd.conf, die opsi-Schemadatei und ein slapcat vom DC Master wären hilfreich. @Felix, bitte einmal testen wo das Problem liegt.
Created attachment 3057 [details] Die in der slapd.conf includierte Datei opsi.schema (Aus Paket opsi4ucs-schema?)
Created attachment 3058 [details] slapcat vom dc-master
Created attachment 3059 [details] /etc/ldap/slapd.conf
Das Problem ist, dass die Rechnerobjekte nicht mehr direkt als Mitglieder in ihrer primären Gruppe gesetzt werden (siehe Bug #21711). Dies ist aber aufgrund der von Opsi verwendeten LDAP Berechtigungen für die opsi Objekte im LDAP zwingend erforderlich (der join des ersten Slave funktioniert, da hier eine andere LDAP ACL greift als bei den folgenden Slaves). Workaround: Ab dem zweiten Slave, auf dem Opsi installiert werden soll, muss zunächst das Rechnerobjekt im UDM angelegt werden (UDM -> "Rechner" -> "Hinzufügen"). Dann muss dieser Rechner in die Gruppe "DC Slave Hosts" aufgenommen werden (UDM -> "Gruppen" -> "DC Slave Hosts" -> "enthaltene Rechner"). Nun kann der Rechner wie gewohnt gejoint werden. *** This bug has been marked as a duplicate of bug 21711 ***
Das wars. Nach händischem hinzufügen des Rechnerobjekts zur Gruppe funktioniert es. Danke. G.