Re: Problem with Hostname

[Bob Proulx]

Please configure your mailer to send plain text emails instead of HTML
email.  Sending HTML email is causing your messages to be severely
mangled.  Save the HTML for web pages.  Thanks.  Here is a reference
to your sent email so that you can see what we see.

  http://lists.gnu.org/archive/html/bug-coreutils/2009-07/msg00090.html

Benjamin Monjoie wrote:
> address@hidden:~]$ type -a hostname
> hostname is /usr/local/bin/hostname
> hostname is /bin/hostname

You have a local hostname in /usr/local/bin/hostname.  It is
overriding the system hostname (as it should) in /bin/.  Your system
did not provide /usr/local/bin/hostname.  You must have installed it
even if you don't remember doing it now.  That is the root cause of
your current issue.

> address@hidden:~]$   hostname --version
> hostname (GNU coreutils) 6.9

Yes.  And it is operating correctly as designed and does not support
the -f option.  No bug there.

> address@hidden:~]$   dpkg -l hostname
> ii  hostname       2.95           utility to set/show the host name or domain

The system hostname.  One of the other ones that isn't the coreutils
hostname.  That is the one that you have been expecting.  It supports
the -f option.  It is still installed and operating correctly.  Again
no bug there.  You are simply overriding it with a local copy in
/usr/local/bin/ (as that override is supposed to work) and are seeing
the GNU coreutils hostname behavior.

> address@hidden:~]$   dpkg -L hostname | grep bin/hostname
> /bin/hostname

A little test I threw in so that if Ubuntu were doing something that I
didn't now about I would learn where the command was located here.  I
don't have an Ubuntu system to test with at the moment.

> I am expecting/hoping to see /bin/hostname is the _other_ hostname in
> the system's hostname package and a /usr/local/bin/hostname that you
> perhaps (?) just installed from a source compile of GNU Coreutils.

And so it was!  :-)

>    I don't think i've installed the other hostname.

But you *did* install it.  You installed /usr/local/bin/hostname from
coreutils 6.9.  Locally installed files are by convention installed in
the /usr/local/ directory tree.  Software distributions (such as the
Ubuntu you are using and all other popular ones) do not install
anything in /usr/local and leave that entirely up to the local
administrator (you!) to do with as you see fit.  If you have a
hostname file there then it is because you have installed it.  I think
it much more likely that you simply did something recently and do not
remember doing it rather than that a security breach occurred and that
a malicious cracker broke into your machine to install GNU coreutils
hostname in your /usr/local/bin/.  :-)

If you suspect that you have installed a package that installed files
there then you can query the package manager for this.  This will
search the package database for any paths that match and will print
out any packages with files there.

  dpkg -S /usr/local/bin

This should not find any packages.  If they do then those packages
violate the system Policy document and you should report the bug to
them.  However, a purely local package is allowed to install files in
/usr/local since by definitely it is a local administratory option.
It is your directory.  You can do whatever you want there.

> It's probably my mistake but i don't see from where it came.
> But I've tried the following :
> address@hidden:~]$ sudo mv /usr/local/bin/hostname{,.bak}

Yes, move or remove the file if you do not wish to use it.

> [sudo] password for benjamin:

Strange that you would need sudo for this.  Does Ubuntu not support
the 'staff' group like its parent Debian does?  But that is a topic
for another time on a different mailing list.

> address@hidden:~]$ hostname -f
> bash: /usr/local/bin/hostname: Aucun fichier ou dossier de ce type

Unfortunatelly I cannot read that message but if it says what I think
it says then it is telling you that your shell has hashed (saved,
cached) the path that it previously found hostname at in
/usr/local/bin/hostname and now it will never look for it again and so
running hostname now _from that particular shell only_ has encountered
an error because the cached location has disappeared.  If you were to
try this from a different shell that had not cached the path then it
would have worked without problem.  You needed to do 'hash -r' to tell
the shell to rehash its table of saved command locations.

  hash -r

For documentation see:

  help hash

  man bash

You may want to set the bash option 'checkhash'.  See the
documentation for how it works.

  shopt -s checkhash

> address@hidden:~]$ sudo ln -s /bin/hostname /usr/local/bin/hostname
> ...
>    And it works. Although, it's not a very clean solution so if you have a
>    better one, i'm interested.

Now that you have learned about the shell's command table hash you
would be better served to remove your workaround.  It isn't needed nor
desired.

If you don't remember installing things into /usr/local then perhaps
it would be a good idea to review what is there and probably do some
cleaning of it.  Remember, the system doesn't put anything there
(except some empty directories to provide the basic structure) so every
file there is a file that you own completely.

  find /usr/local -type f -ls | less

Bob