Werr_ds_obj_string_name_exists

Donald · March 17, 2017, 7:01am

Hallo!

Mein neuer UCS-Server zeigt im Syslog einen merkwürdigen Fehler:

named[3053]: samba_dlz: starting transaction on zone _msdcs.domain.zz
named[3053]: samba_dlz: allowing update of signer=SERVER\$\@domain.ZZ name=gc._msdcs.domain.zz tcpaddr=192.168.72.199 type=A key=2439840844.sig-SERVER.domain.zz/160/0
named[3053]: client 192.168.72.199#41212: updating zone '_msdcs.domain.zz/NONE': adding an RR at 'gc._msdcs.domain.zz' A
named[3053]: samba_dlz: failed to modify DC=gc,DC=_msdcs.domain.zz,CN=MicrosoftDNS,DC=ForestDnsZones,DC=domain,DC=zz - WERR_DS_OBJ_STRING_NAME_EXISTS
named[3053]: samba_dlz: cancelling transaction on zone _msdcs.domain.zz

Diese Meldung kommt ca. alle 30 Minuten. Muss ich mir da Sorgen machen?
Bisher wird der Server noch nicht produktiv benutzt. Im Testlauf ist mir nichts weiter aufgefallen.

Grandjean · March 17, 2017, 7:01am

Hallo,

für mich sieht das so aus, als wolle der Server sich selbst als Global Catalog Server (gc) im DNS eintragen, offenbar steht er da aber schon drin (OBJ_STRING_NAME_EXISTS). Könntest du einmal folgenden Check ausführen und uns die Ausgabe hier mitteilen?

/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh

Schönen Gruß,
Michael

Donald · March 17, 2017, 7:02am

Hier das Ergebnis:

Host gc._msdcs not found: 3(NXDOMAIN)
_gc._tcp.DOMAIN.zz has SRV record 0 100 3268 SERVER.DOMAIN.zz.
_gc._tcp.DOMAIN.zz has SRV record 0 100 3268 dc-backup.DOMAIN.zz.
_ldap._tcp.gc._msdcs.DOMAIN.zz has SRV record 0 100 3268 dc-backup.DOMAIN.zz.
_ldap._tcp.gc._msdcs.DOMAIN.zz has SRV record 0 100 3268 SERVER.DOMAIN.zz.
_ldap._tcp.DOMAIN.zz has SRV record 0 100 389 dc-backup.DOMAIN.zz.
_ldap._tcp.DOMAIN.zz has SRV record 0 100 389 SERVER.DOMAIN.zz.
_ldap._tcp.dc._msdcs.DOMAIN.zz has SRV record 0 100 389 dc-backup.DOMAIN.zz.
_ldap._tcp.dc._msdcs.DOMAIN.zz has SRV record 0 100 389 SERVER.DOMAIN.zz.
_ldap._tcp.pdc._msdcs.DOMAIN.zz has SRV record 0 100 389 SERVER.DOMAIN.zz.
_ldap._tcp.f0bce457-62ae-4e2c-b919-d556b5525566.domains._msdcs.DOMAIN.zz has SRV record 0 100 389 SERVER.DOMAIN.zz.
_ldap._tcp.f0bce457-62ae-4e2c-b919-d556b5525566.domains._msdcs.DOMAIN.zz has SRV record 0 100 389 dc-backup.DOMAIN.zz.
_kerberos._tcp.dc._msdcs.DOMAIN.zz has SRV record 0 100 88 SERVER.DOMAIN.zz.
_kerberos._tcp.dc._msdcs.DOMAIN.zz has SRV record 0 100 88 dc-backup.DOMAIN.zz.
_kerberos._tcp.DOMAIN.zz has SRV record 0 100 88 SERVER.DOMAIN.zz.
_kerberos._tcp.DOMAIN.zz has SRV record 0 100 88 dc-backup.DOMAIN.zz.
_kerberos._udp.DOMAIN.zz has SRV record 0 100 88 SERVER.DOMAIN.zz.
_kerberos._udp.DOMAIN.zz has SRV record 0 100 88 dc-backup.DOMAIN.zz.
_kpasswd._tcp.DOMAIN.zz has SRV record 0 100 464 SERVER.DOMAIN.zz.
_kpasswd._tcp.DOMAIN.zz has SRV record 0 100 464 dc-backup.DOMAIN.zz.
_kpasswd._udp.DOMAIN.zz has SRV record 0 100 464 dc-backup.DOMAIN.zz.
_kpasswd._udp.DOMAIN.zz has SRV record 0 100 464 SERVER.DOMAIN.zz.
Located DC 'SERVER' in site 'Default-First-Site-Name'
Located DC 'dc-backup' in site 'Default-First-Site-Name'
0fdb1faa-d839-4c02-9690-f7ba6500f3bc._msdcs.DOMAIN.zz is an alias for SERVER.DOMAIN.zz.
a9245bb8-7fd9-473e-99be-2e37892d834a._msdcs.DOMAIN.zz is an alias for dc-backup.DOMAIN.zz.
## Records for site Default-First-Site-Name:
_ldap._tcp.Default-First-Site-Name._sites.DOMAIN.zz has SRV record 0 100 389 dc-backup.DOMAIN.zz.
_ldap._tcp.Default-First-Site-Name._sites.DOMAIN.zz has SRV record 0 100 389 SERVER.DOMAIN.zz.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN.zz has SRV record 0 100 389 dc-backup.DOMAIN.zz.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN.zz has SRV record 0 100 389 SERVER.DOMAIN.zz.
_kerberos._tcp.Default-First-Site-Name._sites.DOMAIN.zz has SRV record 0 100 88 SERVER.DOMAIN.zz.
_kerberos._tcp.Default-First-Site-Name._sites.DOMAIN.zz has SRV record 0 100 88 dc-backup.DOMAIN.zz.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN.zz has SRV record 0 100 88 SERVER.DOMAIN.zz.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN.zz has SRV record 0 100 88 dc-backup.DOMAIN.zz.
## Optional GC Records for site Default-First-Site-Name:
_gc._tcp.Default-First-Site-Name._sites.DOMAIN.zz has SRV record 0 100 3268 dc-backup.DOMAIN.zz.
_gc._tcp.Default-First-Site-Name._sites.DOMAIN.zz has SRV record 0 100 3268 SERVER.DOMAIN.zz.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.DOMAIN.zz has SRV record 0 100 3268 dc-backup.DOMAIN.zz.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.DOMAIN.zz has SRV record 0 100 3268 SERVER.DOMAIN.zz.
_kerberos.DOMAIN.zz descriptive text "DOMAIN.ZZ"

