Univention Bugzilla – Bug 44976
S4 Connector treats DC Master object as computers/windows_domaincontroller
Last modified: 2017-08-18 16:35:00 CEST
Created attachment 9017 [details] patch As the change requires changes in the S4-Connector as well, we continue working on the issue in this bug. A patch for the S4-Connector is attached. The old behavior of Bug #30368 has temporarily been restored. svn r81065 should be reverted when the S4 Connector is ready. +++ This bug was initially created as a clone of Bug #30368 +++ I tried to use univention.admin.objects.get to retrieve UDM computer objects. The problem was that there might be computer objects of a different kind. Hoping that the get method would handle this by either raising an exception or returning nothing, I called it for a Windows computer object with the UCC computer module without any errors. I was also able to call the open method on this object. I took it a bit further and discovered that it doesn't seem to matter what kind of DN is presented to method: univention.admin.objects.get(computer_module, co, lo, position=position, dn='uid=Administrator,cn=users,' + baseDN) This returned a valid UCC object although it's user's object. It would be very helpful to have some error handling for this method. At least the lookup method for finding objects makes sure I only get objects of the kind I was asking for. As far as I know a DN can't be fed to lookup but maybe there is a better way of how to open an object for a known DN that I'm not aware of.
The real reason in the S4 Connector seems to be Bug #35559. Some UDM objects are treated as computer/windows_domaincontroller objects while they are e.g. computers/domaincontroller_master.
There are some function: add_in_ucs(self, property_type, object, module, position) modify_in_ucs(self, property_type, object, module, position) move_in_ucs(self, property_type, object, module, position) delete_in_ucs(self, property_type, object, module, position) They all have a parameter "module" which is always unused because they determine the module again… They are all only called from sync_to_ucs() where the old broken logic is still used. In sync_to_ucs is already code to get the (old) ucs object, using the new working logic. We can simply use the already determined module type. We can adjust the logic there and simplify the whole code by evaluating this parameter. Also the DNS module specified dns/dns as module without specifying the types. Both has been fixed in: univention-s4-connector (11.0.7-14): r81167 | Bug #44976: add dns subtypes to ucs_module_others r81166 | Bug #44976: fix identification of UCS module type r81122 | Bug #44976: fix detection of UDM object type univention-s4-connector.yaml: r81123 | YAML Bug #44976
This looks very good now. The only traceback which is still in the S4-Connector log is: 17.07.2017 04:58:44,255 LDAP (ERROR ): get_ucs_object: could not identify UDM object type: cn=qwertzu,dc=AutoTest091,dc=local 17.07.2017 04:58:44,255 LDAP (PROCESS): get_ucs_object: using default: computers/windows 17.07.2017 04:58:44,256 LDAP (WARNING): get_ucs_object: failure was: 17.07.2017 04:58:44,256 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 923, in get_ucs_object ucs_object = univention.admin.objects.get(module, co=None, lo=self.lo, position='', dn=searchdn) File "/usr/lib/pymodules/python2.7/univention/admin/objects.py", line 90, in get raise univention.admin.uexceptions.wrongObjectType('The object %s is not a %s.' % (dn, module.module,)) wrongObjectType: The object cn=qwertzu,dc=AutoTest091,dc=local is not a computers/windows. 17.07.2017 04:58:44,256 LDAP (PROCESS): sync to ucs: [windowscomputer] [ delete] cn=qwertzu,dc=AutoTest091,dc=local 17.07.2017 04:58:44,257 LDAP (WARNING): Object to delete doesn't exsist, ignore (cn=qwertzu,dc=AutoTest091,dc=local)
Looks like this comes from the test case: 66_udm-computers/55_nameserver_update_in_zone_on_delete
(In reply to Florian Best from comment #4) > Looks like this comes from the test case: > 66_udm-computers/55_nameserver_update_in_zone_on_delete The test case is just bad as it uses the same object-name/DN for creating and removing a lot of computer names. This is just a race condition and breaks nothing. The identify() function of dns.py has been removed as it wrongly identified all objects as dns/dns. Now the DNS object types are specified in the mapping as udm_modules_other. univention-s4-connector (11.0.7-16): r81220 | Bug #44976: simplify code r81219 | Bug #44976: remove now unused dns/dns identify() function r81180 | Bug #44976: don't use identify() function of dns.py anymore r81179 | Bug #44976: remove unnecessary code redundancy
Additional commits: r81361, r81362 * Code review: Ok * Functional test: Ok * CI Tests: Ok * Advisory: Ok
<http://errata.software-univention.de/ucs/4.2/114.html>
(In reply to Florian Best from comment #5) > r81219 | Bug #44976: remove now unused dns/dns identify() function > r81180 | Bug #44976: don't use identify() function of dns.py anymore One customer had local changes in the s4 connector mapping file. The identify function was still referenced. Thus, the connector didn't start anymore.
(In reply to Stefan Gohmann from comment #8) > (In reply to Florian Best from comment #5) > > r81219 | Bug #44976: remove now unused dns/dns identify() function > > r81180 | Bug #44976: don't use identify() function of dns.py anymore > > One customer had local changes in the s4 connector mapping file. The > identify function was still referenced. Thus, the connector didn't start > anymore. → Bug #45220