Univention Bugzilla – Bug 23168
Samba4 Bind-Anbindung per "Dynamically Loadable Zones" (DLZ)
Last modified: 2011-12-13 15:46:59 CET
Im Kontext von Samba4 wurde bind9.8 so erweitert, dass es für "Dynamically Loadable Zones" (DLZ) einen dlopen Aufruf auf eine Samba4-Modul verwenden kann. Konfigurationsbeispiel analog zu http://lists.samba.org/archive/samba/2011-February/160896.html : dlz "The univention.qa Zone" { database "dlopen /usr/lib/samba/libdlz_bind9.so"; }; Ich nehme an, dass dies ein alternative Methode zu Bug #23161 darstellt. Man sollte hier abwarten, bis die Anpassungen an dem Samba4-Provisioning konvergiert sind, siehe http://samba.2283325.n4.nabble.com/samba4-and-libdlz-bind9-so-td3647985.html#a3650761
Diese Anpassung ist zusätzlich zu Bug #23161 notwendig, und zwar für * DRS replication updates from other domain controllers * direct modifications via LDAP (DNS in AD is stored in LDAP) (Zitat aus http://blog.tridgell.net/?cat=5 ).
Ich denke wir sollten dann den S4 Weg für Bind gehen. Da wir zusätzlich per S4 Connector die Daten synchronisieren, sollte dann auch weiterhin per UDM administriert werden können. TODOs: - Auf einem S4 System wird per Default das Samba 4 Backend verwendet. Das sollte per UCR oder per Paket, beispielsweise univention-bind-samba4 konfiguriert werden können. Dabei müssen auch die Listener Module berücksichtigt werden. Dieser Bug. - Die DNS Daten sollen synchronisiert werden: Bug #23357
Mit dieser Konfiguration # /etc/bind/named.conf.samba4 dlz "Samba 4" { database "dlopen /usr/lib/samba/libdlz_bind9.so"; }; kann der named gestartet werden: /usr/sbin/named -c /etc/bind/named.conf.samba4 -u bind -f Allerdings gibt es dann noch ein Berechtigungsproblem: [pid 31655] connect(9, {sa_family=AF_FILE, path="/var/lib/samba/private/ldap_priv/ldapi"}, 110) = -1 EACCES (Permission denied)
Per default sucht das dlz samba4 bind Modul nur unterhalb von "CN=MicrosoftDNS,DC=DomainDnsZones" und "CN=MicrosoftDNS,DC=ForestDnsZones". Nachdem auch in "CN=MicrosoftDNS,CN=System" gesucht wird, funktioniert die Anbindung.
root@master51:~# ucr get dns/backend samba4 root@master51:~# nscd -i hosts; host deadlock5.local deadlock5.local has address 10.201.5.1 root@master51:~# /etc/init.d/samba4 stop Stopping Samba 4 daemon: samba. root@master51:~# nscd -i hosts; host deadlock5.local Host deadlock5.local not found: 3(NXDOMAIN) root@master51:~# /etc/init.d/samba4 start Starting Samba 4 daemon: samba. root@master51:~# nscd -i hosts; host deadlock5.local Host deadlock5.local not found: 3(NXDOMAIN) root@master51:~# nscd -i hosts; host deadlock5.local Host deadlock5.local not found: 3(NXDOMAIN) root@master51:~# /etc/init.d/bind9 reload Usage: /etc/init.d/bind9 {start|stop|restart|crestart|force-reload|status}. root@master51:~# /etc/init.d/bind9 restart Restarting bind9 daemon: . done. root@master51:~# nscd -i hosts; host deadlock5.local deadlock5.local has address 10.201.5.1 root@master51:~#
Das ist jetzt soweit umgesetzt. Das Backend kann per dns/backend gesteuert werden. samba4, ldap und none sind möglich. Auf einem System mit S4 wird automatisch das S4 Backend verwendet. Zusätzlich wurden bind und bind-proxy in ein Paket integriert und das init-Skript bind9 steuert die Dienste. Man kann damit so etwas in der Art machen: ucr set dns/backend=samba4 /etc/init.d/bind9 restart host -al $(dnsdomainname) ucr set dns/backend=ldap /etc/init.d/bind9 restart host -al $(dnsdomainname) Zusätzlich ist das Samba4 Initskript so angepasst, dass beim S4 Start auch bind9 einmal neu gestartet wird.
Ggf. können dadurch jetzt die univention-dnsedit Aufrufe im Joinskript von univention-samba4 entfallen? Zitat: ## Adding DNS records is currently necessary, probably this will can be avoided with dlz-dlopen on samba4 ## see https://wiki.samba.org/index.php/Samba4/HOWTO/Join_a_domain_as_a_DC#A_note_on_DNS_updates /usr/share/univention-samba4/scripts/setup-dns-in-ucsldap.sh "$@"
root@master51:~# ucr get dns/backend samba4 root@master51:~# echo $SRV _ldap._tcp.dc._msdcs.deadlock5.local root@master51:~# host -t SRV $SRV Host _ldap._tcp.dc._msdcs.deadlock5.local not found: 3(NXDOMAIN) root@master51:~# host -al deadlock5.local | grep "$SRV" _ldap._tcp.dc._msdcs.deadlock5.local. 3600 IN SRV 0 100 389 master51.deadlock5.local. _ldap._tcp.dc._msdcs.deadlock5.local. 3600 IN SRV 0 100 389 backup52.deadlock5.local. root@master51:~# Das Problem scheint irgendwo im dlz backend zu liegen.
(In reply to comment #8) > root@master51:~# ucr get dns/backend > samba4 > root@master51:~# echo $SRV > _ldap._tcp.dc._msdcs.deadlock5.local > root@master51:~# host -t SRV $SRV > Host _ldap._tcp.dc._msdcs.deadlock5.local not found: 3(NXDOMAIN) > root@master51:~# host -al deadlock5.local | grep "$SRV" > _ldap._tcp.dc._msdcs.deadlock5.local. 3600 IN SRV 0 100 389 > master51.deadlock5.local. > _ldap._tcp.dc._msdcs.deadlock5.local. 3600 IN SRV 0 100 389 > backup52.deadlock5.local. > root@master51:~# > > Das Problem scheint irgendwo im dlz backend zu liegen. Siehe Bug #23786. Für MS2 wird das Backend zunächst wieder auf LDAP gesetzt.
Verified: * Die Konfiguration findet per /etc/bind/named.conf.samba4 statt und folgt den aktuell bekannten upstream-Empfehlungen. * univention-bind hängt von bind9 (>= 1:9.8.0.P4) ab, das das dlopen dlz plugin unterstützt. * Per dns/fakeroot=no lässt sich die Konfiguration der fake root zone deaktivieren. Standardmässig ist das aktiviert und vermeidet so timeout-Verzögerungen, falls kein dns/forwarder1 gesetzt ist und z.B. das gateway nicht erreichbar. * Da im Moment Bug 23161 noch offen ist, lässt sich noch nicht entscheiden, ob Comment 7 zutrifft. Im Moment werden die notiwendigen DNS-Records per univention-dnsedit während des univentiuon-samba4 joins hinzugefügt und sind dann auch per DNS abfragbar (bis auf den _msdcs records, siehe Comment 8). * Changelog bon auf Bug 23786 ok.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"