On Tue, Nov 22, 2011 at 11:06 PM, Andrew Pollock <apoll...@debian.org>wrote:
> On Sun, Nov 20, 2011 at 07:06:52PM -0500, Tim Heckman wrote: > [snip] > > > > Andrew, > > > > Thanks for the information about how it'll be implemented moving forward. > > Not to shy too far off-topic, I'm just trying to explain my use case for > > this. I work for a pretty well known cloud services provider. We create > > distribution templates for Debian as well as others. Most other > > distributions look at the state of the system to determine whether the > > hostname should be set by DHCP. I've yet to find a use case where this > > mechanism is wrong. We have our DHCP servers set the hostname by default > > so the system gets an initial hostname and is ready to go. Every other > > distribution checks the state of the system to determine if the hostname > > should be set. If the hostname setting is blank/empty they will set the > > hostname as obtained by DHCP. Otherwise, it sets the configured > hostname. > > > > I believe the behavior of it not even checking if the hostname should be > > set or not is surprising people as it had not forced it before (as far > as I > > am aware). This bug was opened because dhclient wasn't setting the > > hostname when it should. > > > > I'm not a huge fan of using it on servers, but the patch I submitted > > earlier was based on an idea I obtained from the way Ubuntu handles this. > > It checks to see if the /etc/hostname file contains any data. If the > > length of the file is zero, it sets the dhcp hostname. Otherwise, if it > > has data, it sets that instead. This provides a more uniform behavior > > across distributions. > > > > I definitely understand your insight on the changes you feel should be > > made. I agree that by default it should not request host-name, but I > still > > think the dhclient-script should contain the logic to check to whether it > > should set the hostname or not when it does request it. > > > > Thanks for getting it to set the hostname again in 4.2.2-1. I hope > you'll > > consider my feedback about the path that will be taken moving forward. > > Here's how I feel about the topic: dhclient-script shouldn't have policy > decisions hard-coded in it. So my policy is that there is no policy. > > I know that I can't please everyone on this matter, which is why > dhclient-script is slowly getting refactored so that everything is broken > out into shell functions that can be overridden by the local admin. > > Currently in 4.2.2-1, the hostname stuff is handled by a set_hostname() > function. > > You're free to provide a dhclient-enter-hook in > /etc/dhcp/dhclient-enter-hooks.d/ that redefines set_hostname() with > whatever local business logic floats your boat. > > I really feel like this is the best compromise, because I can assure you > that someone else will come out of the woodwork and argue the exact > opposite > position to you. My end goal is to get dhclient-script so that all of the > logic can be overridden by the local admin, without requiring local > modifications to dhclient-script itself. > > regards > > Andrew Andrew, Thank you for explaining the policy on your policy being no policy. :p But in all seriousness. I completely forgot about the hooks that can be used for DHCP and I entirely agree this makes more sense to do it this way. Thanks for the explanation. If you are State-side I hope you have a great Thanksgiving! -Tim
