Univention Bugzilla – Bug 33414
IP address change is not registered correctly in the reverse zone
Last modified: 2018-04-14 13:37:31 CEST
I completed the appliance setup with a wrong Administrator password, i.e., the join in the appliance failed. I then tried to join DC slave system into a domain, however I received the following error: ==================== > 15.11.13 11:43:38.001 MODULE ( PROCESS ) : Sync time ESC[60Gdone > 15.11.13 11:43:38.001 MODULE ( PROCESS ) : Sync time > 15.11.13 11:43:39.847 MODULE ( PROCESS ) : Join Computer Account: ESC[60Gdone > 15.11.13 11:43:39.847 MODULE ( PROCESS ) : Join Computer Account > 15.11.13 11:43:41.897 MODULE ( PROCESS ) : Sync ldap-backup.secret: ESC[60Gdone > 15.11.13 11:43:41.897 MODULE ( PROCESS ) : Sync ldap-backup.secret > 15.11.13 11:43:45.474 MODULE ( PROCESS ) : Check TLS connection > 15.11.13 11:43:45.474 MODULE ( PROCESS ) : > 15.11.13 11:43:45.474 MODULE ( PROCESS ) : ************************************************************************** > 15.11.13 11:43:45.475 MODULE ( PROCESS ) : * Join failed! * > 15.11.13 11:43:45.475 MODULE ( PROCESS ) : * Contact your system administrator * > 15.11.13 11:43:45.476 MODULE ( PROCESS ) : ************************************************************************** > 15.11.13 11:43:45.476 MODULE ( PROCESS ) : * Message: Establishing a TLS connection with master11 failed. Maybe you didn't specify a FQDN. > 15.11.13 11:43:45.476 MODULE ( WARN ) : Der Join-Vorgang konnte nicht durchgeführt werden:<br/><br/><i>Establishing a TLS connection with master11 failed. Maybe you didn't specify a FQDN.</i><br/><br/> Weitere Informationen könn en in der Logdatei <i>/var/log/univention/join.log</i> gefunden werden.<br/>Bitte den Join-Vorgang nach Lösen aller Konflikte erneut durchführen. > 15.11.13 11:43:45.477 MODULE ( PROCESS ) : ************************************************************************** > 15.11.13 11:43:45.482 MODULE ( WARN ) : stderr: ldap_start_tls: Connect error (-11) > additional info: TLS: hostname does not match CN in peer certificate > > 15.11.13 11:43:45.482 MODULE ( WARN ) : Could not perform system join: ldap_start_tls: Connect error (-11) > additional info: TLS: hostname does not match CN in peer certificate ==================== The problem was that only the hostname of the DC master (=master11) was used. > 15.11.13 11:49:17.349 MODULE ( INFO ) : calling "/usr/sbin/univention-join -dcname master11 -dcaccount Administrator -dcpwd /tmp/tmpfh0NOW" However, the FQDN was properly set in UMC. The problem here was the HostSanitizer, that uses pythons socket library: > python -c 'import socket; print socket.getfqdn("master11.ucs32.qa")' > master11 Could be related to this bug: http://bugs.python.org/issue5004
Solution: Use a weaker sanitization with a simple regexp allowing \w and [:.-] or similar.
> gethostbyaddr(host) -> (name, aliaslist, addresslist) > > Return the true host name, a list of aliases, and a list of IP addresses, > for a host. The host argument is a string giving a host name or IP number. > root@backup17:~# python -c 'import socket; print socket.gethostbyaddr("master11")' > ('master11', [], ['10.200.26.11']) > root@backup17:~# python -c 'import socket; print socket.gethostbyaddr("backup17")' > ('backup17.ucs32.qa', ['backup17'], ['10.200.26.17']) The following line (extracted from the patch at the mentioned bug) seems to work: > python -c 'import socket; print socket.getaddrinfo("master11", None, 0, socket.SOCK_DGRAM, 0, socket.AI_CANONNAME)'
Here the output: > root@backup17:~# python -c 'import socket; print socket.getaddrinfo("master11", None, 0, socket.SOCK_DGRAM, 0, socket.AI_CANONNAME)' > [(2, 2, 17, 'master11.ucs32.qa', ('10.200.26.11', 0))]
It seems to be a wrong entry in the reverse zone? > root@backup17:~# host 10.200.26.17 > 17.26.200.10.in-addr.arpa domain name pointer backup17.ucs32.qa. > root@backup17:~# host 10.200.26.11 > 11.26.200.10.in-addr.arpa domain name pointer master11. > root@backup17:~# udm dns/ptr_record list --superordinate zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa --filter relativeDomainName=11 > relativeDomainName=11 > DN: relativeDomainName=11,zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa > ARG: None > ptr_record: master11. > address: 11 > root@backup17:~# udm dns/ptr_record list --superordinate zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa --filter relativeDomainName=17 > relativeDomainName=17 > DN: relativeDomainName=17,zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa > ARG: None > ptr_record: backup17.ucs32.qa. > address: 17
On the master, I switched back and forward from IP address 10.200.26.11 to .211 and back to .11. Here some output from setup.log where the reverse zone entry might have been registered incorrectly: > INFO:uss.network.phase.LdapSelf:Updating 'cn=master11,cn=dc,cn=computers,dc=ucs32,dc=qa' with '[('ip', ['10.200.26.211'], ['10.200.26.11']), ('dnsEntryZoneReverse', [], [['zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa', '10.200.26.11']])]'... > 13.11.13 23:44:43.872 ADMIN ( INFO ) : check_common_name_length with self["ip"] = ['10.200.26.11'] and self["dnsEntryZoneForward"] = [['zoneName=ucs32.qa,cn=dns,dc=ucs32,dc=qa', '10.200.26.211']] > 13.11.13 23:44:43.873 ADMIN ( INFO ) : LOCK acquireUnique scope = domain > 13.11.13 23:44:43.907 ADMIN ( INFO ) : simpleLdap._modify: c_u_p: pname = "objectFlag" oc = "univentionObject" > 13.11.13 23:44:43.907 ADMIN ( INFO ) : simpleLdap._modify: c_u_p: pname = "ManageableBy" oc = "univentionVirtualMachineHostOC" > 13.11.13 23:44:43.916 ADMIN ( INFO ) : IP[10.200.26.11]? -> Yes > 13.11.13 23:44:43.917 ADMIN ( INFO ) : Split entry ['zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa', '10.200.26.11'] into zone zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa and ip 10.200.26.11 > 13.11.13 23:44:43.917 ADMIN ( INFO ) : we should create a dns reverse object: zoneDn="zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa", name="master11", ip="10.200.26.11" > 13.11.13 23:44:43.917 ADMIN ( INFO ) : dns reverse object: start > 13.11.13 23:44:43.956 ADMIN ( INFO ) : we should modify a dns forward object: zoneDn="None", name="master11", new_ip="10.200.26.11", old_ip="10.200.26.211" > 13.11.13 23:44:43.960 ADMIN ( INFO ) : update the zon sOARecord for the zone: zoneName=ucs32.qa,cn=dns,dc=ucs32,dc=qa > 13.11.13 23:44:43.969 ADMIN ( INFO ) : we should remove a dhcp object: position="None", name="master11", oldname="10.200.26.211", mac="52:54:00:f8:d1:1e", ip="None" > 13.11.13 23:44:43.969 ADMIN ( INFO ) : Remove the following mac: ethernet: "ethernet 52:54:00:f8:d1:1e" > 13.11.13 23:44:43.969 ADMIN ( INFO ) : we should remove a dns reverse object: dnsEntryZoneReverse="None", name="master11", ip="10.200.26.211" > 13.11.13 23:44:43.973 ADMIN ( INFO ) : DEBUG: dn: "relativeDomainName=211,zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa" > 13.11.13 23:44:43.974 ADMIN ( INFO ) : DEBUG: zone: "zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa" > 13.11.13 23:44:43.974 ADMIN ( INFO ) : DEBUG: rdn: "211" > 13.11.13 23:44:43.997 ADMIN ( INFO ) : DEBUG: dn: "relativeDomainName=11,zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa" > 13.11.13 23:44:43.997 ADMIN ( INFO ) : DEBUG: zone: "zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa" > 13.11.13 23:44:43.998 ADMIN ( INFO ) : DEBUG: rdn: "211" > 13.11.13 23:44:43.998 ADMIN ( INFO ) : IP[10.200.26.11]? -> Yes > 13.11.13 23:44:43.998 ADMIN ( INFO ) : Split entry ['zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa', '10.200.26.11'] into zone zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa and ip 10.200.26.11 > 13.11.13 23:44:43.999 ADMIN ( INFO ) : we should create a dns reverse object: zoneDn="zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa", name="master11", ip="10.200.26.11" > 13.11.13 23:44:43.999 ADMIN ( INFO ) : dns reverse object: start
Bug is in computers/* module - veryl likely in univention.admin.handlers.simpleComputer - , not in univention-system-setup. *** This bug has been marked as a duplicate of bug 33042 ***