Univention Bugzilla – Bug 31041
Changing network object modifies too many reverse zones
Last modified: 2013-11-19 06:41:57 CET
Please add a test case for this to ucs test. +++ This bug was initially created as a clone of Bug #30905 +++ With UCS 3.1-0 a regression has been introduced when changing the network object of a (windows) host. During the change the old IP address get removed correctly from old DNS forward lookup zone and DNS reverse lookup zone. The host also gets a new IP address from the IP range defined in the new network object. And the bug: the reverse zone entry is not only created/changed in the reverse zone defined in the network object but also in many other reverse zone that do not match to the new IP address of the host. If the host gets a new IP address (e.g. x.y.z.20) then a reverse zone entry for ".20" is added on other reverse zones. If there is already a ".20" entry in that zone, the hostname will be added to that reverse entry. This results in an IP address which resolves to more than one hostname. When changing the network object again, the reverse zone entries get removed completely. Expected behaviour: the additional hostname will be removed from the reverse zone entry and if there is no hostname left, the reverse zone entry will be removed (but not earlier!). Please note that the old network object used a 24 bit netmask and the new one a 23 bit netmask. Currently it is unknown if this is part of the problem. The problem does not occur with UCS 3.0-2. LDIF changes before and after the change are available. Please have a look at ticket #2013032621001711 which contains an archive with LDAP dumps. (perform a diff between 4-updated-to-ucs310.ldif and 5-changes-made-via-udmcli-netmask23.ldif) The change of the network object has been done by the following command: udm computers/windows modify --dn \ cn=ws424-nb-024,cn=computers,ou=424,dc=school,dc=example,dc=com --set \ network=cn=424-10.102.110.0,cn=networks,ou=424,dc=school,dc=example,dc=com The old network object: # 424-10.101.110.0, networks, 424, school.example.com dn: cn=424-10.101.110.0,cn=networks,ou=424,dc=school,dc=example,dc=com univentionNetmask: 24 cn: 424-10.101.110.0 univentionNetwork: 10.101.110.0 univentionDnsForwardZone: zoneName=school.example.com,cn=dns,dc=school,dc=example,dc=com univentionDhcpEntry: cn=424,cn=dhcp,ou=424,dc=school,dc=example,dc=com univentionDnsReverseZone: zoneName=110.101.10.in-addr.arpa,cn=dns,dc=school,dc=example,dc=com objectClass: top objectClass: univentionNetworkClass objectClass: univentionObject univentionObjectType: networks/network univentionIpRange: 10.101.110.20 10.101.110.219 univentionNextIp: 10.101.110.20 The new network object: # 424-10.102.110.0, networks, 424, school.example.com dn: cn=424-10.102.110.0,cn=networks,ou=424,dc=school,dc=example,dc=com univentionNetmask: 23 univentionNextIp: 10.102.110.20 cn: 424-10.102.110.0 univentionNetwork: 10.102.110.0 univentionDnsForwardZone: zoneName=school.example.com,cn=dns,dc=school,dc=example,dc=com objectClass: top objectClass: univentionNetworkClass objectClass: univentionObject univentionObjectType: networks/network univentionDhcpEntry: cn=424,cn=dhcp,ou=424,dc=school,dc=example,dc=com univentionDnsReverseZone: zoneName=102.10.in-addr.arpa,cn=dns,dc=school,dc=example,dc=com univentionIpRange: 10.102.110.20 10.102.111.199
I've added to tests. One in order to check if modifying a computers dns forward zone does only affect it's own ptr record entry, and one to check if changing his IP only removes the related ptr fully if it would be empty afterwards.
The test case fails in jenkins every night, see here: http://jenkins.knut.univention.de:8080/job/ucs-test_EC2-SingleMaster_64_RESULT/326/testReport/junit/%28root%29/66_udm-computers_51_modify_dns_forward_zone_ptr_record/Check_if_modifying_the_DNS_forward_zone_of_a_computer_only_affects_PTR_records_related_to_him/ I've looked into the code and the test case returned 1 at this point: if len(ldap.search(filter = '(&(relativeDomainName=40)(pTRRecord=%s))' % ptrRecordEntry)[0][1]['pTRRecord']) > 1: # more than the expected entry in ptr_record? sys.exit(1) Is it a error in UDM or in the test case?
(In reply to comment #2) > The test case fails in jenkins every night, see here: > http://jenkins.knut.univention.de:8080/job/ucs-test_EC2-SingleMaster_64_RESULT/326/testReport/junit/%28root%29/66_udm-computers_51_modify_dns_forward_zone_ptr_record/Check_if_modifying_the_DNS_forward_zone_of_a_computer_only_affects_PTR_records_related_to_him/ > > I've looked into the code and the test case returned 1 at this point: > > if len(ldap.search(filter = '(&(relativeDomainName=40)(pTRRecord=%s))' > % ptrRecordEntry)[0][1]['pTRRecord']) > 1: # more than the expected entry in > ptr_record? > sys.exit(1) > > > Is it a error in UDM or in the test case? I've added some additional logging to this test so. If it fails again, we'll be able to see whats in this PTR and hopefully to debug why it's in there.
Test does not fail on jenkins anymore.
OK, the test case works now.
UCS 3.2 has been released: http://docs.univention.de/release-notes-3.2-en.html http://docs.univention.de/release-notes-3.2-de.html If this error occurs again, please use "Clone This Bug".