Re: CVS commit: src/bin/hostname

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 30 Jul 2013 05:05:55 +0000
    From:        David Holland <dholland-tech%NetBSD.org@localhost>
    Message-ID:  <20130730050555.GA12083%netbsd.org@localhost>

  | "The" missing part isn't necessarily uniquely determined or even well
  | defined.

It should be.   It isn't difficult.

  | If my laptop moves back and forth between multiple sites, as
  | many laptops do, and those sites have different DNS, as is not
  | uncommon when e.g. some of them are public- or customer-access wifi,
  | does its "real" hostname change every time it moves?

You were clearly paying no attention to anything I wrote ... no, of
course it doesn't, or doesn't need to - your system's name is its name,
and where it is connected is 100% irrelevant.

Of course, if you want to pretend that you have multiple different systems,
with multiple different names, and you use a different one in each
different environment you find yourself (ala James Bond, or something) that's
fine too.

  | Or do I have to
  | pick one of the many DNS names it might appear under to be canonical
  | and treat the others as second class?

For better or worse, the hostname interface is (and always has been since
it was first created) a single name (at any one instant).  So you are
limited to a single proper hostname - you can have as many aliases as you
like - and you can change names as often as you feel inclined (just as in
any other context though, changing names usually introduces problems.)

  | What about if one of the names is something like
  | wireless-192-168-70-202-toronto-ontario.northeast.bigcoffeecorp.com?

I think you're thinking of PTR DNS records from he in-addr.arpa (or ip6.arpa)
domain.  IMO (for what it is worth) those things are essentially obsolete
these days, and mostly a complete waste of everyone's time (for reasons
like the example given above, and others).  I have given up populating those 
zones at all.   To become relevant again, the operating mentality would need
to alter, so that systems could dynamically update the entry(/ies) corresponding
to their own assigned address(es) either directly, of via the dhcp server
when there is one.  Of course, in IPv4, that's mostly useless anyway, because
of NAT and 1918 addresses, so this would really need to be a v6 thing if it
were ever to happen.   Probably better to just phase out i*.arpa domains and
PTR records completely...

  | Ultimately the "real" hostname, whether it's "siwenna" or "stelmaria"
  | or "sakido" or whatever, is how you refer to the computer and
  | distinguish it from others you deal with.

Yes, but while convenient for you, it is also how others see it, and it
should have a name that anyone can use to refer to it (which doesn't
necessarily mean contact it - there does not have to be anything in the
DNS for your hostname if you don't want there to be.)

  | In most environments, one
  | name's enough, just like we don't normally use the full set of names
  | and titles to address people.

Yes, use of a shortened, or nickname is often appropriate, and
convenient - but only truly when we have a full name that we can
use when appropriate.   You call your system sakido perhaps, what happens
if I do too, and we meet at a conference, and someone says "the computer called
sakido is attacking others ..."

  | Even when there's a single uniquely
  | determined FQDN for each host, adding the domain part to the hostname
  | just wastes horizontal space in logs and other places.

Fine, then drop it from places where it isn't needed.   That's trivial.

Lastly, for those who aren't convinced that the hostname was always
intended to contain the full name (even though the man page doesn't
explicitly say that - back at the time no-one would have ever considered
it needed to be explicitly stated) let me offer 3 more items of
evidence.

First from the hostname(1) man page ... the existence of the -s option (true,
it was not there originally, but as has been pointed out, hostname(1) predates
domain names and the need for -s) - if hostnames were not intended to contain
the FQDN, what use would the -s option be?

Second is from the bugs section of gethostname(3) (and sethostname(3))
(which were originally section 2 functions of course) ...

     Host names are limited to MAXHOSTNAMELEN (from <sys/param.h>) characters
     including null-termination, currently 256.

Single labels (in the DNS) are limited to 63 chars (octets really,
in the case that a multi-byte char set was in use), and it is unlikely in
the extreme that anyone (even Welsh & Germans...) would name something with
a name even that long - if a 256 byte limit is considered a bug, then the
hostname must have been intended to contain more than a single label, right?
[Aside: the full name of Bangkok, in Thai, is probably about that long, but
that's a most obscure case...]

And third, from way out in left field, is the "he" capability from
gettytab(5).   I totally understand that no-one here is going to have
any idea what that is, or why it exists, or its relevance, so I will
tell you ...

The man page (gettytab(7)) just says ...

     he        str               NULL       hostname editing string

and then in the BUGS ...

     The he capability is stupid.

That's its sole documentation (I think.)   It wasn't originally part of
gettytab(7) - or not as it was originally created, I know, because I
created it.   Rather, when I offered this version of getty to Sam Leffler
for 4.2BSD (to replace the older one which had everything compiled in)
the one request that was made, was a way to deal with the hostname printed
in the login prompt.

The hostname for the hosts at Berkeley (in those pre domain days) was set
to things like "ucbarpa" "ucbmonet" "ucbokeeffe" (and ucbvax of course),
but what they had traditionally printed as a login prompt was "monet login:"
(or similar) and they wanted to keep that.

That is, the hostname contained (what was at the time) the fully qualified
form, and (just as today) there was a desire to abbreviate it for local use.

That's what led to the (stupid) he capbility, it allowed the "ucb" part
of the hostnames to be dropped before the (modified) hostname was used
by getty as part of the login prompt.

Once again, if hostnames had been set to just "monet" "okeeffe" etc this
would never have been needed - but from way back when the hostname sys calls
(now replaced by sysctl node, and libc wrapper for compatibility it seems)
were first added, they were always assumed to contain the full unique
hostname of the node, and that's what software ought to be able to assume.

If you only want the first label, then looking for a dot and dropping
everything after is really easy.

kre

ps: someone should really drop the he nonsense from NetBSD's getty, whatever
use it once had, it is certainly not useful, for anything, any more.