Re: NMU'ing for wishlist bugs? (aka: intent to NMU bind9)
On Mon, Sep 16, 2002 at 06:52:02PM +0200, Russell Coker wrote:
> On Mon, 16 Sep 2002 18:19, Stephen Frost wrote:
> > No, don't. If admins want it that way, admins will set it up that way.
> > By default, since the vast majority of people will *not* have bind
> > installed, do *not* require everyone have a user they will not use.
>
(..)
> named is more popular than all news servers combined, more popular than
> majordomo or uucp ever were (and they are much less popular now), more
> popular than msql... These other programs have their accounts in everone's
> /etc/passwd, why not named?
Reading Bug #95557 and Debian Policy [1] it seems to me that the
maintainer is not willing to use the 0-99 range (only for
'mandatory users') However passwd.master in base-passwd contains the
following users for services: news, uucp, proxy, postgres, www-data,
mail, list, and gnats.
Now, DNS server might be the #2 service in the Internet behind the web
service (www-data) and probably over mail ('mail', 'list') and many others
(postgres? gnats?).
I wonder: if you allocate the 'bind' user dynamically (should probably be
'named' better) how are nameservers going to share name zone
configuration? I wonder how would I need to switch from 'bind' to 'djbdns'
or 'maradns'.
Why do I ask this? Because if zone information is standard between name
servers (and I believe it is) there's no point on having that
configuration at /etc/bind since I might want to un-install bind and
install maradns (for example) while preserving my zone configuration. Is
it possible currently? No. Would it be neat? Yes. Does dynamic allocation
of the uid hinder this? Yes.
I vote on giving the name service a proper UID, since it's relevance is
comparable to a web server, news server or whatever. I want to be able to
switch servers and still keep the data (that's what /var/www is for, isn't
it?).
If you do not agree with me here, in any case bind should use 'adduser
--system' Right?
Regards
Javi
[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s10.2
Reply to: