Univention Bugzilla – Bug 25138
Server nicht per DNS erreichbar
Last modified: 2016-05-18 12:07:48 CEST
Installation von einem Master und zwei Memberserver. Nach dem Joinen der Memberserver sind diese nicht per DNS auflösbar: root@xen16:~# host xen14a.deadlock0.local Host xen14a.deadlock0.local not found: 3(NXDOMAIN) root@xen16:~# host xen14.deadlock0.local Host xen14.deadlock0.local not found: 3(NXDOMAIN) root@xen16:~# univention-ldapsearch relativeDomainName=xen14 -LLL dn: relativeDomainName=xen14,zoneName=deadlock0.local,cn=dns,dc=deadlock0,dc=l ocal objectClass: top objectClass: dNSZone aRecord: 10.201.0.13 relativeDomainName: xen14 zoneName: deadlock0.local root@xen16:~# univention-ldapsearch relativeDomainName=xen14a -LLL dn: relativeDomainName=xen14a,zoneName=deadlock0.local,cn=dns,dc=deadlock0,dc= local objectClass: top objectClass: dNSZone aRecord: 10.201.0.14 relativeDomainName: xen14a zoneName: deadlock0.local Nachdem per rndc der Zonen Reload getriggert wird, sind die Memberserver per DNS erreichbar: root@xen16:~# /usr/sbin/rndc -p 55555 reload deadlock0.local zone reload successful root@xen16:~# /usr/sbin/rndc -p 953 reload deadlock0.local zone refresh queued root@xen16:~# host xen14.deadlock0.local xen14.deadlock0.local has address 10.201.0.13 root@xen16:~# host xen14a.deadlock0.local xen14a.deadlock0.local has address 10.201.0.14 Der Zonen-Reload wird normalerweise per listener Modul getriggert.
Bisher konnte ich das noch nicht reproduzieren.
Das ist eine Folge des LDAP idle Timeout. Sobald der slapd die Verbindung zu macht, geht die erste Abfrage schief: Dec 3 21:32:30 master21 named[1079]: received control channel command 'reload deadlock2.local' Dec 3 21:32:30 master21 named[1081]: received control channel command 'reload deadlock2.local' Dec 3 21:32:30 master21 named[1079]: LDAP sdb zone 'deadlock2.local': ldap_result returned -1 Dec 3 21:32:30 master21 named[1081]: zone deadlock2.local/IN: refresh: unexpected rcode (NXDOMAIN) from master 127.0.0.1#7777 (source 0.0.0.0#0) Dec 3 21:32:30 master21 named[1079]: received control channel command 'reload 201.10.in-addr.arpa' Dec 3 21:32:30 master21 named[1081]: received control channel command 'reload 201.10.in-addr.arpa' Dec 3 21:32:31 master21 named[1081]: zone 201.10.in-addr.arpa/IN: Transfer started. Dec 3 21:32:31 master21 named[1081]: transfer of '201.10.in-addr.arpa/IN' from 127.0.0.1#7777: connected using 127.0.0.1#54917
Ist jetzt angepasst: 061_bind9_ldap_idletimeout.patch
Der Fehler tritt nicht mehr auf.
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"