Re: CVS commit: src/bin/hostname

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Jul 30, 2013 at 02:54:20PM +0700, Robert Elz wrote:
 >   | 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.

Not entirely, but as I was trying to post only once it came out that
way. My fault.

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

Where? As far as I know the only place any of my hostnames appears in
public (at least intentionally) is in gnats, where a PR submission
normally includes uname output. Oh and I suppose a few LAN protocols
send out (by default) the hostname for resource browsing purposes, but
unless you're on my LAN you won't see those.

You were just (in the text I pruned) describing DNS PTR records as
obsolete and irrelevant, so apparently in your world you don't even
get that information -- all you have is the IP address I'm sending
packets from, which is probably a firewall and not the host I'm
actually using.

If you have some reason to talk to me about my hosts (and things like
"your desktop" aren't adequate referents) then you probably know my
internal names, and if you care enough for some reason to bother
keeping track of them, distinguishing mine from yours from context
isn't exactly a big challenge. (We do this all the time; if person A
talks about "Matt" without further qualification it's usually a
different Matt from when person B does, but this very rarely causes
confusion.)

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

...then the computer in question is probably neither yours nor mine
but a different one entirely, exploiting the naivete of the person who
thinks a hostname an attacker uses to describe itself is meaningful
information.

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

Yes, it's not needed in the kernel hostname string.

 > Lastly, for those who aren't convinced that the hostname was always
 > intended to contain the full name

Like other people have said, I remember 20+ years ago when the
hostname was basically never the FQDN and people used the kernel
domainname string for both the NIS domain and DNS domain. It was only
later that people stopped equating the last two items and proclaimed
that the hostname should include the DNS domain, and lots of
traditionalists, myself included, never went along.

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

When was it added? It appears to predate NetBSD and I don't have the
CSRG history on hand.

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

That was written at a time when it was commonly believed that in an
ideal world nothing (particularly not arbitrary strings like names)
should be length-limited. I'm not sure that constitutes evidence.

Anyway, such evidence isn't really relevant; the widespread customary
practice in 1990 was as I described above... plus circumstances have
changed quite a bit in the meantime.

 > And third, from way out in left field, is the "he" capability from
 > gettytab(5).  [...]

That should certainly be removed. However, there's a lot of stuff in
getty that should be removed and I think the reason nobody has is that
it's not clear where to stop once you get started...

-- 
David A. Holland
dholland%netbsd.org@localhost