Bug#174360: DNS configuration section is inflexible
retitle 174360 host name-related setup options are confusingly restrictive
# can we compromise on this title?
thanks
Eduard Bloch wrote:
>This is not the DNS configuration. It is a common hostname of the system and
>has primarily nothing to do with DNS.
[Taking this one out of order.] By the phrase "DNS configuration" here
I'm trying to identify all the bits of configuration that relate to name
lookups, including looking up information about hosts from their name and
finding names for the current host. It might more correctly be called
"host name-related configuration"; I referred to DNS because we're in
fact using domain names for all the host names and doing name lookups
primarily using the DNS protocol (a DNS server address is one of the
things that gets configured).
>Hostname is a part of FQDN.
[Also out of order, because I'm establishing some conceptual basis here.]
The hostname, in the sense of gethostname(), can be any type of host
name that identifies the current machine. SUSv2 is silent on whether
it should be qualified or not; it's actually pretty silent on the domain
structure of host names, to allow the name lookup interfaces it defines
to be used equally with DNS, NIS, /etc/hosts, or any other database
or combination of these. The only real requirement seems to be that a
name lookup using the result of gethostname() should successfully find
information about the current host.
My personal preference for how to arrange name lookups is to do
all lookups in the DNS exclusively and to use FQDNs exclusively (no
unqualified names anywhere). In this arrangement the only correct
way to refer to the current host is by its FQDN, which implies that
gethostname() should return the FQDN. Many people choose to have
gethostbyname() return the FQDN even when their name lookup environment
does support implicit qualification of unqualified names. The principal
reason for doing this is that the FQDN is the only name for the host
that can be expected to have the same meaning on another host (which
may well differently qualify unqualified names), and there's no really
portable way for a program -- especially a shell script -- to find the
FQDN if gethostname(2)/hostname(1) doesn't give it. "hostname --fqdn"
most definitely isn't portable, though it's certainly a help for shell
scripts that know that it might exist.
>> When asking for a hostname, dbootstrap rejects any hostname containing
>> dots; it demands an unqualified name. This contradicts the reasonably
>
>RTFM.
Which FM? I see nothing in the installation manual, for example, that
explains such inflexibility. Do you have some manual that says that
the hostname must be an unqualified name? As stated above, I'd find
such a prescription surprising.
>> The next configuration dialogue asks for "the domain name" of the network.
>> This is a rather confused request. This information is actually used in
>
>I guess you have read lots of braindead documentation if it confuses you.
It's not me that's confused, it's the request. It displays some confusion
on the part of whoever wrote it. The confusion, as I explained, is in
thinking that "the network" has a domain name. Putting this kind of
wording in the installer is likely to pass on that confusion to those
who don't know better. It also forces those of us that do know better
to second-guess the author of the configuration program, to work out
what conceptual model he had of the things being configured.
>No, this is something not used by most users. "Power-users" can setup it
>manually. Remember, this is the INSTALLER. It configures the essential things.
>Keep it simple.
Interesting argument, and not without merit. I have several independent responses here.
Firstly, I usually find that using a correct conceptual model from the
start makes things simpler overall. I'm counting keeping the user's
mental model in line with how things actually work after installation
to be "keeping it simple". I must also point out that the dialogue I
proposed, with three questions about names, is only marginally longer than
the two questions of the existing dialogue, and it defaults the same way,
such that most users will just accept the default for the final question.
I don't envision the explicitly separated third question causing any
user confusion. In fact, I think making explicit the purpose for which a
configuration option will be used will be helpful to the user in working
out what to answer.
Another view: which is simpler: to have the installer support every
reasonable configuration, defaulting to the most common arrangement,
or to force everyone into the most common arrangement, including those
for whom it's not appropriate?
Let's try following your exhortation to "keep it simple". I think
we can make the configuration simpler than the current installer.
For starters, we don't need to configure a domain search list at
all: the only host names looked up during installation are for the
location to grab packages from, and they'll pretty much always be fully
qualified anyway (e.g., ftp.uk.debian.org). Next, why do we configure
the machine's own hostname? Nothing needs it during installation.
All we really need during installation is a DNS server address; all the
names can be configured later. I'm being semi-serious here: I think
that configuration of the various names relating to the host ought to
be presented as a normal thing to do somewhere during the install, but
it certainly doesn't need to be done that early, could reasonably be
delayed until after the boot of the minimal system, and if you want the
default dialogue to support only the most common configuration then it
could reasonably be made optional so that power users can do it manually
without having to invent an incorrect configuration to start with.
>And, finaly, please provide patches if you need some functionality. Talking
>and requesting features wont help us.
Looks like actual code patches would have been wasted work here.
I thought it more helpful for us to first discuss what the dialogue
sequence should be, by describing it in fairly explicit English,
which, for all my geekiness, I would still in this case find more
readable than C. Things might have been different had the dialogue been
written in a scripting language; C requires so much explicitness about
administrative details.
-zefram
Reply to: