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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
