Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 72572 - /etc/hosts file configuration for lonely or fully integrated 'incorrect'
Summary: /etc/hosts file configuration for lonely or fully integrated 'incorrect'
Status: RESOLVED FIXED
Alias: None
Product: [OLD] Docs-user
Classification: Unclassified
Component: Handbook (show other bugs)
Hardware: All Linux
: High trivial (vote)
Assignee: Sven Vermeulen (RETIRED)
URL: http://forums.gentoo.org/viewtopic.ph...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-26 11:33 UTC by Leon
Modified: 2004-12-22 13:35 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leon 2004-11-26 11:33:06 UTC
This isn't exactly a bug, but I think it matters whether 'localhost' appears first in the list of aliases.

Changing the order as suggested in the URL removed the unknown_domain string that appears before the login prompt.

Reproducible: Sometimes
Steps to Reproduce:
1. Please see the URL
Actual Results:  
The dnsdomainname was resolved successfully

Expected Results:  
Not applicable?
Comment 1 Sven Vermeulen (RETIRED) gentoo-dev 2004-11-26 13:40:53 UTC
I don't really see what message in that entire thread you are referring to.

What do you think is wrong with the two /etc/hosts that are listed in the handbook?

"""
127.0.0.1     localhost
192.168.0.5   jenny.homenetwork jenny
192.168.0.6   benny.homenetwork benny
192.168.0.7   tux.homenetwork tux
"""
and
"""
127.0.0.1     tux.homenetwork tux localhost
"""
Comment 2 Leon 2004-11-27 02:51:57 UTC
Fair enough comment.

My orignal request in the thread was an attempt at trying to understand how the dnsdomainname is set in the scenario drawn. The reason that mattered is because the welcome message at the login prompt "This is hostname.domainname (Linux ..." didn't work, it displayed "This is hostname.unknown_domain (Linux ...".

The specific bit of the documentation that I think isn't completely correct is Code Listing 20 "127.0.0.1     tux.homenetwork tux localhost". I think "127.0.0.1     tux.homenetwork localhost tux" is interpreted differently and on my build it then sets the dnsdomainname correctly.

Please see the bit about "hostname -v -d" and "hostname -F < /etc/hosts" in the thread for more details if you need it.

I know that it shouldn't matter, but it appears that it does.

Thanks
Comment 3 Xavier Neys (RETIRED) gentoo-dev 2004-11-27 06:26:36 UTC
I can't see anything wrong with the current doc either.
I remember seeing a lot of confusion about what sets which domain name in the mentioned thread on forums.g.o. I can't read again because f.g.o pining for the fields at the moment.

I'll try to sum it up for you:

* Setting the hostname
You just need the name in /etc/hostname, name only, NO FQDN.
# echo "basil" > /etc/hostname
Add hostname to your runlevel

* Setting the dns domain name
You only need to list it in resolv.conf
FYI, the init script domainename will only read /etc/dnsdomainname and write it to /etc/resolv.conf. You do not need it in your runlevel.
# echo -e "domain a.la.maison\nnameserver x.y.z.t" > /etc/resolv.conf
Replace x.y.z.t with your nameserver IP, it could be the internal IP of your router or the IP of your ISP's nameserver.

* Login prompt
/bin/login displays the hostname previously set up followed by 'login:'
What you call the login prompt "This is...." is in fact displayed by agetty and is the content of /etc/issue.
# man agetty
Edit /etc/issue and replace \o by \O if appropriate.
\o (lowercase letter O) is a placeholder for the nis domain name
\O (uppercase letter O) is a paceholder for the dns domain name, the one you want.
The current default is 'This is \n.\O (\s \m \r) \t'

* Resolver
# echo "127.0.0.1       basil.a.la.maison basil localhost" > /etc/hosts
will do the trick

basil ~ # hostname -fv
gethostname()=`basil'
Resolving `basil' ...
Result: h_name=`basil.a.la.maison'
Result: h_aliases=`basil'
Result: h_aliases=`localhost'
Result: h_addr_list=`127.0.0.1'
basil.a.la.maison

basil ~ # hostname -d
a.la.maison

Both aliases will resolve to 127.0.0.1:
basil ~ # ping -c1 basil
PING basil.a.la.maison (127.0.0.1) 56(84) bytes of data.
64 bytes from basil.a.la.maison (127.0.0.1): icmp_seq=1 ttl=64 time=0.093 ms

