Univention Bugzilla – Bug 46919
Warn the user, when creating DC machine-objects at the wrong LDAP position
Last modified: 2019-07-25 18:45:10 CEST
At the moment an unknowing user can create domain controller machine-objects in the LDAP, using UDM, that are not located under cn=dc,cn=computers,$LDAP_BASE. This will provoke unexpected errors later on, e.g. when executing univention-join. The UDM tool could show a warning, when creating computers/domaincontroller_backup, computers/domaincontroller_master or computers/domaincontroller_slave objects, that are not located under cn=dc,cn=computers,$LDAP_BASE.
I think python-udm could provide warning information as part of the return code of an operation. That way, it could also be shown in UMC.
We could do this in a generic way by checking if the created object is underneath of one of the default containers. If not, add the warning. ?!
*** Bug 36651 has been marked as a duplicate of this bug. ***
(In reply to Florian Best from comment #3) > *** Bug 36651 has been marked as a duplicate of this bug. *** Or we should consider creating those objects in the default position by default.
This should be fixed in UDM-CLI and UDM-UMC both! It would be good to create a warning for unknown containers and we should also prevent that DC are created by default in the wrong containers (in UMC). Currently we only have default containers for computers and cannot differentiate the actual computer type. Should we adapt containers to have a "domain controller computers" default container flag? Or should we manually remove cn=computers,base from the default computers when the selected type is a DC?
Instead of a warning default containers for DC objects have been introduced. Therefore via UMC the cn=computers container is not displayed anymore for DC objects (Slave, Master, Backup, Windows DC). During the upgrade the default container object is modified so that it includes all current default containers for computers except the one for memberservers and the generic one. The UDM CLI only displays a warning if objects are created in the ldap base and the module has a default container. For UCS@school a separate bug has been opened: univention-ldap (15.0.0-16) 5a2793cd9126 | Bug #46919: upgrade default domain controller containers 4171cfc9a558 | Bug #46919: extend schema for default domaincontroller path 90b3660f1787 | Bug #46919: Merge branch 'fbest/46919-dc-computer-default-container' into 4.4-0 5faf2f051298 | Bug #46919: add default containers for DC computers univention-management-console-module-udm (9.0.11-6) 90b3660f1787 | Bug #46919: Merge branch 'fbest/46919-dc-computer-default-container' into 4.4-0 5faf2f051298 | Bug #46919: add default containers for DC computers b0e4e562cc94 | Bug #46919: prepare form for handling different default containers depending on the object type 6cc40c1f2696 | Bug #46919: unify the use of default containers univention-directory-manager-modules (14.0.12-12) 90b3660f1787 | Bug #46919: Merge branch 'fbest/46919-dc-computer-default-container' into 4.4-0 5faf2f051298 | Bug #46919: add default containers for DC computers e838dcb3162b | Bug #46919: add warning when creating objects in the LDAP base and the object type is not in the default containers 6cc40c1f2696 | Bug #46919: unify the use of default containers 4171cfc9a558 | Bug #46919: extend schema for default domaincontroller path univention-management-console-module-udm.yaml univention-ldap.yaml univention-directory-manager-modules.yaml
Please check if the new high level UDM Python API can also make use of the new code. It already has code to put new computer objects into the correct containers by default. But it may not be consistent or can maybe be made simpler by using get_default_containers(). Please take a look at * ComputersDCModule._get_default_object_positions() * ComputersMemberModule._get_default_object_positions() Other UDM modules use GenericModule._get_default_object_positions() → GenericModule._get_default_containers().
(In reply to Daniel Tröder from comment #7) > Please check if the new high level UDM Python API can also make use of the > new code. > > It already has code to put new computer objects into the correct containers > by default. > But it may not be consistent or can maybe be made simpler by using > get_default_containers(). > > Please take a look at > * ComputersDCModule._get_default_object_positions() > * ComputersMemberModule._get_default_object_positions() > > Other UDM modules use GenericModule._get_default_object_positions() → > GenericModule._get_default_containers(). The changes have been ported to the univention.udm lib.
I added a comment to execute joinscript again into the postinst of univention-ldap-config in case the migration fails in the postinst. I didn't put the code into 10univention-ldap-server joinscript because force-reexecuting this would set a new machine password. So I added it into the UDM joinscript: univention-run-join-scripts --force --run-scripts 18python-univention-directory-manager.inst The code there checks if the attribute is empty as pre condition to set the values.
As discussed: The combobox doesn't jump arround anymore when changing the type.
Using the keyboard to navigate between the choices of the ComboBox causes following error: objectType::onChange() triggers, which calls container::dynamicValues(), which causes objectType::dynamicValues() due to depends on 'container' The current drop-down list is not valid anymore after objectType::dynamicValues() since it has new values. The user can't select any value from the drop-down list anymore
(In reply to Johannes Keiser from comment #11) > Using the keyboard to navigate between the choices of the ComboBox causes > following error: > > objectType::onChange() triggers, > which calls container::dynamicValues(), > which causes objectType::dynamicValues() due to depends on 'container' > > The current drop-down list is not valid anymore after > objectType::dynamicValues() since it has new values. The user can't select > any value from the drop-down list anymore Okay, I fixed the circular dependency problem by removing the dependency from objectType → container. This was only needed in the past but with the adjustments during the DNS/DHCP cleanup, the values are directly used from the tree. The UMC form has been adapted to display progress animations during the (re)loading of dynamic values (in case you give a standbyDuring method to the form). This is basically the base to fix Bug #29423.
OK: join-script OK: postinst OK: udm-cli OK: UDM UMC OK: Dialog OK: YAML (d37537c8fa) -> verified
<http://errata.software-univention.de/ucs/4.4/18.html> <http://errata.software-univention.de/ucs/4.4/19.html> <http://errata.software-univention.de/ucs/4.4/22.html> <http://errata.software-univention.de/ucs/4.4/27.html>