Grandjean · March 17, 2017, 7:02am

Okay, danke.

das hier deckt sich zumindest mit der Logmeldung von oben:

Der Eintrag existiert nicht, sollte aber da sein. Der SERVER versucht sich da auch einzutragen bzw. den anzulegen, scheitert aber. Dann müssen wir weiter suchen.

Stimmt das DNS Backend (sollte samba4 sein)?

ucr get dns/backend

Gibt es evtl. Rejects beim S4-Connector (also beim Sync zwischen Samba/AD und OpenLDAP)?

univention-s4connector-list-rejected

Und wie sehen die SRV Records aus, wenn man über UMC/UDM drauf guckt (die OpenLDAP-Seite)?

udm dns/srv_record list | grep ^DN:

Donald · March 17, 2017, 7:03am

Hier die Ausgaben

#ucr get dns/backend
samba4


# univention-s4connector-list-rejected

UCS rejected

S4 rejected

    1:    S4 DN: DC=gc,DC=_msdcs.DOMAIN.zz,CN=MicrosoftDNS,DC=ForestDnsZones,DC=DOMAIN,DC=zz
         UCS DN: relativedomainname=gc._msdcs,zonename=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz

        last synced USN: 5042


# udm dns/srv_record list | grep ^DN:
DN: relativeDomainName=_ldap._tcp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_domaincontroller_master._tcp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_kerberos._tcp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_kerberos._udp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_kerberos-adm._tcp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_pkgdb._tcp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.dc._msdcs,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.f0bce457-62ae-4e2c-b919-d556b5525566.domains._msdcs,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_kerberos._tcp.dc._msdcs,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_kpasswd._tcp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_kpasswd._udp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.Default-First-Site-Name._sites,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_kerberos._tcp.Default-First-Site-Name._sites,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_gc._tcp,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.gc._msdcs,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_gc._tcp.Default-First-Site-Name._sites,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.pdc._msdcs,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.DomainDnsZones,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
DN: relativeDomainName=_ldap._tcp.ForestDnsZones,zoneName=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz

Der Server wurde komplett neu eingerichtet: Domain, User etc: alles...

#########

#########
answer
Werr_ds_obj_string_name_exists
Univention Coporate Server (UCS)
2017-03-17T11:13:29.786Z
Grandjean

Danke

Der Reject hier trifft genau das Objekt, um das es geht:

S4 rejected

    1:    S4 DN: DC=gc,DC=_msdcs.DOMAIN.zz,CN=MicrosoftDNS,DC=ForestDnsZones,DC=DOMAIN,DC=zz
         UCS DN: relativedomainname=gc._msdcs,zonename=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz

