Re: Problem with Hostname

[Benjamin Monjoie]

Bob Proulx a écrit :
> 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

My Bad, i'm sorry

> 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/.  :-)

I remember that, about a year from now,  i tried to install a patched
coreutils to add a progress bar but it didn't worked well so I removed
it. I must have left some garbage behind. It's just strange that the
"error" occurred now and not before.

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

/usr/local/bin and its contain belongs to root:root but my system is not
a reference because i've made a lot of tests on it and i've never
reinstalled it. There have to be a lots of workarounds and garbages.

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

Thanks a lot for your help and explanations. I'm glad to learn a bit
more about GNU/Linux :)