bug#6235: hostname and -b option

[Bob Proulx]

Eric Blake wrote:
> Nelson H. F. Beebe wrote:
> > We noticed recently that Ubuntu's /bin/hostname has this option
> >     -b, --boot            set default hostname if none available

The longer documentation (from Debian Sid) is:

       -b, --boot
           Always set a hostname; this allows the file specified by -F  to
           be  non-existant  or  empty,  in which case the default hostname
           localhost will be used if none is yet set.

But note that Debian doesn't call hostname with -b or other
nonstandard argument.  I didn't actually test this (by installing GNU
hostname in /usr/local/bin/hostname and rebooting) but came to this
conclusion by inspection.  I could be wrong.  :-)

> > Unfortunately, Ubuntu's startup script puts /usr/local/bin ahead of
> > /bin and /usr/bin,

For userland uses of PATH I think it is well and good to put
/usr/local/bin in front of /usr/bin:/bin.  It allows the local site
admin to install a different executable in /usr/local/bin that will be
used.  But not if they have created an incompatible API.  For system
startup scripts that need to restrict operation to the system then
system startup scripts should have PATH set to just the system
directories and not including site local directories.  (Sometimes that
means just /sbin:/bin if the script is running before /usr is
mounted.)

> > thus getting a version of hostname that chokes on
> > the -b option.  We patched the configuration file to force an explicit
> > path:
> > 
> >     exec /bin/hostname -b -F /etc/hostname
> 
> Correct - Ubuntu's script is buggy if it uses non-standard options
> without an explicit path to a version of the utility known to provide
> those options.

I agree.  If Ubuntu is using an incompatible API in the startup script
then they need to ensure that they are calling their own version of
the command.

But even if they did that just feels like the wrong way to do things.
Instead they should use standard scripting to accomplish what they
want.  Then they could use any hostname implementation.  Plus this is
already a solved problem.  Here is what Debian uses:

     [ -f /etc/hostname ] && HOSTNAME="$(cat /etc/hostname)"
     # Keep current name if /etc/hostname is missing.
     [ -z "$HOSTNAME" ] && HOSTNAME="$(hostname)"
     # And set it to 'localhost' if no setting was found
     [ -z "$HOSTNAME" ] && HOSTNAME=localhost
     hostname "$HOSTNAME"

I am guessing that someone didn't like this scripting, read the
documentation for the hostname in use, saw that it supported the -b
and -F options and switched to using it without realizing the full
consequences of the change.  I don't have access to an Ubuntu system
at the moment to go check out the full story.

> > Would it be reasonable to consider adding support in coreutils for
> > the -b option?

When the behavior isn't traditional and is also so easily implemented
as desired by a line or two of shell script I vote against adding it
to the command.

> How would we (portably) implement it?  The problem is that coreutils'
> hostname has to compile on many more platforms than just Ubuntu, and
> there are just too many distro-specific actions (or even lack of OS
> interfaces altogether) for setting a default hostname.

Unfortunately with the description Nelson originally provided it read
as if this was setting something distro specific.  But actually the -F
option just reads the hostname from a file.

  hostname -F /etc/filename
    <=>
      hostname "$(cat /etc/filename)"

And the -b option just says to ignore an error if the file is empty or
does not exist, in which case set it to localhost.

  hostname -b -F /etc/filename
    <=>
      test -f /etc/hostname && HOSTNAME=$(cat /etc/hostname)
      test -z "$HOSTNAME" && HOSTNAME=$(hostname)
      test -z "$HOSTNAME" && HOSTNAME=localhost
      hostname "$HOSTNAME"

Sure that can be put in the executable.  But why?

> > [I'm not urging that this be done, merely that it be discussed.  In my
> > view, Ubuntu is at fault for introducing nonstandard options, and
> > messing up the boot PATH, and failing to use explicit paths on
> > critical boot-time commands.

If you are using Ubuntu and have been affected by this change then I
suggest filing a bug report against the scripts in question and
requesting that they revert this change.  I would file it against the
scripts that are calling hostname this way and not the hostname they
are using.  I assume it was a recent script change.  I also suggest
looking at the package history and seeing when this modification
occurred.  In which case you would have better leverage that it is
something to be reverted.  You could also note that Debian doesn't do
it that way. :-)

However your easiest path is to not install GNU hostname in
/usr/local/bin at all.  It shouldn't be getting installed by a default
build and install.  You must have enabled it.  It would be much
simpler to not and not use it.

Bob