Bug 50336 - Fix subtree removal in S4-Connector
Fix subtree removal in S4-Connector
Status: NEW
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: Samba maintainers
Samba maintainers
:
: 50542 (view as bug list)
Depends on: 49956
Blocks:
  Show dependency treegraph
 
Reported: 2019-10-10 10:05 CEST by Florian Best
Modified: 2022-03-15 09:35 CET (History)
2 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: 0.103
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 Florian Best univentionstaff 2019-10-10 10:05:15 CEST
The subtree removal in both directions (S4 → UCS, UCS → S4) is wrong.

Bug #49956 enhanced (?) the situation and changed/fixed the identification of objects but added workarond for wrong calls to sync_from_ucs().

sync_from_ucs() must be called with a ucs_object but is called with a samba_object definition.

sync_to_ucs() must be called with a samba_object but is called with a ucs_object definition.

This was analyzed in Bug #49324 comment 8 and their followups.

We should fix the calls or implement a different subtree removal strategy.
We should revert the workarounds from Bug #49956, so that the data is consistent again (e.g. removal of DNs from some caches and lockingdb)
We should fix the endless recursion if there is one object in the subtree which cannot be removed (due to ignore-filter, non-UDM/S4-identifyable, etc.).

+++ This bug was initially created as a clone of Bug #49956 +++
Comment 1 Florian Best univentionstaff 2019-10-10 12:49:54 CEST
Related Bug #50282. Maybe also caused by this bug.
Comment 2 Florian Best univentionstaff 2019-10-10 12:50:39 CEST
(In reply to Florian Best from comment #1)
> Related Bug #50282. Maybe also caused by this bug.
And maybe the reason why we didn't yet expericence the endless loop?
Comment 3 Florian Best univentionstaff 2019-10-10 16:57:42 CEST
Bug #47343: For DNS objects no handling is defined at all. Maybe it can use a generic implementation.
Comment 4 Florian Best univentionstaff 2019-11-26 16:12:38 CET
*** Bug 50542 has been marked as a duplicate of this bug. ***
Comment 5 Florian Best univentionstaff 2019-11-26 16:13:24 CET
(In reply to Florian Best from comment #4)
> *** Bug 50542 has been marked as a duplicate of this bug. ***

add OU=myou,DC=four,DC=four 

add 
 dn: CN=my,OU=myou,DC=four,DC=four 
 objectClass: oncRpc
 cn: my
 oncRpcNumber: 1
to samba

rm ou=myou via udm 

 udm container/ou  remove  --dn "ou=myou,dc=four,dc=four"

/var/log/univention/connector-s4.log:

25.11.2019 17:55:28.477 LDAP        (WARNING): Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 891, in __sync_file_from_ucs
    if ((old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, unicode(old_dn, 'utf8'), old, new)) or (not old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, old_dn, old, new))):
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/s4/__init__.py", line 2613, in sync_from_ucs
    self.delete_in_s4(object, property_type)
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/s4/__init__.py", line 2649, in delete_in_s4
    if self._remove_subtree_in_s4(object, property_type):
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/s4/__init__.py", line 2682, in _remove_subtree_in_s4
    if not self.sync_from_ucs(key, subobject_s4, back_mapped_subobject['dn']):
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/s4/__init__.py", line 2301, in sync_from_ucs
    if self.property[property_type].sync_mode in ['read', 'none']:
KeyError: None