Bug 44976 - S4 Connector treats DC Master object as computers/windows_domaincontroller
S4 Connector treats DC Master object as computers/windows_domaincontroller
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.2
Other Linux
: P3 minor (vote)
: UCS 4.2-1-errata
Assigned To: Florian Best
Arvid Requate
:
Depends on: 35559 40839
Blocks: 30368
  Show dependency treegraph
 
Reported: 2017-07-11 22:39 CEST by Florian Best
Modified: 2017-08-18 16:35 CEST (History)
8 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.091
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Ticket number:
Bug group (optional): Cleanup, Troubleshooting, Usability
Max CVSS v3 score:
best: Patch_Available+


Attachments
patch (1.43 KB, patch)
2017-07-11 22:39 CEST, Florian Best
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2017-07-11 22:39:26 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.
Comment 1 Florian Best univentionstaff 2017-07-11 22:45:34 CEST
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.
Comment 2 Florian Best univentionstaff 2017-07-14 09:38:54 CEST
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
Comment 3 Florian Best univentionstaff 2017-07-17 12:10:31 CEST
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)
Comment 4 Florian Best univentionstaff 2017-07-17 12:13:16 CEST
Looks like this comes from the test case:
66_udm-computers/55_nameserver_update_in_zone_on_delete
Comment 5 Florian Best univentionstaff 2017-07-18 16:10:47 CEST
(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
Comment 6 Arvid Requate univentionstaff 2017-07-26 13:11:10 CEST
Additional commits: r81361, r81362

* Code review: Ok
* Functional test: Ok
* CI Tests: Ok
* Advisory: Ok
Comment 7 Erik Damrose univentionstaff 2017-07-26 14:39:41 CEST
<http://errata.software-univention.de/ucs/4.2/114.html>
Comment 8 Stefan Gohmann univentionstaff 2017-08-18 16:28:19 CEST
(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.
Comment 9 Florian Best univentionstaff 2017-08-18 16:35:00 CEST
(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