Bug 33258 - IP address of additional network interfaces is not correctly written into LDAP
IP address of additional network interfaces is not correctly written into LDAP
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Basic settings
UCS 3.2
Other Linux
: P5 normal (vote)
: UCS 3.2-0-errata
Assigned To: Philipp Hahn
Florian Best
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-11 17:00 CET by Alexander Kläser
Modified: 2014-01-29 11:17 CET (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:
klaeser: Patch_Available+


Attachments
Fix same network addresses (4.58 KB, patch)
2013-11-12 09:51 CET, Philipp Hahn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kläser univentionstaff 2013-11-11 17:00:47 CET
I added in system setup a new network interface (eth1) which I selected as primary interface. However, its IP address had not been added to the LDAP entry of the DC master. eth0 has the IP address 10.200.26.10, eth1 has 10.200.26.210.

DN: cn=master10,cn=dc,cn=computers,dc=ucs32,dc=qa
  domain: ucs32.qa
  ip: 10.200.26.10
  nagiosServices: ...
  ...
  service: ...
  ...
  unixhome: /dev/null
  dnsEntryZoneForward: zoneName=ucs32.qa,cn=dns,dc=ucs32,dc=qa 10.200.26.10
  dnsEntryZoneForward: zoneName=ucs32.qa,cn=dns,dc=ucs32,dc=qa 10.200.26.210
  dnsEntryZoneAlias: ucs32.qa zoneName=ucs32.qa,cn=dns,dc=ucs32,dc=qa 0d13bd6f-54dd-4246-b7fc-fa89f8357e9f._msdcs
  shell: /bin/sh
  mac: 52:54:00:4a:22:fc
  groups: cn=DC Backup Hosts,cn=groups,dc=ucs32,dc=qa
  groups: cn=Enterprise Domain Controllers,cn=groups,dc=ucs32,dc=qa
  groups: cn=Domain Controllers,cn=groups,dc=ucs32,dc=qa
  primaryGroup: cn=DC Backup Hosts,cn=groups,dc=ucs32,dc=qa
  password: {crypt}$6$hRvcidvUkJMMw2Bz$jUymShSUmqnok7ISdYSPouWrqK62DlzFB8tNXnnfU4akY.CvbU4293j/jvwMC/mUOtzDXTgcyO2UW9zxkZK5x0
  serverRole: master
  dnsAlias: 0d13bd6f-54dd-4246-b7fc-fa89f8357e9f._msdcs
  name: master10
  fqdn: master10.ucs32.qa
  dnsEntryZoneReverse: zoneName=26.200.10.in-addr.arpa,cn=dns,dc=ucs32,dc=qa 10.200.26.10
  sambaRID: 1000


The DNS entries seem to be ok:

root@master10:~# host master10
master10.ucs32.qa has address 10.200.26.210
master10.ucs32.qa has address 10.200.26.10


For the reverse DNS entries, 10.200.26.210 is missing as entry:

root@master10:~# host 10.200.26.10
10.26.200.10.in-addr.arpa domain name pointer master10.ucs32.qa.
root@master10:~# host 10.200.26.210
Host 210.26.200.10.in-addr.arpa. not found: 3(NXDOMAIN)


I am also not sure whether the 210-entry should be the first one in the host record:

udm dns/host_record list --superordinate zoneName=ucs32.qa,cn=dns,dc=ucs32,dc=qa

DN: relativeDomainName=master10,zoneName=ucs32.qa,cn=dns,dc=ucs32,dc=qa
ARG: None
  a: 10.200.26.10
  a: 10.200.26.210
  name: master10
  zonettl: 80600 seconds


root@master10:~# host -la ucs32.qa
Trying "ucs32.qa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35574
;; flags: qr aa ra; QUERY: 1, ANSWER: 29, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ucs32.qa.                      IN      AXFR

;; ANSWER SECTION:
ucs32.qa.               10800   IN      SOA     master10.ucs32.qa. root.ucs32.qa. 35 28800 7200 604800 0
ucs32.qa.               900     IN      NS      master10.ucs32.qa.
ucs32.qa.               900     IN      A       10.200.26.10
ucs32.qa.               900     IN      A       10.200.26.210
master10.ucs32.qa.      900     IN      A       10.200.26.10
master10.ucs32.qa.      900     IN      A       10.200.26.210
_gc._tcp.ucs32.qa.      900     IN      SRV     0 100 3268 master10.ucs32.qa.
gc._msdcs.ucs32.qa.     900     IN      A       10.200.26.10
gc._msdcs.ucs32.qa.     900     IN      A       10.200.26.210
_ldap._tcp.ucs32.qa.    900     IN      SRV     0 100 389 master10.ucs32.qa.
_kpasswd._udp.ucs32.qa. 900     IN      SRV     0 100 464 master10.ucs32.qa.
_kpasswd._tcp.ucs32.qa. 900     IN      SRV     0 100 464 master10.ucs32.qa.
_kerberos._udp.ucs32.qa. 900    IN      SRV     0 100 88 master10.ucs32.qa.
_kerberos._tcp.ucs32.qa. 900    IN      SRV     0 100 88 master10.ucs32.qa.
_kerberos-adm._tcp.ucs32.qa. 900 IN     SRV     0 100 88 master10.ucs32.qa.
_ldap._tcp.gc._msdcs.ucs32.qa. 900 IN   SRV     0 100 3268 master10.ucs32.qa.
_ldap._tcp.dc._msdcs.ucs32.qa. 900 IN   SRV     0 100 389 master10.ucs32.qa.
_ldap._tcp.pdc._msdcs.ucs32.qa. 900 IN  SRV     0 100 389 master10.ucs32.qa.
_kerberos._tcp.dc._msdcs.ucs32.qa. 900 IN SRV   0 100 88 master10.ucs32.qa.
_domaincontroller_master._tcp.ucs32.qa. 900 IN SRV 0 0 0 master10.ucs32.qa.
_gc._tcp.Default-First-Site-Name._sites.ucs32.qa. 900 IN SRV 0 100 3268 master10.ucs32.qa.
_ldap._tcp.Default-First-Site-Name._sites.ucs32.qa. 900 IN SRV 0 100 389 master10.ucs32.qa.
0d13bd6f-54dd-4246-b7fc-fa89f8357e9f._msdcs.ucs32.qa. 3600 IN CNAME master10.ucs32.qa.
_kerberos._tcp.Default-First-Site-Name._sites.ucs32.qa. 900 IN SRV 0 100 88 master10.ucs32.qa.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.ucs32.qa. 900 IN SRV 0 100 3268 master10.ucs32.qa.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ucs32.qa. 900 IN SRV 0 100 389 master10.ucs32.qa.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.ucs32.qa. 900 IN SRV 0 100 88 master10.ucs32.qa.
_ldap._tcp.d2d2f81b-5768-4da2-8d15-b183dd614881.domains._msdcs.ucs32.qa. 900 IN SRV 0 100 389 master10.ucs32.qa.
ucs32.qa.               10800   IN      SOA     master10.ucs32.qa. root.ucs32.qa. 35 28800 7200 604800 0
Comment 1 Philipp Hahn univentionstaff 2013-11-12 09:51:59 CET
Created attachment 5601 [details]
Fix same network addresses

Nasty: See Bug #28670 comment 42 for a similar issue, which was not fixed completely.

The problem is that ChangeSet.(old|new)_ipv[46]s() returns a *set* of IPNetwork() objects. If two interfaces are configured into the same sub-network, the second one is eliminated as a duplicate of the first one (because the network-address of x.x.x.1/24 and x.x.x.2/24 are both x.x.x.0/24 and thus the same).

AddressChange() only used that filtered view to detect, if there was change in the number of configured addresses and skipped all changes:

# grep "No address change" /var/log/univention/setup.log 
WARNING:uss.network.plug:Phase skipped: No address change

The attached patch fixed that by changing (old|new)_ipv[46]s() to return a list of all IP-Addresses instead of a set and moving the duplicate-network-filtering down into the individual checks.
Comment 2 Alexander Kläser univentionstaff 2013-11-12 10:00:07 CET
Cool, thanks, Philipp :) !
Comment 3 Florian Best univentionstaff 2014-01-16 11:49:22 CET
switching assignee & qa_contact because Philipp wrote the patch.
Comment 4 Philipp Hahn univentionstaff 2014-01-16 12:19:04 CET
univention-system-setup: r47175,r47178,r47181
YAML: r47182 branches/ucs-3.2/ucs-3.2-0/doc/errata/staging/2014-01-15-univention-system-setup.yaml
Comment 5 Philipp Hahn univentionstaff 2014-01-17 09:32:56 CET
For extra QA: There was a change to debian/u-s-s-boot.install; please verify that before and after the update the following directories contains the same file names:
 usr/share/univention-system-setup/startxwithfirefox
 usr/lib/univention-system-setup/cleanup-pre.d
 usr/lib/univention-system-setup/cleanup-post.d
 usr/lib/univention-system-setup/appliance-hooks.d
 etc/init.d

