cvs commit: src/etc/rc.d hostname

[Brooks Davis]

On Tue, Feb 13, 2007 at 10:04:36AM +0300, Yar Tikhiy wrote:
> On Mon, Feb 12, 2007 at 09:03:33AM -0600, Brooks Davis wrote:
> > On Mon, Feb 12, 2007 at 03:09:09PM +0300, Yar Tikhiy wrote:
> > > On Sun, Feb 11, 2007 at 09:44:38PM -0600, Brooks Davis wrote:
> > > > On Sun, Feb 11, 2007 at 11:53:17AM +0300, Yar Tikhiy wrote:
> > > > > On Sat, Feb 10, 2007 at 08:52:28PM +0000, Ceri Davies wrote:
> > > > > > On Sat, Feb 10, 2007 at 01:13:33PM +0000, Yar Tikhiy wrote:
> > > > > > > yar         2007-02-10 13:13:33 UTC
> > > > > > > 
> > > > > > >   FreeBSD src repository
> > > > > > > 
> > > > > > >   Modified files:
> > > > > > >     etc/rc.d             hostname 
> > > > > > >   Log:
> > > > > > >   Handle the case when the admin forgot to set $hostname,
> > > > > > >   which can happen in new installations: advise to set the
> > > > > > >   variable and refer to rc.conf(5).
> > > > > > 
> > > > > > Isn't it possible for the hostname to come via DHCP?  How does this
> > > > > > behave in that case (or rather, I can see how it behaves; is that the
> > > > > > right thing)?
> > > > > 
> > > > > I've never played with setting the hostname via DHCP.  In my change,
> > > > > I just tried not to break the existing code related to DHCP.  Perhaps
> > > > > someone using DHCP to get the hostname could shed light on the topic.
> > > > 
> > > > This appears mostly harmless for systems that get their hostname via
> > > > DHCP.  They will get a warning, but it will otherwise work.
> > > 
> > > Now I see.  The code getting $hostname via kenv from dhcp.host-name
> > > is for the case when the host was booted via PXE.  OTOH, a usual
> > > DHCP client will run dhclient when it comes to setting up network
> > > interfaces, i.e., after /etc/rc.d/hostname.  Perhaps we need
> > > a way to indicate that the hostname will be assigned automatically
> > > and the nagging message shouldn't be emitted.  E.g., in rc.conf:
> > > 
> > > hostname="DHCP"
> > > 
> > > I have no idea how many Unix hosts allow their hostname to be set
> > > via DHCP.  I prefer to think that a Unix host is like a good ship:
> > > it never changes its name while furrowing the network seas.  A DHCP
> > > assigned hostname better fits crippled hosts such as diskless
> > > stations etc.
> > 
> > I wrote patches many years ago that added a "default_hostname" variable
> > which acted like hostname except that dhclient-script knew about it and
> > would change the host name to one it was give.  This is the right thing
> > to do IMO because many applications break horribly if hostname is not
> > set.
> 
> OTOH, booting a DHCP-configured laptop without a network connection
> can result in its not having the hostname set at all.  This can
> warrant making $hostname a mandatory variable even for DHCP clients.
> dhclient will change the hostname if it gets a new value from the
> server.  Changing the default hostname to a DHCP value isn't worse
> than changing the null hostname, so the former shouldn't break any
> apps not broken yet.  I mean that dhclient may do the change a bit
> too late into the boot sequence if the DHCP server doesn't respond
> instantly.

dhclient will not change the hostname if it is set and this is probably
the right behavior for most people.  If we're going to make hostname
manditory, we need to provide an option to that dhclient can override
the hostname if that's what the administrator prefers.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20070213/635caadf/attachment.pgp