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
signature.asc
Description: Digital signature
