Univention Bugzilla – Bug 28562
Join should store all IP- and MAC-addresses - currently uses wrong MAC for DHCP
Last modified: 2017-08-08 07:08:30 CEST
aufgefallen an Ticket#2012090721000811 Ein DC Slave dessen Interfaces eth0, eth1 mittels Bonding zusammengefasst sind und dessen eth4 das primäre Interface mit der Domänen IP Adresse sein soll, schlugen während das Joinvorgang die Joinskripte univention-bind und univention-ldap-server fehl. Im LDAP war daraufhin außerdem die MAC Adresse von eth0 mit der IP Adresse von eth4 hinterlegt.
Seit Bug #26058 (UCS-3.1) ist es möglich, auch ein anderes Interface als eth0 über die UCR-Variable "interface/primary" als Haupt-Interface festzulegen. Das univention-join nur eth0 übermittelt ist bereits in Bug #16807 angesprochen und in Bug #10977 beanstandet. Von daher eigentlich ein Duplikat von den 3 Bugs.
*** Bug 10977 has been marked as a duplicate of this bug. ***
univention-join uses the "default_address", but always uses the address of the first interface. This breaks DHCP, as the interface order may be random for each boot. univention-join:494 > mac_addr="$(LC_ALL=C ip link show | sed -rne 's|.*link/ether ([0-9a-fA-F:]+) brd .*|\1|p' | head -n1)" > if [ -n "$mac_addr" ]; then > »···args+=(-mac "$mac_addr") > fi At a customer site that became a problem, as the first interface was not the interfaces used for DHCP and thus the wrong DHCP-Host-entry was created. IMHO during join at least all MAC- and IP-addresses should be stored in LDAP (UMC supports this). If DNS and DHCP entries should be created for them all is a different issue (IMHO: yes).
Encountered once more at a customer: Only a random interface and the wrong IP was registered, overwriting the already correctly registered IP- and MAC-address in UDM. This each time broke the next run of a fully-automatic UCS-3.2 network installation. (The problem is that through univention-join "udm computers/$role --set ip=... --set mac=..." is called, which updates the existing "dhcpZoneEntry" to match the new IP and MAC addresses). This is quiet unfortunately, as DHCP entries would only be created for new "managed-" and "mobile-clients", but they are no longer supported since UCS-3.0. So the current implementation destroys the setup explicitly entered by the admin from before the join.) I have a patch to register all MAC and IP addresses...
Created attachment 5694 [details] Reister all MAC and IP addresses + cleanup Tested only with a 3.2 member server for join and re-join. Please re-check for correctness before applying: * "Remove password from commandline": There might still be tools not handling --bindpwdfile... * Refacture SSL CA copying": A DC-Slave now fails if "/etc/ldap-backup.secret" can not be copied. * Handling for "Client and Mobile Client" in univention-join could be removed, as those roles are no longer supported since UCS-3.0. Also the code is now equal to that for "Memberserver".
I noticed a problem with bonding: bonding changes the MAC-address of the slave interfaces, so if such a host is joined, not all "native" MAC-addresses are registered, but only those of the chosen primary. Also notice that when testing with QEMU/kvm, the MAC-addresses are not reset when the VM reboots, but only when it's turned off and on again.
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
There is a Customer ID set so I set the flag "Enterprise Customer affected".
This issue has been filed against UCS 3.0. UCS 3.0 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.