Bug 133224

Note that this problem disappears if /etc/host.conf is set to "order
bind,hosts" and a nameserver is reachable.  If a nameserver is
unavailable, the problem occurs again.  This means hostname -s/-d can
give two seperate values depending on whether DNS is working or not.

If you want to get localhost.localdomain you have to use hostname -f
which displays short host name and the DNS domain name. Anyway I've
checked this bug on two different machines with same version of
net-tools and the results differs. Once I've seen
localhost.localdomain and on the second pc first alias (eg.
mypc.mydomain.com). "hostname -v" shows calling of gethostname()
function. My resume is that it's wrong setting of your DNCP server
which doesn't resolve your name correctly. 

substitude DNCP with DHCP

Sorry, but you are wrong. Perhaps you misunderstood the problem.  It
has nothing to do with the DHCP server (which BTW does resolve the
name correctly) or whether we use DHCP at all.  DHCP was only
mentioned as a possible reason why you put mypc.mydomain.com as an
alias in /etc/hosts, but it is also clearly the wrong thing to do.

This is the errant behaviour:

[root@mypc root]# hostname
mypc.mydomain.com
[root@mypc root]# hostname -a
mypc.mydomain.com localhost mypc
[root@mypc root]# hostname -f
localhost.localdomain
[root@mypc root]# hostname -s
localhost
[root@mypc root]# hostname -d
localdomain
[root@mypc root]# hostname -v
gethostname()=`mypc.mydomain.com'
mypc.mydomain.com
[root@mypc root]# hostname -vf
gethostname()=`mypc.mydomain.com'
Resolving `mypc.mydomain.com' ...
Result: h_name=`localhost.localdomain'
Result: h_aliases=`mypc.mydomain.com'
Result: h_aliases=`localhost'
Result: h_aliases=`mypc.mydomain.com'
Result: h_addr_list=`127.0.0.1'
localhost.localdomain

The installer places mypc.mydomain.com in /etc/hosts as an alias for
127.0.0.1.  The result is that when you attempt to get the short name,
or fqdn, you end up with localhost and localhost.localdomain
respectively.  

An strace on hostname reveals that it is using the resolv library,
consulting /etc/nsswitch (i.e. hosts: files dns) and /etc/host.conf
(i.e. order hosts,bind) to determine the host and domain names.

If you force resolv to use a DNS server (order bind,hosts in
/etc/host.conf, hosts: dns files in /etc/nsswitch.conf), or even just
make mypc.mydomain.com the primary for 127.0.0.1 and
localhost.localdomain the alias in /etc/hosts, you get the correct and
expected behaviour (i.e. no appearance of localhost or localdomain in
any of the above commands).

Placing mypc.mydomain.com as an alias in /etc/hosts is what is causing
the errant behaviour. Make the changes to /etc/nsswitch.conf,
/etc/host.conf and /etc/hosts and see for yourself.

What Alex said. It's nothing to do with the DHCP server, so reopening.

I think that the problem isn't with the functionality of hostname -s
but with the actual entry in /etc/hosts which is written by anaconda
and system-config-network.

For the hostname to be meaningful it has to resolve to the actual IP
address on the network you have set up. So the /etc/hosts should look
like this:

127.0.0.1 localhost.localdomain localhost
123.45.67.89 mypc.mydomain.com mypc

Substitute real IP above.
Then everything will work fine. This bug should get reassigned to
anaconda or system-config-network.

Yes feel free to reassign the component if you think that's appropriate.

Of course the /etc/hosts can look like you suggest, but only if you
know the IP address, which is what I was referring to right at the
start: you won't know this for DHCP which is probably why
anaconda/system-config-network puts the host name against 127.0.0.1.

I'm not convinced, but perhaps system-config-network (or whatever)
should only put the hostname against 127.0.0.1 if we're using DHCP,
and then the DHCP _client_ should rewrite /etc/hosts when it gets a
lease? Would that be the "correct" fix?

If hostname is to appear in /etc/hosts against 127.0.0.1, then it
should be the primary one to produce the correct behaviour for
hostname et al.

However, who knows what this solution will break if you make the
primary entry for 127.0.0.1 something other than localhost.

The proper solution IMHO would be to add *nothing* against 127.0.0.1
(leaving it well alone as localhost.localdoman localhost) and only add
a seperate entry for the hostname with the IP address obtained via
DHCP, if you are using DHCP. This is obviously is only to catch
instances when the host is disconnected from a network after obtaining
its address via DHCP or DNS/NIS/etc is not working.

Tomas is right about correct settings of /etc/hosts. Anyway it seems,
that system-config-network doesn't like this syntax and when the
hostname is changed it also rewrites /etc/hosts

[rvokal@garfield devel]$ cat /etc/hosts
127.0.0.1       localhost.localdomain   localhost
192.168.1.13    garfield

[rvokal@garfield devel]$ system-config-network
--> hostname changed from garfield to garfield-new <---

[rvokal@garfield devel]$ cat /etc/hosts
127.0.0.1       localhost.localdomain   garfield-new       localhost

So the correct /etc/hosts file should look like 

[rvokal@garfield devel]$ cat /etc/hosts
127.0.0.1       localhost.localdomain   localhost
192.168.1.13    garfield.mydomain       garfield

Reassigning this bug to system-config-network for additional comments.
In case of first /etc/hosts file the hosts are not resolved in
system-config-network hosts tab which I think is correct behaviour.
Anyway changing the hosthame affects only first line of /etc/hosts

