Description Sönke Schwardt-Krummrich 2013-04-17 15:59:54 CEST

A customer changed the network object of a (windows) host and noted a different behaviour between UCS 3.0-x and UCS 3.1-1 errata 87:

UCS 3.0-x:
If the network object gets changed, a new DHCP entry will be created in new DHCP zone with new IP address. If more than one MAC address has been defined at the host object (e.g. LAN + WLAN MAC address), only one new DHCP entry has been created in new DHCP zone (regardless if one or more DHCP entries were present before changing the network object).

UCS 3.1-1 errata 87:
If the network object gets changed, a new DHCP entry will be created in new DHCP zone with new IP address. If more than one MAC address has been defined at the host object, it will be no DHCP entry created at all.


+++ 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