On Thu, Nov 24, 2011 at 11:06 PM, Andrew Pollock <apoll...@debian.org>wrote:
>
> I've actually been poking at this some more, and it turns out I've made a
> grave error in assuming that by not requesting a particular option you
> don't
> get it anyway.
>
> It turns out in testing, that even not requesting the host-name option, if
> it's set in the server, the client seems to get it, so this totally blows
> up
> my grand plans of telling people who don't like the hostname setting
> behaviour to just not request the hostname, so I have to revisit
> everything.
>
> regards
>
> Andrew

I'm usually not a fan of the files, depending on the software, but maybe an
'/etc/default/dhclient' file would make sense here.  I don't mean to
over-complicate the "dhclient-script" here, but it would allow the
administrator to configure how the hostname is set with a simply flip of a
switch, instead of a hook needing to be made as well as having to worry
about what logic to use in the script.  For example in
/etc/default/dhclient:

set_hostname="yes" # sets the hostname every time
set_hostname="no" # never sets the hostname
set_hostname="detect" # maybe "dynamic", or something.  This option sets
the hostname based on what "/etc/hostname" looks like.  If the file exists
and contains no data, set the hostname.  If not, have the local hostname
override the one given out by DHCP.

I'm willing to bet, however, that there may be better options available.

For anyone who comes looking for a fix, here is a workaround I've managed
to throw together for an exit hook for dhclient that sets the hostname and
does some logic so it only sets it if needed.  Unfortunately, I do not have
the file on my local system but you can download the raw version of this
pastebin to "/etc/dhcp/dhclient-exit-hooks.d/set_hostname":

- http://pastie.org/2917845

That could probably use a little bit of cleaning up, but it works.

-Tim

Reply via email to