IPv6 PTR Records und kein Ende

mahescho · February 5, 2018, 7:26pm

Eben musste ich wieder feststellen, dass bei mir der IPv6 Reverselookup nicht funktioniert. Die Zone siehet so aus:

Auswahl_184

Ergebnis:

root@ucs:~# host 2001:1a50:XXXX:2::14
Host 4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.X.X.X.X.X.X.a.1.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)
root@ucs:~# host 2001:1a50:XXXX:2::200
Host 0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.X.X.X.X.X.X.a.1.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)

Wie trage ich das ein, damit es auch funktioniert. Neulich habe ich die Zone mal gelöscht und neu angelegt. dann hat sich eine Weile funktioniert. Da war aber nur ein Eintrag drin (ucs …). Seit die die beiden Anderen Hostst mir drin habe geht es wieder nicht mehr. Ich verstehe das nicht

Moritz_Bunkus · February 5, 2018, 7:42pm

Huhu,

die Formate sehen soweit gut aus und funktionieren bei mir auch.

Was passiert denn, wenn Sie den bind neu starten? Gibt’s dann im /var/log/syslog irgendwelche Fehlermeldungen von ihm?

Weiterhin: welches DNS-Backend ist eingestellt (ucr get dns/backend)?

Und: gibt’s Rejects vom S4-Connector (univention-s4connector-list-rejected)? Läuft der Connector? Gibt’s Dateien in /var/lib/univention-connector/s4?

Zuletzt: welcher Host ist auf dem Server ucs als Nameserver konfiguriert (grep nameserver /etc/resolv.conf), und ist das die IP des DC Masters?

Gruß
mosu

mahescho · February 5, 2018, 7:52pm

Neu gestartet, keine Fehler im Syslog, keine Änderung.

samba4

Alle meine 3 Records werden hier gelistet … warum auch immer.

root@ucs:~# service univention-s4-connector status
● univention-s4-connector.service - LSB: Univention S4 Connector
   Loaded: loaded (/etc/init.d/univention-s4-connector)
   Active: active (running) since So 2018-02-04 10:35:41 CET; 1 day 10h ago
  Process: 1342 ExecStart=/etc/init.d/univention-s4-connector start (code=exited, status=0/SUCCESS)
 Main PID: 1945 (python2.7)
   CGroup: /system.slice/univention-s4-connector.service
           └─1945 /usr/bin/python2.7 -W ignore /usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py

Feb 04 10:35:23 ucs systemd[1]: Starting LSB: Univention S4 Connector...
Feb 04 10:35:41 ucs univention-s4-connector[1342]: Starting Univention S4 Connector: univention-s4-connector.
Feb 04 10:35:41 ucs systemd[1]: PID file /var/run/univention-s4-connector not readable (yet?) after start.
Feb 04 10:35:41 ucs systemd[1]: univention-s4-connector.service: Supervising process 1945 which is not our child. We'll most likely not notice when it exits.
Feb 04 10:35:41 ucs systemd[1]: Started LSB: Univention S4 Connector.
Hint: Some lines were ellipsized, use -l to show in full.

Ja, 3 und ein Verzeichnis “tmp”

Nameserver passt.

Moritz_Bunkus · February 5, 2018, 8:01pm

Huhu,

Passt zum Fehlerbild: im OpenLDAP sind die Einträge zwar da, können aber nicht zum Samba4-LDAP synchronisiert werden (das sind die Rejects), und da Bind direkt in Samba4 nach DNS-Einträgen sucht, werden keine gefunden.

Was sagt denn die Logdatei vom S4-Connector dazu (/var/log/univention/connector-s4.log)?

Gruß
mosu

mahescho · February 5, 2018, 8:08pm

Das sieht zielführend aus:

05.02.2018 21:06:20,913 LDAP        (PROCESS): sync from ucs:   Resync rejected file: /var/lib/univention-connector/s4/1517051171.102940
05.02.2018 21:06:20,917 LDAP        (PROCESS): sync from ucs: [           dns] [    delete] DC=@,DC=2.0.0.0.X.X.X.X.X.X.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
05.02.2018 21:06:20,963 LDAP        (WARNING): sync failed, saved as rejected
        /var/lib/univention-connector/s4/1517051171.102940
