Re: Setting the hostname?

[Howard Chu <hyc symas com>]

Dan Williams wrote:
> 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 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?

That's all I can think of offhand.

I'm thinking that the fallback behavior is wrong - if gethostname() returns a 
non-empty string, then explicitly overriding it with localhost.localdomain is 
a bad idea.

> > > 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.

> > However, I think - please correct me if i am wrong - the problem as of
> > now is that NM wouldnt get any error from dnsmasq if its running, but
> > isnt actually used (e.g. no 127.0.0.1 in /etc/resolv.conf). Do you
> > think that dnsmasq through dbus could detect that and return an
> > error for such cases?

> 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.

Probably this DBUS interface should be standardized and an equivalent handler 
should be added to BIND. But as for the latter case - the patch already checks 
to see if dnsmasq is listening; if not then this feature isn't used and it 
simply falls back to the existing behaviors. Since dnsmasq is both a DNS 
server and a DHCP server, it is common for there to be multiple instances 
running (frequently to provide DHCP service to virtual machines and other uses 
on the same box). Only one of them can have DBUS enabled. Using DBUS is 
obviously not the default behavior in dnsmasq.

Since this is something that you msut explicitly enable on the dnsmasq side, 
it makes sense to me that if it's there, we can assume it's doing the right thing.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/