[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with Hostname
From: |
Benjamin Monjoie |
Subject: |
Re: Problem with Hostname |
Date: |
Sat, 11 Jul 2009 19:32:47 +0200 |
User-agent: |
Thunderbird 2.0.0.22 (X11/20090608) |
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 :)