Alex: I agree about the separate entry for the IP address when
obtained via DHCP, which is what I was also saying. But you have to
also deal with the case of the machine not having a DHCP lease or not
being on a network. The hostname has to map to _some_ address, and so
that has to be 127.0.0.1.

I've got related problems with hostname -s on EL3.  It's not the 
localhost line specifically, rather it's how hostname works (badly).  
Firstly, "hostname" always returns what the hostname was last set to, 
regardless of whatever's in the hosts file.  If the short name is not 
requested, I reliably get "hostname.domain.com", and it doesn't open 
any files!  So why does it not do what it says in the manual:
       -s, --short
              Display the short host name. This is the host name cut 
at the first dot.

hostname without -s appears to get the entire returned string from 
uname's structure.  With that, instead of "cutting at the first dot" 
it uses a completely different method.  That's a bug to me.  Here's a 
sequence I can repeat.  Note the results of the second hostname -s vs 
without the -s! :

With this /etc/hosts (which does not change during the tests):
172.1.2.3 hostname.domain.com hostname hostname1.domain.com hostname1
127.0.0.1 localhost.localdomain localhost

[root@hostname1 /]# hostname
hostname1.domain.com
[root@hostname1 /]# hostname -s
hostname
[root@hostname1 /]# hostname hostname2.domain.com
[root@hostname1 /]# hostname
hostname2.domain.com
[root@hostname1 /]# hostname -s
hostname: Unknown host
[root@hostname1 /]# hostname hostname1.domain.com 
[root@hostname1 /]# hostname
hostname1.domain.com
[root@hostname1 /]# hostname -s
hostname

An strace of hostname vs hostname -s reveals an interesting story...

"hostname" performs a bunch of system calls (it does not read any 
files apart from opening libraries), ending with a uname followed by 
the write...

"hostname -s" interrogates the /etc/resolv.conf, nsswitch.conf, 
host.conf, and hosts files on top of that, and gets the answer from 
the hosts file itself...

This is IMHO inconsistent and thus flawed.

If you change the hostname in s-c-network it does not automatically
change your /etc/hosts! 
If the new hostname does not resolv to a IP address through DNS or
/etc/hosts, it is added to localhost.

I still do not see why two so very different methods are used for two 
methods accessing one piece of information.

It's like asking you your full name, and you tell me what you've 
always known from when you first learnt how to say it and write it 
down.  Then I ask you your first name, and you have to look yourself 
up in the reverse phone directory and HOPE that you're in it.  It 
makes no sense.

The point is, the hostname command DOES NOT OPEN /etc/hosts when you 
don't ask for the full version.  But it does when you want the 
short.  This is inconsistent, and quite frankly, wrong.

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

I can confirm that the issue still exists in a fully up-to-date FC3.

The steps to reproduce are identical to previously, but I will repeat them
anyway: here I took a working system with hostname dargo. Using
system-config-network I changed the hostname (on the DNS tab) to dargon, which
doesn't exist in DNS. After doing that, I could do the following:
[root@dargo etc]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1	localhost.localdomain	dargon	localhost
[root@dargo etc]# hostname
dargon
[root@dargo etc]# hostname -s
localhost
[root@dargo etc]# hostname -a
dargon localhost
[root@dargo etc]# hostname -d
localdomain

So just as bogus as before.

Moving to fc3 as per comment #15.

For what it's worth, if you do a net install via anaconda, you get a correct
/etc/hosts file:

127.0.0.1               localhost.localdomain localhost
128.197.20.188          evol.bu.edu evol

I've added a note to hostname(1) about -s option describing the way it resolvs
the  hostname. I think this is enought to close this problem, changing the
current `hostname` behaviour doesn't make much sense to me. 

I don't know when the errant behaviour started, but it needs to be fixed and
made consistent with the behaviour of hostname on other *NIX implementations.
Documenting the problem is not an adequate solution or resolution to this
problem. Hence I request this bug be re-opened. 

I must agree with Alex' statement.  Please don't redefine bad program behaviour 
as normal by changing documentation.  Amongst other things, this unexpected 
behaviour breaks some (admittedly obscure) aspects of Oracle applications.  We 
settled for an ugly workaround while it was required.  Of course, it's not just 
broken in FC, it's broken in AS/EL too.

Hello,

hostname -s, hostname -f and hostname -d currently all work by looking up uname
with gethostbyname, and then working on the first result: -s uses first part, -f
all and -d the last part. hostname -a prints all aliases, not only the first.

hostname with no option returns uname without looking it up first (use -v to see
what hostname does).

So as I am upstream maintainer, I will at least fix the man page. However Ludwig
Nussel from Suse asked me, if it is preffered to have hostname -s use uname and
strip off a domain (since most new systems use a FQDN uname). This would avoid
the dns lookups and some confusion, act as documented (somewhat). But I am not
sure if the changed behaviour this might cause problems? (However i think
hostname -s is currently eighter wrong or the same has "hostname sans domain")

All users of "hostname -s" not wanting the DNS lookup could of course use 

bash> h=$(hostname); h=${h/.*/); echo shorthostname=$h

instead of changing the hostname semantic.

upstream:
https://cvs.berlios.de/cgi-bin/viewcvs.cgi/net-tools/net-tools/hostname.c?rev=1.12&content-type=text/vnd.viewcvs-markup