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
pe...@adpm.de
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
