Bug 30905 - Changing network object modifies too many reverse zones
Changing network object modifies too many reverse zones
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
UCS 3.1
Other Linux
: P2 normal (vote)
: UCS 3.1-1-errata
Assigned To: Lukas Walter
Stefan Gohmann
:
Depends on:
Blocks: 31041 31080
  Show dependency treegraph
 
Reported: 2013-03-26 13:41 CET by Sönke Schwardt-Krummrich
Modified: 2013-04-17 15:59 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2013-03-26 13:41:57 CET
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
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2013-03-26 13:42:44 CET
It is currently unknown if this problem also occurs when using UMC only.
Comment 2 Lukas Walter univentionstaff 2013-04-04 14:43:10 CEST
This problem did not only occur when changing the network object but whenever the DNS forward zone changed.

Fixed in ucs-3.1-1 and ucs-3.1.2.

univention-directory-manager-modules has been rebuild in ucs3.1-2 and errata3.1-1 scope.

YAML file has been added.
Comment 3 Sönke Schwardt-Krummrich univentionstaff 2013-04-04 14:57:56 CEST
> 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 also recheck this situation.
Comment 4 Lukas Walter univentionstaff 2013-04-04 15:21:20 CEST
(In reply to comment #3)
> > 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 also recheck this situation.

Does not occur anymore.
Comment 5 Lukas Walter univentionstaff 2013-04-04 15:35:57 CEST
The problem DOES still occur but due to another issue -> REOPENED.
Comment 6 Lukas Walter univentionstaff 2013-04-04 17:49:51 CEST
(In reply to comment #5)
> The problem DOES still occur but due to another issue -> REOPENED.

Fixed.
Packages rebuild and YAML updated.
Comment 7 Stefan Gohmann univentionstaff 2013-04-12 12:29:27 CEST
Tests errata: OK, I was able to reproduce it

3.1-2 review: OK
diff -Nur -x '.svn' ucs-3.1-1/management/univention-directory-manager-modules/
ucs-3.1-2/management/univention-directory-manager-modules/

errata YAML: OK

Changelog: OK
Comment 8 Janek Walkenhorst univentionstaff 2013-04-12 15:06:19 CEST
http://errata.univention.de/3.1-errata87.html