DHCP set hostname is not working.

Issue #39 resolved
Rémi Audebert created an issue

Issue: hostnames should be auto-configured using DHCP at boot, but they are not.

We currently rely on sadm/python-lib/prologin/set_hostname.py to set the hostname, which is hacky and not a good solution.

Proposed fix: As seen on http://www.bctes.com/dhcpd.conf.5.html the DHCP hostname configuration is enabled using the host-name option, which we do not have activated on our present setup. An even better option is use-host-decl-names. Extract from dhcpcd.conf(5):

The use-host-decl-names statement

         use-host-decl-names flag;

         If the use-host-decl-names parameter is true in a given  scope,  then
         for  every  host declaration within that scope, the name provided for
         the host declaration will be supplied to the client as its  hostname.
         So, for example,

             group {
               use-host-decl-names on;

               host joe {
                 hardware ethernet 08:00:2b:4c:29:32;
                 fixed-address joe.fugue.com;
               }
             }

         is equivalent to

               host joe {
                 hardware ethernet 08:00:2b:4c:29:32;
                 fixed-address joe.fugue.com;
                 option host-name "joe";
               }

Test procedure:

Expected results:

  • DHCP offers should contain the host-name option. Debug using tcpdump/wireshark.
  • The machine should use the DHCP hostname. Hostname is displayed on kdm.

Comments (9)

  1. Pierre Bourdon

    I seem to remember this not working because we rely on the kernel for the initial DHCP requests, and re-running a DHCP client from the nfsroot was causing disconnects and screwing up everything. Probably worth testing again anyway.

  2. Rémi Audebert reporter

    So this boils down to forwarding the hostname iPXE received using his DHCP request to the kernel, without breaking the network stack.

    Side note: currently in etc/prologin/netboot.yml, we ask the kernel to configure eth0 using DHCP, which is redundant because iPXE already acquired an IP.

    We should see if it is possible for iPXE to forward its IP configuration to the kernel using something like that in netboot.yml:

    options: root=/dev/nfs ip=:${ip}::${gateway}:${netmask}:${hostname}:eth0:none nosplash
    

    Potential issue: what about the DHCP lease-time? should we care? Currently it is set to 30 minutes for fast recovery if we screw something up. AFAIK it doesn't matter because IPs are statically allocated in the DHCP server, but I can miss the point.

    Edit: OK we may still need a DHCP client on the machine in case of the interface go down and need to be reconfigured. An interface may go down for a number of reason, the main one is a user unplugging the network cable of the machine.

    Refs:

  3. Robin Thoni

    The iPXE chain command seems to be able to pass arguments to the kernel, so putting them in python-lib/prologin/netboot/script.ipxe:13 instead of netboot.yml may do the trick.

    Interface does not seem to lose IP when disconnected. In case of troubles, network settings can be recovered from /proc/cmdline

    Refs: * http://ipxe.org/cmd/chain

  4. Antoine Pietri

    I took some time to rebase your PR on master. It's still using "none" as a last argument of ip= on the kernel command line. Should we change it to "dhcp" like @halfr suggested in his last comment?

  5. Log in to comment