Evtl. gibt uns die Logdatei da mehr Aufschluss, warum das schief geht. Kannst du bitte die Datei /var/log/univention/connector-s4.log anhängen? Gerne auch nur den letzten Teil, der S4-Connector sollte alle paar Minuten versuchen das Objekt neu zu synchronisieren. Der Eintrag müsste in etwas so eine Zeile enthalten:
sync to ucs: Resync rejected dn: DC=gc,DC=_msdcs.DOMAIN.zz,CN=MicrosoftDNS,DC=ForestDnsZones,DC=DOMAIN,DC=zz
Anschließend müsste ein Python-Traceback kommen, beginnend mit
(ERROR ): Traceback (most recent call last):
Mindestens der Teil wäre relevant.

Donald · March 17, 2017, 7:03am

17.03.2017 12:33:06,827 LDAP (PROCESS): sync to ucs: Resync rejected dn: DC=gc,DC=_msdcs.DOMAIN.zz,CN=MicrosoftDNS,DC=ForestDnsZones,DC=DOMAIN,DC=zz
17.03.2017 12:33:06,831 LDAP (PROCESS): sync to ucs: [ dns] [ modify] relativedomainname=gc._msdcs,zonename=DOMAIN.zz,cn=dns,dc=DOMAIN,dc=zz
17.03.2017 12:33:06,837 LDAP (ERROR ): Unknown Exception during sync_to_ucs
17.03.2017 12:33:06,837 LDAP (ERROR ): Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1472, 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 1638, in con2ucs
ucs_host_record_create(s4connector, object)
File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 979, in ucs_host_record_create
newRecord.modify()
File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 317, in modify
return self.modify(modifychilds, ignore_license=ignore_license)
File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 813, in _modify
self.lo.modify(self.dn, ml, ignore_license=ignore_license)
File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 471, in modify
raise univention.admin.uexceptions.ldapError(err2str(msg), originalexception=msg)
ldapError: Type or value exists: aRecord: value #288 provided more than once

Donald · March 17, 2017, 7:03am

Sieht nicht so aus:

$ univention-s4search -b CN=MicrosoftDNS,DC=ForestDnsZones,$(ucr get ldap/base) DC=gc

record 1

dn: DC=gc,DC=_msdcs.DOMAIN.zz,CN=MicrosoftDNS,DC=ForestDnsZones,DC=DOMAIN,DC=zz
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20170309142102.0Z
uSNCreated: 3685
showInAdvancedViewOnly: TRUE
name: gc
objectGUID: 3e642a9e-367d-4817-aae5-a6a834ba3500
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,DC=DOMAIN,DC=zz
dc: gc
dNSTombstoned: TRUE
whenChanged: 20170321080649.0Z
uSNChanged: 5590

Die Anzahl der dnsRecord scheint aber nicht mehr gewachsen zu sein.

Donald · March 17, 2017, 7:03am

Ich würde noch gerne wissen, ob dieser Bug im Produktivbetrieb stört?
Im Moment wird dieser Server noch eingerichtet, aber ich möchte schon bald umziehen.

Donald · April 4, 2017, 7:01am

ldapError: Type or value exists: aRecord: value #839 provided more than once taucht nach wie vor in connector-s4.log auf.

thorp-hansen · April 4, 2017, 8:02am

Zur Referenz: dieser Bug ist hier gemeint: https://forge.univention.org/bugzilla/show_bug.cgi?id=41190 - der ist leider noch nicht gelöst. Ich könnte mir nur vorstellen, dass der dort angehängte Workaround nicht auf das Objekt angewendet werden kann, das in Ihrem Fall für Probleme sorgt. Wenn das eine Testumgebung ist, könnte man mal den ServiceRecord manuell neu anzulegen versuchen.

Donald · April 4, 2017, 8:14am

Das können wir gerne versuchen. Der Server ist noch unbenutzt. LDAP-Dumps werden nachts gezogen.
Und wie geht das neu anlegen?

Donald · April 20, 2017, 2:02pm

Oder soll ich eher auf 4.2 dpdaten?

thorp-hansen · April 20, 2017, 2:10pm

Huch, die Frage hatte ich übersehen… Der Servicerecord ist ein DNS Objekt. Am einfachsten wird sein über die UMC -> Domäne -> DNS den Record zu “kopieren” und neu anzulegen. Ich glaube eigentlich nicht, dass ein Update genau dieses Problem löst, aber es bringt natürlich weitere Neuheiten, etc. von daher kann ich nicht abraten.

Donald · April 24, 2017, 8:51am

Das Problem scheint weg zu sein. Vorher kam der Fehler alle 10 Minuten, wahrscheinlich ein Cronjob.
Jetzt 2 Stunden nach der Neuerzeugung des Records kommt er nicht mehr.