05.02.2018 21:06:20,963 LDAP        (WARNING): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 897, in __sync_file_from_ucs
    if ((old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, unicode(old_dn, 'utf8'), old, new)) or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old, new))):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2727, in sync_from_ucs
    self.property[property_type].con_sync_function(self, property_type, object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 1585, in ucs2con
    s4_zone_delete(s4connector, object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 884, in s4_zone_delete
    res = s4connector.lo_s4.lo.delete_s(zone_dn)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 295, in delete_s
    return self.delete_ext_s(dn,None,None)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 288, in delete_ext_s
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 476, in result3
    resp_ctrl_classes=resp_ctrl_classes
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 483, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call
    result = func(*args,**kwargs)
NOT_ALLOWED_ON_NONLEAF: {'info': '00002015: subtree_delete: Unable to delete a non-leaf node (it has 6 children)!', 'desc': 'Operation not allowed on non-leaf'}

Solcherlei Blocks gibt es eine Menge …

UPDATE: Mir fällt da etwas merkwürdiges auf. Wenn ich mir die Logeinträge anschaue dann sind da eher komische dabei. Ich sehe da Logeintäge, die sich auf die “2” und welche die sich auf “0002” am Ende beziehen. Also:

05.02.2018 20:59:45,355 LDAP        (PROCESS): sync from ucs: [           dns] [    delete] DC=@,DC=2.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
05.02.2018 20:59:45,397 LDAP        (PROCESS): sync from ucs: [           dns] [    delete] DC=@,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc

Moritz_Bunkus · February 5, 2018, 8:18pm

Huhu,

OK, das heißt, dass das Löschen der Zone bereits nicht richtig synchronisiert wurde. Alle weiteren sind dann Folgefehler davon.

Was fehlschlug, war das Löschen im Samba4, weil darunter noch Kindeinträge vorhanden sind. Also müssen Sie jetzt diese Untereinträge manuell löschen, damit der S4-Connector weitermachen kann.

Einträge im Samba4-LDAP löschen Sie mit ldbdel. Sie können den kompletten Zweig samt Kinder mit folgendem Befehl löschen:

ldbdel -H /var/lib/samba/private/sam.ldb --recursive 'DC=@,DC=2.0.0.0.X.X.X.X.X.X.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc' dn

Ich empfehle Copy & Paste der zu löschenden DN aus dem S4-Connector-Log.

Anschließend abwarten und das S4-Connector-Log beobachten und schauen, was nun passiert. Die Rejects werden regelmäßig erneut versucht.

Gruß
mosu

mahescho · February 5, 2018, 8:32pm

Ergebnis findet die DNs nicht:

failed - (No such object) No such Base DN:
‘(null)’ failed - (Invalid DN syntax) ldb_search: invalid basedn ‘(null)’

Das hier:

ldbsearch -H /var/lib/samba/private/sam.ldb --recursive ‘(objectclass=*)’ | grep arpa

liefert nichts, was mich vermuten lässt, dass das was er löschen will schlicht nicht da ist falls meine suche sinnvoll ist.

Moritz_Bunkus · February 5, 2018, 8:45pm

Die korrekte Suche wäre univention-s4search --cross-ncs -b 'DC=@,DC=2.0.0.0.X.X.X.X.X.X.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc'.

Dummerweise war meine ldbdel-Zeile leicht falsch — da ist das dn am Ende zu viel. Sollte eigentlich das hier sein:

ldbdel -H /var/lib/samba/private/sam.ldb --recursive 'DC=@,DC=2.0.0.0.X.X.X.X.X.X.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc'

mahescho · February 5, 2018, 9:37pm

Kann schon mal passieren

Aber, es bleibt dabei, das “ldbdel -H /var/lib/samba/private/sam.ldb --recursive” liefert weiterhin: failed - (No such object) No such Base DN:

Und im Log bleiben die Einträge wie gehabt.

Wenn ich nach den Einträgen such, wie vorgeschalgen, dann bekomme ich: search error - LDAP error 32 LDAP_NO_SUCH_OBJECT

Er versucht also offensichtlich weiterhin etwas zu löschen was nicht existiert …

Moritz_Bunkus · February 5, 2018, 9:41pm

Sie setzen da aber schon die tatsächliche DN ein, oder? Also die, die Sie auch im connector-s4.log in der Fehlermeldung sehen?

Sie geben mir ja immer nur die entschärften DNs, und daher kann ich auch nur die Copy&Pasten, aber die sind natürlich falsch, die ganzen X und DC=xxx,DC=loc…

mahescho · February 5, 2018, 9:42pm

Ja schon, ich bin schon gross cut&paste aus dem /var/log/univention/connector-s4.log

Wie lasse ich mir denn alles zeigen, unter “DC=DomainDnsZones,DC=xxx,DC=loc” liegt?

Moritz_Bunkus · February 5, 2018, 9:46pm

Mit univention-s4search --cross-ncs -b 'DC=DomainDnsZones,DC=xxx,DC=loc' dn

mahescho · February 5, 2018, 9:52pm

liefert:

dn: DC=::200,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
dn: DC=4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
dn: DC=1.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
dn: DC=200::,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
dn: DC=0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
dn: DC=2.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
dn: DC=1,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
dn: DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
dn: DC=0.0.0.0.0.0.0.0.0.0.0.0.0.200,DC=2.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc

und im Log steht:

05.02.2018 22:51:31,102 LDAP        (PROCESS): sync from ucs: [           dns] [    delete] DC=@,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
05.02.2018 22:52:27,527 LDAP        (PROCESS): sync from ucs: [           dns] [    delete] DC=@,DC=2.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
05.02.2018 22:52:27,569 LDAP        (PROCESS): sync from ucs: [           dns] [    delete] DC=@,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc
05.02.2018 22:52:27,661 LDAP        (PROCESS): sync from ucs: [           dns] [    delete] DC=@,DC=2.0.0.0.x.x.x.x.0.5.a.1.1.0.0.2.ip6.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=loc

( …mittlerweile habe ich das entschärfen gescriptet )

Ich fürchte ja, dass das System in einem suboptimalen Gesamtzustand ist und ich spiele mit dem Gedanken einfach alles neu zu machen. Im Moment macht der bei mir eh nur DNS und DHCP. Wenn ich das irgend wie sinnvoll exportieren und wieder importieren könnte, also alles was im DNS IPv4 ist und DHCP.

mahescho · February 6, 2018, 1:34pm

So, ein mal alles neu - geht … war wohl alles durch meine vielen Experiment “etwas” durcheinander … der läuft ja schon ziemlich lange und ich habe immer wieder dran rumgebastelt um alles was ich brauche hin zubekommen. Jetzt sieht es so aus, als würde erstmalig alles funktionieren was ich brauche. Jetzt versuche ich mich noch am dem “also notify” für DNS und dann sollte alles so sein wie ich es brauche.

@Moritz_Bunkus danke für die Geduld

Moritz_Bunkus · February 6, 2018, 1:51pm

Freut mich, dass es wieder klappt.