Re: Setting the hostname?

[Dan Williams <dcbw redhat com>]

On Thu, 2008-09-25 at 19:28 +0200, Alexander Sack wrote:
> On Thu, Sep 25, 2008 at 05:23:17AM -0700, Howard Chu wrote:
> > I just updated my build tree from svn and I see that NetworkManager now 
> > tries to set the machine's hostname based on info various plugins may 
> > provide. This caused quite a bit of confusion here on my Ubuntu laptop - 
> > the hostname that was set by init during boot was used in the getty 
> > prompt, but shortly after my X session started, it changed to 
> > localhost.localdomain. X clients that were started after the hostname 
> > changed no longer had permission to talk to the X server, and so silently 
> > failed to launch, and a lot of cursing and swearing followed shortly 
> > thereafter.
> 
> This feature is still missing in the ifupdown plugin which in the end
> should be used for debian/ubuntu installs. keyfile from what i
> understand cannot do it in a distro independent fashion.

Tambet just added that yesterday.

> 
> >
> > I realize there are a lot of different use cases being targeted here, but 
> > I don't believe that overriding a non-NULL current hostname is a good 
> > behavior. Maybe it's ok if the current hostname is "localhost" but there 
> > aren't a lot of other situations where overriding would be the correct 
> > action.
> 
> The idea for ifupdown plugin is to read /etc/hostname. Are there other
> global configs we should respect?
> 
> >
> > Along similar lines, it's not always correct to accept a domain name from 
> > DHCP and stuff it into the local resolv.conf. I can see it in one use 
> > case, e.g. in a large network of non-mobile machines, where you really do 
> > want to just plug in the box and let it self-configure. But again, for a 
> > laptop that's used in multiple locations, it's incorrect. My laptop is 
> > part of my "symas.com" domain, no matter whose network I plug it into - 
> > office, the wifi at the coffee shop, a friend's house, wherever.
> >
> > This is another reason why supporting dnsmasq over DBUS is superior to 
> > using the resolvconf package - it leaves /etc/resolv.conf configured 
> > exactly as I set it, so I get consistent name lookups no matter where I 
> > am. It also obviates the need for most of the /etc/ppp/ip-{up,down} 
> > scripts too, for the same reasons.
> 
> In general, I like the idea of using dnsmasq through DBUS. I can even
> imagine that it could serve as a default setup for distros at some
> point.

Yeah; it's good but we need to think some about how to integrated it.  I
doubt we can just throw the switch today, but in the future we may just
ship with this enabled by default.

However, how do we handle the cases where somebody is already running a
caching nameserver that's not dnsmasq (ie, bind) or they have already
started dnsmasq and it's not using the dbus flag?  Only one process can
grab 127.0.0.1:53 at a time.

Dan