Univention Bugzilla – Bug 29526
Join von Backup (Samba DC) schlägt IPv6-only fehl
Last modified: 2013-01-15 11:00:42 CET
Created attachment 4856 [details] Weitere Debug-Informationen Ein S4-DC-Backup konnte bei der Installation nicht joinen, weil 98univention-samba4-dns.inst fehl geschlagen ist. DC-Master: mike.icao.test DC-Backup: bravo.icao.test Ausgaben in der join.log: Waiting for RID Pool replication: .....[…]..... Error no rIDSetReferences replicated for bravo
Created attachment 4857 [details] join.log sierra.icao.test Tritt auch auf dem slave (sierra.icao.test) auf. In der join.log findet sich folgender Traceback: ERROR(exception): uncaught exception - Failed to find a writeable DC for domain 'icao.test' File "/usr/lib/python2.6/dist-packages/samba/netcmd/__init__.py", line 168, in _run return self.run(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/samba/netcmd/domain.py", line 563, in run machinepass=machinepass, use_ntvfs=use_ntvfs, dns_backend=dns_backend) File "/usr/lib/python2.6/dist-packages/samba/join.py", line 1116, in join_DC machinepass, use_ntvfs, dns_backend, promote_existing, keep_existing) File "/usr/lib/python2.6/dist-packages/samba/join.py", line 74, in __init__ ctx.server = ctx.find_dc(domain) File "/usr/lib/python2.6/dist-packages/samba/join.py", line 273, in find_dc raise Exception("Failed to find a writeable DC for domain '%s'" % domain) Finding a writeable DC for domain 'icao.test'
Siehe auch Bug #29508.
Die Fehlermeldung "Error no rIDSetReferences replicated" aus 98univention-samba4-dns.inst war in diesem Fall ein Symptom dafür dass im Samba4-Verzeichnis des DC Master dem Rechnerkonto des DC Backup überhaupt kein "RID Set" Objekt zugeordnet war. Da dann keins zum DC Backup repliziert wurde, kann dieser nicht per "samba-tool user add" Benutzer anlegen (in diesem Fall dns-$hostname). Warum hier nach dem Join das "RID Set"-Objekt fehlt ist bisher unklar, ggf. noch ein Samba-Bug. Die Auswirkung auf 98univention-samba4-dns.inst könnte man auf zwei Wegen vermeiden: 1. den Benutzer "dns-$hostname" per UDM anlegen, seine Replikation abwartet und dann die notwendigen zusätzlichen AD-Kerberos-Attribute lokal hinzufügt (so machen wir es in univention-squid-kerberos) 2. Das Konto (in diesem Falls vom DC Backup aus) z.B. per python-ldb-API direkt im Samba4-Verzeichnisdienst auf dem S4-Connector-Host anlegen. Das hat den Vorteil, dass man die zusätzlichen AD-Kerberos-Attribute direkt mit setzen kann ohne auf eine Replikation warten zu müssen. IMHO die bessere Lösung.
Der Traceback "Failed to find a writeable DC for domain" kommt vermutlich von dem ersten samba domain join Versuch, bei dem wir nicht explizit einen Server mit angeben. Da wir diesen Fall schon häufiger beobachtet haben wird im Fehlerfall dann im nächsten Schritt explizit gegen den S$-Connector-Host gejoined. Vermutlich ist der Traceback also unkritisch, ggf. hat er einfach auch nichts mit dem Problem zu tun.
Das Problem, dass der RID Set nicht angelegt wird, tritt auch beim IPv6-Join des DC Slave auf. Leider sieht man bei samba/debug/level= 10 weder im log.samba auf dem DC Master noch im join.log des DC Slave einen eindeutigen Fehler.
Das Problem tritt auf einem UCS 3.1-0-Slave mit S4-RC6 weiterhin auf.
Mit IPv6 scheint es in RC6 ein generelles Problem mit der Replikation zu geben. In log.samba auf dem Master sieht man, dass es ein Problem bei der DNS-Auflösung gibt (Note: In der Ausgabe steht "A", ggf. ist das aber nur ein Artefakt der Fehlermeldung die nur zwischen "SRV" und "A" unterscheidet): =============================================================================== [2012/12/19 04:01:07, 3] ../source4/libcli/resolve/dns_ex.c:489(pipe_handler) dns child failed to find name '9567e3b4-1606-4057-bedb-85400317128f._msdcs.arucs31i24.qa' of type A [2012/12/19 04:01:07, 4] ../source4/dsdb/repl/drepl_notify.c:196(dreplsrv_notify_op_callback) dreplsrv_notify: Failed to send DsReplicaSync to 9567e3b4-1606-4057-bedb-85400317128f._msdcs.arucs31i24.qa for DC=DomainDnsZones,DC=arucs31i24,DC=qa - NT_STATUS_OBJECT_NAME_NOT_FOUND : WERR_BADFILE =============================================================================== root@ipv6master:~# host 9567e3b4-1606-4057-bedb-85400317128f._msdcs.arucs31i24.qa 9567e3b4-1606-4057-bedb-85400317128f._msdcs.arucs31i24.qa is an alias for ipv6backup.arucs31i24.qa. ipv6backup.arucs31i24.qa has IPv6 address 2001:4dd0:ff00:8c42:ff08:ac8:0:91 Auf dem DC Backup findet sich entsprechend in log.samba: =============================================================================== [2012/12/19 04:02:42, 3] ../source4/libcli/resolve/dns_ex.c:489(pipe_handler) dns child failed to find name '947be362-9a4d-4211-ad1f-7bd445226332._msdcs.arucs31i24.qa' of type A [2012/12/19 04:02:42, 4] ../source4/dsdb/repl/drepl_out_pull.c:178(dreplsrv_pending_op_callback) dreplsrv_op_pull_source(WERR_BADFILE) for CN=RID Manager$,CN=System,DC=arucs31i24,DC=qa [2012/12/19 04:02:42, 0] ../source4/dsdb/repl/drepl_ridalloc.c:43(drepl_new_rid_pool_callback) ../source4/dsdb/repl/drepl_ridalloc.c:43: RID Manager failed RID allocation - WERR_BADFILE - extended_ret[0x0] =============================================================================== root@ipv6backup:~# host 947be362-9a4d-4211-ad1f-7bd445226332._msdcs.arucs31i24.qa 947be362-9a4d-4211-ad1f-7bd445226332._msdcs.arucs31i24.qa is an alias for ipv6master.arucs31i24.qa. ipv6master.arucs31i24.qa has IPv6 address 2001:4dd0:ff00:8c42:ff08:ac8:0:90
Ggf. ist durch http://gitweb.samba.org/samba.git/?p=samba.git;a=commit;h=c54fe86a63f73543eaf9b031e146d5f647c05830 eine Funktionsänderung in die Samba4-internen DNS-Auflösung eingebracht worden. Es wird zuerst getaddrinfo versucht und danach als Fallback res_search. getaddrinfo scheint genrell das "_msdcs" nicht zu erlauben, auch unter einem reinen IPv4-System habe ich: root@master20:~/debug# host 69f87f84-3956-4d41-b67e-2cba04a4588d._msdcs.arucs31i20.qa 69f87f84-3956-4d41-b67e-2cba04a4588d._msdcs.arucs31i20.qa is an alias for backup20.arucs31i20.qa. backup20.arucs31i20.qa has address 10.200.8.11 root@master20:~/debug# ping 69f87f84-3956-4d41-b67e-2cba04a4588d._msdcs.arucs31i20.qa ping: unknown host 69f87f84-3956-4d41-b67e-2cba04a4588d._msdcs.arucs31i20.qa Vermutlich muss man sich also den res_search Code anschauen. Testweise habe ich die Datei source4/libcli/resolve/dns_ex.c auf den Stand vor der Upstream-Änderung reverted undd damit funktionierte die Replikation dann wieder und das Joinscript 98univention-samba4-dns läuft durch.
Unklar ist noch, warum RC6 in IPv4-Umgebungen keine Probleme bei Join und Replikation macht, obwohl man auch dort (anscheinend nur auf dem Master, nicht auf dem Slave) bei Loglevel 4 die schon in Comment 7 berichtete Fehlermeldung im log.samba findet: ============================================================================= [2012/12/10 14:01:27, 3] ../source4/libcli/resolve/dns_ex.c:489(pipe_handler) dns child failed to find name '69f87f84-3956-4d41-b67e-2cba04a4588d._msdcs.arucs31i20.qa' of type A [2012/12/10 14:01:27, 4] ../source4/dsdb/repl/drepl_notify.c:196(dreplsrv_notify_op_callback) dreplsrv_notify: Failed to send DsReplicaSync to 69f87f84-3956-4d41-b67e-2cba04a4588d._msdcs.arucs31i20.qa for CN=Configuration,DC=arucs31i20,DC=qa - NT_STATUS_OBJECT_NAME_NOT_FOUND : WERR_BADFILE =============================================================================
Patch ist upstream geschickt, Paket ist in errata3.1-0 neu gebaut. Advisory: 2013-01-08-samba4.yaml Die in Comment 9 dokumentierte Logmeldung hat eine andere Ursache und ist nach aktuellem Wissensstand kosmetischer Natur. getaddrinfo akzeptiert unter Linux wie auch unter FreeBSD nicht FQDNs oder cnames bei denen einzelne Label mit _ anfangen, dazu gehören in AD/Samba4-Umgebungen die <GUID>._msdcs.$domainname Aliases und der spezielle Hostname gc._msdcs.$domainname (NB: SRV records unterstützt getaddrinfo garnicht, obschon bei diesen per RFC2782 explizit _label erlaubt sind). Samba4 macht dann als Fallback einfach noch einen DNS-Lookup und der schlägt direkt nach dem Samba4 restart vorübergehend fehl, während bind9 auch gerade neu gestartet wird.
OK, die Replikation funktioniert. YAML: OK.
http://errata.univention.de/3.1-errata7.html