[pkg-dhcp-devel] Bug#628141: Bug#628141: patch that should fix the isue

[Peter Marschall]

Hi,

On Saturday, 18. June 2011, Andrew Pollock wrote:
> On Sat, Jun 18, 2011 at 06:36:23PM +0200, Peter Marschall wrote:
> > Tomas has a point here.
> > While the part regarding the invalid variables was fixed in 4.1.1-17,
> > 
> > the logic still looks a bit fishy:
> >   "only set the host name if the old one and the new one are given"
> > 
> > (I am aware that I am the one to blame ;-)
> 
> You may be, but I'm not convinced this kind of logic belongs in
> dhclient-script in the first place.
I definitely am. git blame in my clone of your repo tells ;-)

> > Please find attached a patch that hopefully fixes the issue for good:
> > Here's the logic it tries to implement:
> > 
> > For the non-udeb case, set the hostname in Linux & kfreebsd only if
> > 1) the new hostname isn't empty
> > 
> >    <=> make sure that we do not reset the hostname to empty
> > 
> > 2) the current hostname is empty (or '(none)' or 'localhost') or
> > 
> >    matches the old hostname from DHCP
> >    <=> make sure that we only set the host name if there is
> >    
> >        no valid one or if the old hostname came from DHCP too
> > 
> > 3) the current hostname is empty or
> > 
> >    the new hostname from DHCP differs from the old one from DHCP
> >    <=> make sure that we set the host name only if it really changed
> > 
> > If you think it is the correct solution, please consider including it in
> > the next release of isc-dhcp for Debian
> 
> As I've said on this bug and another, I really think the best solution if
> you don't want DHCP to be determining your hostname is to not request it in
> the first place, not to have some tricky logic in dhclient-script itself to
> try and infer the intent of the local administrator.

I can understand this "no policy in the code" attitude well, but
my fear is that the original version:
a) also codes policy: 
   "$old_host_name and $new_host_name need both be non-empty"
   is a policy too: it requires $old_host_name to be set.
b) may be wrong as well:
    according to #609851, on boot $old_host_name is empty,
    precluding that host name gets set.

The argment "don' ask for the hostname if you do not want to set it" does not 
help, for two reasons
a) IIRC there's an option on the server side to send options even if they
    haven't been requested.
b) It may not hinder the server to do his part of things with the name it
    thinks it is the correct one (DDNS, ..)
    This may then confuse people, because you may get different
    views on the names depending where you are (local vs. remote)

What exactly don't you like in the new version?
I guess 1) is uncontroversial.
Which aprt of 2) and/or 3) is it?

Best regards
Peter

-- 
Peter Marschall
peter at adpm.de