Re: CVS commit: src/bin/hostname

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

    Date:        Thu, 25 Jul 2013 07:31:41 -0400
    From:        matthew sporleder <msporleder%gmail.com@localhost>
    Message-ID:  
<CAHKF-AvizrV8HnWqtA+7q9e7GUa9G5_ph+HFGK+TTB1pWszVyQ%mail.gmail.com@localhost>

First, for Thor, this is very definitely a side issue off the stupid
options for hostname(1) question - on that, so far, no-one (not even Roy)
has supported the existence of the options - so someone - anyone who can -
please revert that change.

This discussion kind of relates to just one of the added options, the -f
option, which is the only one of them that actually relates to hostnames.
It is kind of the inverse to the (pre-existing) -s option, and is intended
to operate when nicknames are used as the hostname to obtain the FQDN.
The question here is whether that option should remain, and if so, what should
it do.

My opinion is that it should go along with all the rest, as hostname -f
and just plain hostname are (or should be) equivalent, and adding a new option,
that does nothing, for no good purpose is silly.

Now for Matthew's message...

  | I've run hundreds of systems which use either a short hostname (no
  | domain) or which have zero relation to their DNS, forward or reverse
  | (amazon instances).  This included mail servers.

Sure, lots of people run mis-configured systems.  You can if you like, and
they might even seem to work, but that doesn't mean it is right, or that
we shouldn't try to encourage you to run systems configured correctly.

  | I think it is most common for systems to use a single, short name and
  | then fully qualify it in /etc/hosts (maybe).

Some people do that, but it only works if the software takes the extra
step of converting the short name to the long one (where it is needed,
converting a long one to short, when appropriate, ala hostname -s, is
trivial, and is done where it is needed).   Some software does, others does
not.

What we're discussing is what the interface (the API) is promising.
We all know that hostname(2) returns a string of characters, null terminated.
That part of the interface is clear.   The question is whether or not
applications are entitled to place any additional reliance on the value
returned (when the string isn't "").

  | Systems with multiple IP addresses, existing on many vlans, NAT-ing
  | traffic here and there, running many VirtualHosts (web or email), who
  | are members of a pool of systems configured similarly, etc, completely
  | ruin any idea that forward and reverse dns mean anything to a server.

Of course.   Please, everyone, totally forget any relationship between
names that look up in the DNS to return an IP address of the host, and
names returned from in-addr.arpa (or ip6.arpa) lookups of any address the
host owns, or any combination of similar DNS lookups.

That's not what is required.   All that is needed is a name that is
intended to be unique for this host.   How you get that is really not
the issue - it is just that using a properly assigned FQDN is an easy
painless way to get a name that is unique.  But if you're convinced
that setting your hostname to "rumplestiltskin" (or whatever) will
generate a name that no other system anywhere uses, then that's OK
(provided you're correct.)

  | In my opinion, the more options, the better.  Networks are complicated
  | and real life system installs even more so.

It has nothing to do with the network, the question is what software can
assume about the result of the hostname(2) system call (and its clones).

Take another example.   Systems run fine with the time (the result of time(2))
set to 1000000000 (that's something in September 2001).   You can set the
time that way (using date(1)) and everything will appear to work, more or
less fine (other than the off application like ntp, which we can assume
this particular host doesn't want to run).   But we know (really) that's
not right, and that isn't the correct time.

Now apps programmers who actually want the right time have a problem.  if
lots of hosts start setting the date to random values, how do they continue
working?   Well, one thing they could do, is write a function

        time_t
        network_time()
        {
                time_t t;

                t = result_of_some_network_query();
                return t;
        }

and then use it like


        time_t offset;

        time_t
        my_time(time_t *tp)
        {
                return time(tp) + offset;
        }

        main() {

                time_t offset = network_time() - time(0);
#define time my_time

                .... /* code that uses time() */

Of course, that really can be done better ways, but you get the point I
think - apps could start compensating for a common problem setting the time
by getting the time from the network (somehow) and calculating the error
with the local setting, and then compensating for that error every timethe 
local time is queried.

They could.

Should they?    Personally, I don't think so, I think apps are (and should
be) entitled to assume that time(2) returns at least a reasonable approximation
of the current (UTC) time, and should not need to have added code to go and
verify, or fix, errors in the results.

And if that's true for time(2), why shouldn't it be true for hostname(2)
as well?   Apps should be entitled to simply assume that it is a unique
string that belongs to just this one host, and is not shared by anything else
on (or off) the planet.

There's no question that (for both sys calls) most things will seem to work
OK with incorrect configurations, but the results just aren't really correct.

kre