Seite 1 von 1
[gelöst] opsi4ucs: join schlägt fehl
Verfasst: 02 Feb 2011, 10:33
von gerdw
Hallo UIB-Team.
Nach der Installation (und _Benutzung) es nicht möglich, weitere Server zu UCS Domäne hinzuzufügen.
Da ich eher ein UCS-Problem vermute, habe ich einen ausführlichen Fehlerbericht bei Univention angelegt (
https://forge.univention.org/bugzilla/s ... i?id=21433) und poste das hier nur "zur Info"
Beste Grüße
Gerd Wilhelm
Re: opsi4ucs: join schlägt fehl
Verfasst: 02 Feb 2011, 15:05
von ueluekmen
Hallo Gerd,
zur Info: opsi4ucs 4.0 ist noch nicht für UCS 2.4.1 getestet und deshalb auch noch nicht dafür freigegeben.
Dennoch würde mich folgendes interessieren, da wir bald auch dieses Thema in der QA angehen müssen:
Ich gehe mal davon aus, dass hier die Rede von opsi4ucs 4.0 ist.
Wurde auf dem weiteren DCSLAVE auch opsi4ucs installiert, oder soll er einfach so gejoined werden? Wurde nach der Installation der opsi Pakete der eigentliche Slave neu gejoined?
Re: opsi4ucs: join schlägt fehl
Verfasst: 02 Feb 2011, 15:18
von gerdw
ueluekmen hat geschrieben:zur Info: opsi4ucs 4.0 ist noch nicht für UCS 2.4.1 getestet und deshalb auch noch nicht dafür freigegeben.
Oups. Das kann natürlich sein, dass es an der Minor Version liegt. Wenn ich Zeit habe Teste ichs mal mit UCS 2.4.0
ueluekmen hat geschrieben:Wurde auf dem weiteren DCSLAVE auch opsi4ucs installiert, oder soll er einfach so gejoined werden?
Nein. Auf dem 2. DC-Slave wurde weder opsi4ucs installiert, noch das opsi4ucs-ldap-schema (Dies sollte sich ja durch den Listener replizieren)
ueluekmen hat geschrieben:Wurde nach der Installation der opsi Pakete der eigentliche Slave neu gejoined?
Der Opsi-Slave-DC wurde nach der Installation nicht neu gejoined, aber es wurden wie in der Anleitung beschrieben per
univention-run-join-scripts
die Opsi-Join-Scripts ausgeführt. Wenn weitere Infos oder Tests gewünscht sind, wirke ich gerne mit.
Beste grüße
Gerd Wilhelm
Re: opsi4ucs: join schlägt fehl, auch ucs v. 2.4.0
Verfasst: 18 Feb 2011, 16:28
von gerdw
Der Fehler tritt unter ucs Version 2.4.0-0 genauso auf.
Es liegt also nicht an dem Minor Release 2.4.1
Gruss
Gerd Wilhelm
Re: opsi4ucs: join schlägt fehl
Verfasst: 03 Mär 2011, 17:15
von gerdw
Das Problem wurde von Univention identifiziert und ein einfacher Workaround vorgschlagen:
Felix Botner schrieb hier
https://forge.univention.org/bugzilla/s ... i?id=21433:
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.
Re: [gelöst] opsi4ucs: join schlägt fehl
Verfasst: 04 Mär 2011, 12:30
von SirTux
Hallo bei mir funktioniert mit dem Workaround der join zwar auch, aber irgendwie scheint der LDAP des SDCs leer zu sein, so daß z.B. kein anmelden mit Domänenbenutzern möglich ist.
Wie sieht das bei dir aus?
Re: [gelöst] opsi4ucs: join schlägt fehl
Verfasst: 11 Mär 2011, 11:00
von gerdw
SirTux hat geschrieben:Hallo bei mir funktioniert mit dem Workaround der join zwar auch, aber irgendwie scheint der LDAP des SDCs leer zu sein, so daß z.B. kein anmelden mit Domänenbenutzern möglich ist.
Wie sieht das bei dir aus?
Nein, das ist bei mir nicht so.
Ich glaube das Anmelden von Domänenbenutzern an einem SDC auf der Konsole ist standardmäßig aber auch deaktiviert.
Per SSH z.B. sollte es gehe.
Gruss
Gerd
Re: [gelöst] opsi4ucs: join schlägt fehl
Verfasst: 11 Mär 2011, 12:16
von SirTux
Oh entschuldige den Thread hier hatte ich ganz vergessen.
Per SSH hatte ich es auch versucht. Aber daran lag es nicht. Der ganze lokale LDAP war leer. Eine Neuinstallation hat dann das Problem behoben.