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