DHCP set hostname is not working.
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:
- Add
use-host-decl-names on
indhpcd.conf
- Remove
set_hostname,py
(revert 83b5cdc11b01862fb5314ef3f97120cd268a6663 and childs) - Boot a machine with PXE and DHCP
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)
-
-
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 configureeth0
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:
-
reporter -
assigned issue to
-
assigned issue to
-
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
-
Suggested configurations worked like a charm, see commit ba85a21 and pull request
-
- changed status to resolved
-
- changed status to open
-
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?
-
- changed status to resolved
Fixed by 738c993851d7
- Log in to comment
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.