Univention Bugzilla – Bug 39060
S4-Connector currently doesn't support renaming of DNS objects
Last modified: 2019-01-03 07:17:52 CET
The S4-Connector currently doesn't support renaming of DNS objects. The effect seems to be, that a new object is created and the old one is not removed. So you end up with both on the target directory. Tested with a host record, renamed via UDM -> two objects in S4 (old and new). Same in the other direction (tested with ldbrename). Tested with a package version before the changes of Bug 34184 (erratalevel 263).
Created attachment 9228 [details] 39060-s4c-rename-dns-duplicate-422.patch The problem seems to be, that we map the `old_dn` in `sync_from_ucs()` if we detected a "move" and have a `dn_mapping_function` (both cases apply here). The problem is, that `object` as given to `sync_from_ucs()` is already mapped from the original (and moved!) UCS object. So setting `tmp_object['dn'] = old_dn` and performing the DN-mapping fails, as the custom DNS-DN-mapping uses the objects attributes. Which again: are the mapped ones from the new UCS object. The fix is, to not use the attributes the DNS-DN-mapping (relativeDomainName, zoneName), but extract them from the given (old) DN. The attached patch tags all s4c dns tests with `s4c_dns` and adds a new test 503_test_dns_rename.py. Also the issue is fixed. See also branch `loyen/39060-s4c-rename-dns-duplicate-422`.
This issue has been filled against UCS 4.0. The maintenance with bug and security fixes for UCS 4.0 has ended on 31st of May 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.