On Fri, Nov 25, 2011 at 7:25 PM, Andrew Pollock <apoll...@debian.org> wrote:
> On Fri, Nov 25, 2011 at 01:25:39AM -0500, Tim Heckman wrote: > > 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. > > Is this targeted at 4.2.2-1 or earlier? > My apologies for not clarifying. This is designed for the current Debian Squeeze version (4.1.1-P1-15+squeeze3). > If it's targeted at 4.2.2-1, it should be a case of a dhclient-enter-hook > that redefines the set_hostname() function. > > Using an exit hook means the hostname is going to flip flop, which probably > isn't the end of the world. > In the Debian Squeeze version the $new_host_name variable does not appear to be populated with any data when the enter-hook script runs. It also appears the hook debug scripts don't print out all of the variables that may be available (had to add "new_host_name" manually). As a note for anyone interested in using that hook on the Squeeze version: I did notice something strange with my exit-hook. It appears that the Getty spawns before the hostname gets set using this method so my login prompt has "(none)" until I log in for the first time. Nothing breaks, is just slightly annoying and actually adds another problem that I must resolve while I search for the solution I need (go figure). -Tim