Univention Bugzilla – Bug 21126
Bei abweichendem Namensschema wird zusätzliches SchulDC-Objekt wird angelegt
Last modified: 2013-06-07 21:40:36 CEST
Ein Kunde hat ein abweichendes Namensschema für SchulDCs ("dcfoobar" statt "dcfoobar-01"). Beim Importieren von Rechnern für die OU "foobar" wird beim Konsistenzcheck für die OU der SchulDC "dcfoobar-01" im LDAP erstellt. Möglicher Fix: Außer beim Aufruf von create_ou werden keine SchulDC-Objekte erstellt.
(In reply to comment #0) > Möglicher Fix: > Außer beim Aufruf von create_ou werden keine SchulDC-Objekte erstellt. Dieser Fix hätte den Nachteil, dass für den Benutzer nicht mehr transparent ist was ein impliziter Aufruf genau macht. Beispielsweise ist ein häufiges Vorgehen beim Importieren einer neuen Schule zuerst das Netz zu importieren. Durch den impliziten Aufruf von create_ou werden dabei alle notwendigen Container generiert. Dies würde mit dem beschriebenen Fix nicht mehr funktionieren.
(In reply to comment #1) > Dieser Fix hätte den Nachteil, dass für den Benutzer nicht mehr transparent ist > was ein impliziter Aufruf genau macht. Beispielsweise ist ein häufiges Vorgehen > beim Importieren einer neuen Schule zuerst das Netz zu importieren. Durch den > impliziten Aufruf von create_ou werden dabei alle notwendigen Container > generiert. Dies würde mit dem beschriebenen Fix nicht mehr funktionieren. Die notwendigen Container für Gruppen, User, usw. werden ja weiterhin erstellt. Nur haben wir derzeit keine Möglichkeit, das Namensschema für SchulDCs zu definieren. Ggf. könnten wir das über eine UCR-Variable abbilden z.B. ucsschool/ldap/dc/namescheme="dc%(ou)s-01" Alternativ werden DC-Objekte nur dann erstellt, wenn noch kein DC-Objekt für die OU existiert. Damit hat der Admin mit abweichendem Namensschema die Möglichkeit, per "./create_ou 123 meinDCname" eine OU mit abweichendem DC anzulegen, während der Admin mit Standard-Namensschema gleich mit dem Import von Netzen beginnen kann. Bei abweichendem Schema wird durch ein späteres "./import_computer <file>" dann kein zusätzliches/unnützes DC-Objekt angelegt, weil schon eins existiert.
Report from customer at <http://forum.univention.de/viewtopic.php?f=44&t=2597> I think this gets more important now because users are now able to choose their desired DC name via the UMC wizard (so it's more likely that they choose a different naming scheme)
> Alternativ werden DC-Objekte nur dann erstellt, wenn noch kein DC-Objekt für > die OU existiert. Damit hat der Admin mit abweichendem Namensschema die > Möglichkeit, per "./create_ou 123 meinDCname" eine OU mit abweichendem DC > anzulegen, während der Admin mit Standard-Namensschema gleich mit dem Import > von Netzen beginnen kann. Bei abweichendem Schema wird durch ein späteres > "./import_computer <file>" dann kein zusätzliches/unnützes DC-Objekt angelegt, > weil schon eins existiert. Sofern kein Slavename an create_ou übergeben wird, erstellt create_ou bzw. die verify_ou-Funktion nur noch dann Default-Slave-Objekte, wenn in der Gruppe "OU${OU}-DC-Edukativnetz" keine Member enthalten sind bzw. die Gruppe nicht existiert. D.h. bei einem "create_ou foo" wird die OU "foo" mit dem DC "dcfoo-01" erstellt, bei einem "create_ou bar myslave" wird die OU "bar" mit dem DC "myslave" erstellt. Ein späteres "create_ou foo" bzw. "create_ou bar" erstellt keine weiteren DC-Objekte unterhalb der OU. Sofern ein Slavename als zweiter Parameter angegeben wird, wird dieser weiterhin erstellt und der OU-Zugriffsgruppe hinzugefügt. Changelog entry has been made. ucs-school-import (9.0.11-1) unstable; urgency=low
(In reply to comment #4) > Sofern kein Slavename an create_ou übergeben wird, erstellt create_ou bzw. die > verify_ou-Funktion nur noch dann Default-Slave-Objekte, wenn in der Gruppe > "OU${OU}-DC-Edukativnetz" keine Member enthalten sind bzw. die Gruppe nicht > existiert. > D.h. bei einem "create_ou foo" wird die OU "foo" mit dem DC "dcfoo-01" > erstellt, > bei einem "create_ou bar myslave" wird die OU "bar" mit dem DC "myslave" > erstellt. > Ein späteres "create_ou foo" bzw. "create_ou bar" erstellt keine weiteren > DC-Objekte unterhalb der OU. > > Sofern ein Slavename als zweiter Parameter angegeben wird, wird dieser > weiterhin erstellt und der OU-Zugriffsgruppe hinzugefügt. Der Bug konnte mit UCS@school 3.1 reproduziert werden und tritt in R2 nicht mehr auf. Das Verhalten ist exakt so, wie im o.g. Text beschrieben. Changelog ist vorhanden. Verified!
UCS@school 3.1 R2 has been released: http://download.univention.de/doc/release-notes-ucsschool-3.1-rev2.pdf If this error occurs again, please use "Clone This Bug".