NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/55011 dhcpcd(8) sets "localhost" as hostname
The following reply was made to PR bin/55011; it has been noted by GNATS.
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: roy%marples.name@localhost
Cc: gnats-bugs%NetBSD.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: bin/55011 dhcpcd(8) sets "localhost" as hostname
Date: Tue, 21 Apr 2020 20:05:11 +0900
(sorry for a late response)
> The default behaviour since dhcpcd-6.10 has been to install the
> 29-lookup-hostname as an example script rather than include it as a default script.
>
> Without the default dhcpcd.conf, the hostname option will not be requested.
>
> So this is expected.
Ok, I see.
> > - The default name of "localhost" is annoying for me because
> > it's also used by sysinst as default settings in /etc/hosts.
> > Blank is still better for me.
>
> I've attached a patch below to address this.
> Let me know if it works for you!
I have not tested yet (sorry) but if it's changed to leave
hostname empty, it's enough for me.
> > Is there any intentional changes (lookup removal?) from 6.1.5 one?
>
> The 29-lookup-hostname hook was removed from the default installation due to a
> lot of user complaints.
> It's also IPv4 specific, although that could be improved.
> I have no intention of restoring it as a default hook.
>
> If you want a DHCP client to set the hostname, use the default dhcpcd.conf and
> ensure the hostname is set in the DHCP message.
>
> OR, set this in /etc/dhcpcd.enter-hook
>
> . /usr/share/examples/dhcpcd/hooks/29-lookup-hostname
Now I've checked dhcpd.conf(5) manual and noticed "use-host-decl-names"
entry:
---
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.example.com;
}
}
is equivalent to
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.example.com;
option host-name "joe";
}
---
Then I've added "use-host-decl-names on;" to server's /etc/dhcpd.conf
---
# Pass hostname to option host-name per each "host" declaration.
use-host-decl-names on;
[..]
host roppa {
hardware ethernet 00:c0:f6:xx:xx:xx;
fixed-address roppa;
server-name "mirage";
option root-path "/r/export/NetBSD/x68k/root";
}
---
and now at least NetBSD/x68k 9.0 dhcpcd in sysinst can get
an FQDN hostname as provided from the server. Thanks.
However, there are still two minor problems:
(1) FQDN hostname
As mentioned in hooks/30-hostname (or hooks/30-hostname.in in -current)
it looks dhcpcd(8) sets FQDN hostname by default.
(maybe using "domain-name" also provided by DHCP server?)
---
# A value of server means just what the server says, don't manipulate it.
# This could lead to an inconsistent hostname on a DHCPv4 and DHCPv6 network
# where the DHCPv4 hostname is short and the DHCPv6 has an FQDN.
# DHCPv6 has no hostname option.
# RFC4702 section 3.1 says FQDN should be prefered over hostname.
#
# As such, the default is hostname_fqdn=true so that a consistent hostname
# is always assigned.
: ${hostname_fqdn:=true}
---
However, it looks sysinst(8) in NetBSD 9.0 doesn't like FQDN hostname,
so that it explicitly asks hostname again even after dhcpcd
successfully gets an IP address and an FQDN hostname.
Should sysinst(8) be fixed to handle FQDN name properly, or
should we prepare customized "30-hostname" with "hostname_fqdn=false"
for all installation media and specify it in
src/distrib/common/list.dhcpcd?
(2) description of dhcpd.conf(5) man page
dhcpd.conf(5) from NetBSD 9.0 says the following in the
"use-host-decl-names" section:
---
It should be noted here that most DHCP clients completely ignore
the host-name option sent by the DHCP server, and there is no way
to configure them not to do this. So you generally have a choice
of either not having any hostname to client IP address mapping
that the client will recognize, or doing DNS updates. It is
beyond the scope of this document to describe how to make this
determination.
---
I guess that's the reason why the dhclient(8) used a looked up hostname.
Maybe we should patch (or send a request to change) this dhcpd.conf(5)
description to reflect modern dhcpcd(8) behavior?
Thanks,
---
Izumi Tsutsui
Home |
Main Index |
Thread Index |
Old Index