Bug 49728
| Summary: | Renaming DNS host record does not delete old object in Samba/AD | ||
|---|---|---|---|
| Product: | UCS | Reporter: | Christian Völker <voelker> |
| Component: | S4 Connector | Assignee: | Julia Bremer <bremer> |
| Status: | CLOSED FIXED | QA Contact: | Florian Best <best> |
| Severity: | normal | ||
| Priority: | P5 | CC: | best, bremer, fels, gohmann, requate, steuwer, thomas |
| Version: | UCS 4.4 | ||
| Target Milestone: | UCS 4.4-2-errata | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| See Also: | https://forge.univention.org/bugzilla/show_bug.cgi?id=49874 | ||
| What kind of report is it?: | Bug Report | What type of bug is this?: | 5: Major Usability: Impairs usability in key scenarios |
| Who will be affected by this bug?: | 3: Will affect average number of 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.171 | Enterprise Customer affected?: | Yes |
| School Customer affected?: | ISV affected?: | ||
| Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
| Ticket number: | 2019062421000558, 2019092621000503, 2019100221000742, 2019102421000782 | Bug group (optional): | |
| Max CVSS v3 score: | |||
|
Description
Christian Völker
This looks like a general issue of DNS host_record synchronization: udm dns/host_record modify --dn relativeDomainName=foo,zoneName=ar41i1.qa,cn=dns,dc=ar41i1,dc=qa --set name=foo2 Another customer affected Raising priority as the still existing entry obviously does not update the IP address in case the IP address of the renamed computer changes. This results in timeout errors when using the old name (which should instead immediately bring an error NXDOMAIN). Key customer affected. Got the feedback that this probably affects further customers. @Julia: Is this related to Bug #49874? The patch seems at least to fix that as well. (In reply to Florian Best from comment #6) > @Julia: Is this related to Bug #49874? The patch seems at least to fix that > as well. Not directly, the traceback from #49874 just broke my new test, which is why I fixed that too. (In reply to Julia Bremer from comment #7) > (In reply to Florian Best from comment #6) > > @Julia: Is this related to Bug #49874? The patch seems at least to fix that > > as well. > > Not directly, the traceback from #49874 just broke my new test, which is why > I fixed that too. So the changes would work without Bug #49874 but the test case would fail?! Hm, I think in this case we should explicitly fix Bug #49874 instead. Julia and I further analyzed the code:
self.sync_from_ucs() is called where object is `mapped_object = self._object_mapping(key, object, 'ucs')`.
_object_mapping() already calls dn_mapping_function() (and self._subtree_replace()).
Therefore object['olddn'] contains a DN from the sqlite cache (get_dn_by_ucs()) which is the correctly mapped olddn of the S4-object.
So I guess we can just use this and remove the function calls for the detection of a move operation:
diff --git services/univention-s4-connector/modules/univention/s4connector/s4/__init__.py services/univention-s4-connector/modules/univention/s4connector/s4/__init__.py
index 1a78fa437f..e744e1fe43 100644
--- services/univention-s4-connector/modules/univention/s4connector/s4/__init__.py
+++ services/univention-s4-connector/modules/univention/s4connector/s4/__init__.py
@@ -2304,16 +2304,7 @@ class s4(univention.s4connector.ucs):
# check for move, if old_object exists, set modtype move
pre_mapped_ucs_old_dn = old_dn
if old_dn:
- if hasattr(self.property[property_type], 'dn_mapping_function'):
- tmp_object = copy.deepcopy(object)
- tmp_object['dn'] = old_dn
- for function in self.property[property_type].dn_mapping_function:
- tmp_object = function(self, tmp_object, [], isUCSobject=True)
- old_dn = tmp_object['dn']
- if hasattr(self.property[property_type], 'position_mapping'):
- for mapping in self.property[property_type].position_mapping:
- old_dn = self._subtree_replace(old_dn.lower(), mapping[1].lower(), mapping[0].lower())
- old_dn = self._subtree_replace(old_dn, self.lo.base, self.lo_s4.base)
+ old_dn = object['olddn']
# the old object was moved in UCS, but does this object exist in S4?
try:
old_object = self.s4_search_ext_s(compatible_modstring(old_dn), ldap.SCOPE_BASE, 'objectClass=*')
In a quick test this works. A branch test is running: https://jenkins.knut.univention.de:8181/job/UCS-4.4/job/UCS-4.4-2/view/Product%20Tests/job/product-test-samba-s4-connector/8/console
Unfortionately I cannot see the beyond the CVS history of why this second mapping was introduced.
8745a195a3 Bug #49728: yaml 1034645bbd Bug #49728: Version bump 940adbe79c Bug #49728: Added testcase move_dns_host_record 7eb78b60ed Bug #49728: Fix newdn instead of olddn is mapped in case of move Package: univention-s4-connector Version: 13.0.2-56A~4.4.0.201910281739 Branch: ucs_4.4-0 Scope: errata4.4-2 OK: dns/host_record OK: dns/txt_record OK: dns/srv_record OK: dns/alias OK: dns/ns_record OK: dns/ptr_record (except if I set adress to something non-digital) OK: ucs-test case (could include all types, could be written in python) OK: works if I remove the object from the sqlite tables 'DN Mapping UCS', 'DN Mapping CON' ~OK: YAML (I adapted the wording a little bit) |