r47203, univention-system-setup_7.0.69-3.564.201401170856, r47204
Comment 6 Florian Best univentionstaff 2014-01-17 14:01:41 CET
The aRecord's for the host record in the dns forward zone are not updated/set.
Comment 7 Philipp Hahn univentionstaff 2014-01-17 14:42:17 CET
(In reply to Florian Best from comment #6)
> The aRecord's for the host record in the dns forward zone are not
> updated/set.

This only happens when additional addresses are added to an already existing address, which is not removed.

After discussion with Stefan, this will not be changed:
The current implementation of "class simpleComputer" only changes one IP address by default, not all addresses. Adding all IP addresses by default could lead to the situation, where Windows clients will pick the wrong IP address form a different subnet and are unable to connect. Because of that the DNS forward configuration should be explicit: If the admin required multiple addresses to be listed, she should do so herself.

We will wait for more user feedback on this issue.

PS: For IPv6 it is already required to iterate over all IPv6 addresses, since it is required to try all addresses returned by getaddrinfo() until a working one is found. We don't know what Windows implements, so we wait for more user feedback. See Bug #28562 for a similar issues with univention-join.
Comment 8 Florian Best univentionstaff 2014-01-20 10:19:43 CET
OK: IP address changes (within the same network) are correctly written into the ldap aRecord attribute of the computer object.

(In reply to Philipp Hahn from comment #5)
> For extra QA: There was a change to debian/u-s-s-boot.install; please verify
> that before and after the update the following directories contains the same
> file names:
>  usr/share/univention-system-setup/startxwithfirefox
>  usr/lib/univention-system-setup/cleanup-pre.d
>  usr/lib/univention-system-setup/cleanup-post.d
>  usr/lib/univention-system-setup/appliance-hooks.d
>  etc/init.d
> 
> r47203, univention-system-setup_7.0.69-3.564.201401170856, r47204
OK

(In reply to Philipp Hahn from comment #7)
> (In reply to Florian Best from comment #6)
> > The aRecord's for the host record in the dns forward zone are not
> > updated/set.
> 
> This only happens when additional addresses are added to an already existing
> address, which is not removed.
> 
> After discussion with Stefan, this will not be changed:
> The current implementation of "class simpleComputer" only changes one IP
> address by default, not all addresses. Adding all IP addresses by default
> could lead to the situation, where Windows clients will pick the wrong IP
> address form a different subnet and are unable to connect. Because of that
> the DNS forward configuration should be explicit: If the admin required
> multiple addresses to be listed, she should do so herself.
> 
> We will wait for more user feedback on this issue.
> 
> PS: For IPv6 it is already required to iterate over all IPv6 addresses,
> since it is required to try all addresses returned by getaddrinfo() until a
> working one is found. We don't know what Windows implements, so we wait for
> more user feedback. See Bug #28562 for a similar issues with univention-join.
OK

YAML: OK
Comment 9 Moritz Muehlenhoff univentionstaff 2014-01-29 11:17:23 CET
http://errata.univention.de/ucs/3.2/32.html