Re: FQDNs for netbooted hosts via DHCP?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 14 Jul 2018 13:12:29 +0200
    From:        Martin Husemann <martin%duskware.de@localhost>
    Message-ID:  <20180714111229.GF3551%mail.duskware.de@localhost>

  | In userland, dhcpcd hooks should set the full name by default, if I read 
  | /libexec/dhcpcd-hooks/30-hostname correctly, not sure what goes wrong here
  | for John.

I think the cause relates to the way that need_hostname() works in that file.

Two things are clear ... if the host has no hostname set (or no meaningful
one, "localhost", etc, don't count), of if the dhcpcd.conf variable 
"force_hostname" is set to true (or yes), then (assuming no other settings
contradict things) then the hostname will get set (and default to the fqdn).

So, for John, putting

	env force_hostname=YES

(or true) in /etc/dhcpcd.conf should make things work as desired.
It would not hurt to also include

	env hostname_fqdn=YES

to force setting the FQDN, though that one should be the default if
nothing else overrides it.

The reason I suspect that works when not netbooted, is that in that case,
nothing has yet set the hostname (since John said he has no hostname=
in rc.conf) and so need_hostname() returns true., and the hostname gets
set.

But when a hostname has been set already, and force_hostname is not
set (or is set to false, or something) then we get to the somewhat
convoluted logic lower down in need_hostname()

But in that, it tests of either old_fqdn or old_host_name are set, which
if I guess correctly, means that dhcpcd has previously set the host name.
Here, it has not (the kernel did) so both of those should be empty.

When dhcpcd has not set the hostname, and there is a hostname,
need_hostname() returns false, and nothing gets set.   (That's that
final "false" in the else clause right near the end of need_hostname()).

I suspect this is to handle the case where the hostname has been set
by some other agency (like hostname= in rc.conf, or just by some user
running the hostname command).   In that case, by default, dhcpcd does
not override the other setting.

Here it was the kernel dhcp client that set the hostname, not dhcpcd,
so dhcpcd is justg leaving things alone.

Similarly, in the case that dhcpcd has previously set a hostname
(old_fqdn or old_host_name is not null) the script checks to see if
the current hostname set in the kernel is the same (actually, to me,
it looks like it just checks that it is likely the same, rather than 
definitely, but I might be misreading those cases) as the one dhcpcd
previously set, and refuses to alter it if something else has changed it.

kre