Bug 40380 - DNS wildcard hosts are no longer synchronized
DNS wildcard hosts are no longer synchronized
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.0
Other Linux
: P5 normal (vote)
: UCS 4.1-0-errata
Assigned To: Arvid Requate
Felix Botner
Depends on:
Blocks: 40381
  Show dependency treegraph
Reported: 2016-01-07 07:22 CET by Stefan Gohmann
Modified: 2016-01-13 13:09 CET (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
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:


Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2016-01-07 07:22:01 CET
DNS wildcard hosts are no longer synchronized from OpenLDAP to Samba 4. The customer tested with an old connector version and it works with the old version: 9.0.16-40.571.201508061242

Old connector:
06.01.2016 20:17:09,445 LDAP        (PROCESS): sync from ucs: [           dns] [    modify]
06.01.2016 20:17:10,687 LDAP        (PROCESS): sync from ucs: [           dns] [    modify] dc=@,dc=joomla.XXX.XXX.de,cn=microsoftdns,cn=system,DC=XXX,DC=XXX,DC=de

New connector:
06.01.2016 20:15:20,584 LDAP        (PROCESS): sync from ucs: [           dns] [    modify] DC=@,dc=joomla.XXX.XXX.de,cn=microsoftdns,cn=system,DC=XXX,DC=XXX,DC=de
06.01.2016 20:15:20,697 LDAP        (PROCESS): sync from ucs: [           dns] [    modify] DC=@,dc=joomla.XXX.XXX.de,cn=microsoftdns,cn=system,DC=XXX,DC=XXX,DC=de

Ticket #2016010621000623
Comment 1 Stefan Gohmann univentionstaff 2016-01-07 07:22:43 CET
It is an critical problem for the customer.
Comment 2 Arvid Requate univentionstaff 2016-01-07 17:22:57 CET
Fixed: properly escape special characters in the LDAP search filters

New ucs-test case: tests/52_s4connector/175sync_create_dns_wildcard_host

Advisory: univention-s4-connector.yaml
Comment 3 Felix Botner univentionstaff 2016-01-11 16:35:20 CET
OK - ucs-test
OK - univention-s4-connector
OK - univention-s4-connector.yaml
Comment 4 Felix Botner univentionstaff 2016-01-11 17:32:29 CET
Create a dns host record in openldap:

DN: relativeDomainName=*,zoneName=four.one,cn=dns,dc=four,dc=one
ARG: None
  name: *
  zonettl: 3 hours

Then i updated the connector, now i get the following error:

11.01.2016 17:28:09,41 LDAP        (PROCESS): sync to ucs: Resync rejected dn: DC=_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones,DC=four.one,CN=MicrosoftDNS,DC=DomainDnsZones,DC=four,DC=one
11.01.2016 17:28:09,46 LDAP        (PROCESS): sync to ucs:   [           dns] [    modify] relativedomainname=*,zonename=four.one,cn=dns,dc=four,dc=one
11.01.2016 17:28:09,49 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
11.01.2016 17:28:09,50 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1438, in sync_to_ucs
    result = self.property[property_type].ucs_sync_function(self, property_type, object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 1456, in con2ucs
    ucs_srv_record_create(s4connector, object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 1069, in ucs_srv_record_create
    newRecord= univention.admin.handlers.dns.srv_record.object(None, s4connector.lo, position=None, dn=searchResult[0][0], superordinate=superordinate, attributes=[], update_zone=False)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/dns/srv_record.py", line 145, in __init__
    univention.admin.handlers.simpleLdap.__init__(self, co, lo, position, dn, superordinate, attributes = attributes )
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 570, in __init__
    oldinfo=univention.admin.mapping.mapDict(self.mapping, self.oldattr)
  File "/usr/lib/pymodules/python2.7/univention/admin/mapping.py", line 219, in mapDict
    v=mapping.unmapValue(key, value)
  File "/usr/lib/pymodules/python2.7/univention/admin/mapping.py", line 199, in unmapValue
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/dns/srv_record.py", line 99, in unmapName
    items[ 1 ] = items[ 1 ][ 1 : ]
IndexError: list index out of range

-> univention-s4connector-list-rejected 

UCS rejected

S4 rejected

    1:    S4 DN: DC=_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones,DC=four.one,CN=MicrosoftDNS,DC=DomainDnsZones,DC=four,DC=one
         UCS DN: relativedomainname=*,zonename=four.one,cn=dns,dc=four,dc=one

        last synced USN: 3849
Comment 5 Arvid Requate univentionstaff 2016-01-11 17:47:20 CET
Hmm, that's because the S4-Connector has remembered the previous match it obtained from the relativedomainname=* wildcard search. The connector-s4.log shows:

11.01.2016 17:32:40,652 LDAP        (INFO   ): object_from_element: olddn: DC=_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones,DC=four.one,CN=MicrosoftDNS,DC=DomainDns
11.01.2016 17:32:40,653 LDAP        (INFO   ): _object_mapping: map with key dns and type con
11.01.2016 17:32:40,654 LDAP        (INFO   ): _dn_type con
11.01.2016 17:32:40,654 LDAP        (INFO   ): dns_dn_mapping: check newdn for key 'dn'
11.01.2016 17:32:40,655 LDAP        (INFO   ): dns_dn_mapping: premapped UCS object: relativeDomainName=*,zoneName=four.one,cn=dns,dc=four,dc=one

This can be fixed manually by stopping the S4-Connector and doing this:

root@master:~# sqlite3 /etc/univention/connector/s4internal.sqlite "select * from 'DN Mapping CON' where Value='relativedomainname=*,zonename=four.one,cn=dns,dc=four,dc=one'"


root@master:~# sqlite3 /etc/univention/connector/s4internal.sqlite "delete from 'DN Mapping CON' where Value='relativedomainname=*,zonename=four.one,cn=dns,dc=four,dc=one'"

After that the S4-Connector can be restarted again.
Comment 6 Arvid Requate univentionstaff 2016-01-11 18:06:32 CET
I created Bug 40414 to fix the source of this issue but I guess we have to live with the workaround for the time being.
Comment 7 Felix Botner univentionstaff 2016-01-11 18:33:07 CET
OK, workaround works.
Comment 8 Janek Walkenhorst univentionstaff 2016-01-13 13:09:01 CET