Bug 46919 - Warn the user, when creating DC machine-objects at the wrong LDAP position
Warn the user, when creating DC machine-objects at the wrong LDAP position
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
UCS 4.3
Other Linux
: P5 enhancement (vote)
: UCS 4.4-0-errata
Assigned To: Florian Best
Johannes Keiser
:
: 36651 (view as bug list)
Depends on:
Blocks: 49028
  Show dependency treegraph
 
Reported: 2018-05-02 12:42 CEST by Richard Ulmer
Modified: 2019-07-25 18:45 CEST (History)
5 users (show)

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Ulmer univentionstaff 2018-05-02 12:42:07 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.
Comment 1 Arvid Requate univentionstaff 2018-05-02 14:25:18 CEST
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.
Comment 2 Florian Best univentionstaff 2019-03-01 21:56:30 CET
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. ?!
Comment 3 Florian Best univentionstaff 2019-03-10 16:28:08 CET
*** Bug 36651 has been marked as a duplicate of this bug. ***
Comment 4 Florian Best univentionstaff 2019-03-10 16:28:45 CET
(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.
Comment 5 Florian Best univentionstaff 2019-03-11 20:15:57 CET
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?
Comment 6 Florian Best univentionstaff 2019-03-18 14:25:07 CET
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
Comment 7 Daniel Tröder univentionstaff 2019-03-18 14:56:21 CET
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().
Comment 8 Florian Best univentionstaff 2019-03-18 15:18:51 CET
(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.
Comment 9 Florian Best univentionstaff 2019-03-20 10:41:56 CET
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.
Comment 10 Florian Best univentionstaff 2019-03-20 15:10:31 CET
As discussed: The combobox doesn't jump arround anymore when changing the type.
Comment 11 Johannes Keiser univentionstaff 2019-03-20 19:50:59 CET
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
Comment 12 Florian Best univentionstaff 2019-03-21 12:51:03 CET
(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.
Comment 13 Johannes Keiser univentionstaff 2019-03-26 15:49:40 CET
OK: join-script
OK: postinst
OK: udm-cli
OK: UDM UMC
OK: Dialog
OK: YAML (d37537c8fa)
-> verified