basil ~ # ping -c1 localhost
PING basil.a.la.maison (127.0.0.1) 56(84) bytes of data.
64 bytes from basil.a.la.maison (127.0.0.1): icmp_seq=1 ttl=64 time=0.091 ms


Please let us know if this does not solve your problem.

Hth
Comment 4 Leon 2004-11-27 07:48:50 UTC
Thank you very much for that very detailed and thorough answer.

I have two 'differences'

1. "my" /etc/resolv.conf has only one entry and it is 'nameserver 192.168.0.1' which is set from the DHCP server at 192.168.0.1, I assume. That is, there is no domain information in my /etc/resolv.conf file. The dhcp server doesn't provide a domain name as far as I can tell.

2. "my" hostname -fv & hostname -d commands operate as you explain now, however prior to me having "127.0.0.1 hostname.domainname localhost hostname" and NOT "127.0.0.1 hostname.domainname hostname localhost" set in my /etc/hosts, hostname -d couldn't resolve the domainname. 'Strangely', now that it is working, the order doesn't matter anymore!

The way that you outline the 'process' is exactly how I expected it to work, but it didn't until I changed my /etc/hosts to have the 127.0.0.1 alias list set with localhost as the first in the list, not second as per the handbook? 

I'm thinking the 'resolver' as you outline it might care about the order?

I suppose that something else could have triggered the 'permanent' change in operation as well, but I didn't do anything else apart from this change?

Am happy to 'play' with the system if you need any additional info, but not till tomorrow :-)

Lastly, just to clear. 'My' problem is resolved. As far as I know it was resolved by changing the order or the alias list in /etc/hosts, hence my comment/request to have the handbook modified. (I'm guessing from the number of confused unknown_domain posts on the forums that his is happening for others as well, but then I'm a n00b to linux so could just be talking out of my a...)

fractoon
Comment 5 Xavier Neys (RETIRED) gentoo-dev 2004-11-27 08:26:16 UTC
Swapping aliases in /etc/hosts may look like it solves your problem but all it does is make a symptom go away. The problem is still there: no domain in /etc/resolv.conf
Any reason you want to use your router as a nameserver/dhcp server?
Anyway, dhcpcd overwrites /etc/resolv.conf (look for a /etc/resolv.conf.sv) and if your router is not set up to provide a domain name, you won't get any.
To prevent dhcpcd from overwriting your /etc/resolv.conf, use -R option in /etc/conf.d/net: dhcpcd_eth0="-R"
Looking at /etc/conf.d/net.example, it looks like you can use peer_dns="no"
Comment 6 Leon 2004-11-28 03:29:37 UTC
Thank you for that info Xavier.

I understand about 'treating the symptom, not the cause', but the state the laptop (hence the desire for dhcp) is in now doesn't allow for me to experiment as I can not undo the domain resolution after having made that specific change.

I'm also assumming that using wlan0 instead of eth0 in my situtation should be fine for configuring the name resolution as suggested?

The router is acting as a dhcp server as it is an all-in-one singular device. I can disable this functionality of course, but I' rather fixed the linux box than mess with the router.

Anyway ... if anyone has any suggestions as how to 'break' it again so I can try all the other things suggested I'm willing to do so to really get to the bottom of this.

The last thing I'll comment on is the fact that prior to swapping the order of the alias list that hostname -vd did not work, coming back with an unknown error? I can't reproduce this though, but you can have look at the forum thread to check the detailed 'error' messages.

fractoon
Comment 7 Paul Worrall 2004-12-12 13:49:38 UTC
I too think localhost should be listed first after 127.0.0.1 in /etc/hosts, but for a different reason:

I have found that to access the 'SWAT' configuration tool for samba (which is run from xinetd) by typing 'http://localhost:901' in my web browser I have to have localhost is listed first.

Now... man xinetd.conf says that with 'only_from' set to 'localhost' (which is the default), xinetd will do a reverse lookup to determine if the canonical name of the IP address trying to access SWAT is 'localhost', i.e. you want 'hostname -fv' to return "Result: h_name='localhost'" and the way to achieve this is to have 'localhost' first.

BTW, I have my domainname in /etc/resolv.conf and dhcpcd_eth0="-R" in /etc/conf.d/net
Comment 8 Sven Vermeulen (RETIRED) gentoo-dev 2004-12-22 13:35:45 UTC
I've set localhost to be first after 127.0.0.1 again.