GNU bug report logs - #6235
hostname and -b option

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6235 in the body.
You can then email your comments to 6235 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
To: bug-coreutils <at> gnu.org
Cc: bowman <at> math.utah.edu, Brad Hawks <brad <at> physics.utah.edu>,
	beebe <at> math.utah.edu
Subject: hostname and -b option
Date: Thu, 20 May 2010 15:45:01 -0600 (MDT)

We noticed recently that Ubuntu's /bin/hostname has this option

    -b, --boot            set default hostname if none available

and uses it in /etc/init/hostname.conf.

However, the GNU version from coreutils-1.8 lacks that option.

Unfortunately, Ubuntu's startup script puts /usr/local/bin ahead of
/bin and /usr/bin, 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

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

At my site, I have

    % cat /etc/lsb-release
    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=9.10
    DISTRIB_CODENAME=karmic
    DISTRIB_DESCRIPTION="Ubuntu 9.10"

    % uname -r
    2.6.31-21-generic-pae

    % /bin/hostname --version
    hostname 2.95

[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.  We had issues a few months ago with GNU
inetutils that have since been resolved by adding support in inetutils
for an option expected by Ubuntu.]

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe <at> math.utah.edu  -
- 155 S 1400 E RM 233                       beebe <at> acm.org  beebe <at> computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Message #8 received at 6235 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
Cc: 6235 <at> debbugs.gnu.org, bowman <at> math.utah.edu,
	Brad Hawks <brad <at> physics.utah.edu>
Subject: Re: bug#6235: hostname and -b option
Date: Thu, 20 May 2010 16:31:14 -0600

[Message part 1 (text/plain, inline)]

On 05/20/2010 03:45 PM, Nelson H. F. Beebe wrote:
> We noticed recently that Ubuntu's /bin/hostname has this option
> 
>     -b, --boot            set default hostname if none available
> 
> and uses it in /etc/init/hostname.conf.
> 
> However, the GNU version from coreutils-1.8 lacks that option.

coreutils 1.8 doesn't exist.  Did you mean coreutils 8.5?

> 
> Unfortunately, Ubuntu's startup script puts /usr/local/bin ahead of
> /bin and /usr/bin, 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.

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

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.

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

Your view is correct.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 6235 <at> debbugs.gnu.org (full text, mbox):

From: C de-Avillez <hggdh2 <at> ubuntu.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 6235 <at> debbugs.gnu.org, bowman <at> math.utah.edu,
	"Nelson H. F. Beebe" <beebe <at> math.utah.edu>,
	Brad Hawks <brad <at> physics.utah.edu>
Subject: Re: bug#6235: hostname and -b option
Date: Thu, 20 May 2010 18:16:50 -0500

[Message part 1 (text/plain, inline)]

On Thu, 2010-05-20 at 16:31 -0600, Eric Blake wrote:
> > Unfortunately, Ubuntu's startup script puts /usr/local/bin ahead of
> > /bin and /usr/bin, 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.

Ubuntu does not install *anything* under /usr/local -- this is a path
reserved for local stuff. On Ubuntu, 'hostname' is installed from the
hostname package. As such, there are no non-standard options being
played.

<snip/>

> > [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.
> 
> Your view is correct.
> 

I was looking at the coreutils source (git). 'hostname' is set not to be
installed by default (together with 'arch' and 'su') -- unless one
runs ./configure  --instal-program=hostname.

I am failing to see how Ubuntu is messing up the boot path;
additionally, there is no conflict for 'hostname' unless one installs
something outside of the distribution (but, then, all bets are off,
anyways). For example, I usually run coreutils git, and have no problems
like the OP.

Thank you,

..C..

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 6235 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
Cc: 6235 <at> debbugs.gnu.org, bowman <at> math.utah.edu,
	"Nelson H. F. Beebe" <beebe <at> math.utah.edu>,
	Brad Hawks <brad <at> physics.utah.edu>
Subject: Re: bug#6235: hostname and -b option
Date: Thu, 20 May 2010 18:23:29 -0600

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

Message #17 received at 6235 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>, 6235 <at> debbugs.gnu.org
Cc: bowman <at> math.utah.edu, Brad Hawks <brad <at> physics.utah.edu>
Subject: Re: bug#6235: hostname and -b option
Date: Mon, 7 Jun 2010 17:52:01 -0600

Hi Nelson,

Have there been any new developments with this issue?

Note that the BTS is tracking it here:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6235

Bob

Message #22 received at 6235-done <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>, 6235-done <at> debbugs.gnu.org
Cc: bowman <at> math.utah.edu, Brad Hawks <brad <at> physics.utah.edu>
Subject: Re: bug#6235: hostname and -b option
Date: Wed, 24 Aug 2011 23:33:20 -0600

> Have there been any new developments with this issue?
> Note that the BTS is tracking it here:
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6235

It has been a year since any feedback has been provided on this issue
in the bug tracking system.  I assume that the discussion logged so
far was sufficient.  Therefore I am closing this bug.  If you have
more information for it that is great.  It is okay with me if you wish
to re-open the bug.

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.