Bug 726054 - Add hostname to /etc/hosts [NEEDINFO]
Summary: Add hostname to /etc/hosts
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: nss-myhostname
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-27 12:38 UTC by Piotr Suwara
Modified: 2015-02-18 13:36 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-18 13:36:06 UTC
kparal: needinfo? (lpoetter)


Attachments (Terms of Use)

Description Piotr Suwara 2011-07-27 12:38:11 UTC
Description of problem:
If a computer's hostname is set to "myname" during installation, it takes a few minutes for sendmail to load (during startup or later). Even if I turn sendmail off, it still starts and stops at the startup, which badly increases startup time. Sometimes it starts quickly.

Take a look at the /var/log/maillog:
Jul 27 13:37:25 domeq sendmail[3991]: My unqualified host name (domeq) unknown; sleeping for retry
Jul 27 13:38:25 domeq sendmail[3991]: unable to qualify my own domain name (domeq) -- using short name
Jul 27 13:38:25 domeq sendmail[4022]: starting daemon (8.14.5): SMTP+queueing@01:00:00
Jul 27 13:38:25 domeq sm-msp-queue[4030]: My unqualified host name (domeq) unknown; sleeping for retry
Jul 27 13:39:25 domeq sm-msp-queue[4030]: unable to qualify my own domain name (domeq) -- using short name
Jul 27 13:39:25 domeq sm-msp-queue[4038]: starting daemon (8.14.5): queueing@01:00:00

Sometimes sendmail happens to turn on quickly during startup, it's quite random.


Version-Release number of selected component (if applicable):
sendmail-8.14.5-1.fc15.x86_64


How reproducible:
During installation (or, possibly, change it later) choose the host name to me "myname".


Steps to Reproduce:
1. Set the hostname to "myname" during installation (or possibly later).
2. Boot the computer.
3. Take a cup of tea. If your computer starts quickly, try some more times.

Actual results:
The computer waits 2 minutes after "Starting LSB: start and stop sendmail".

Alternatively:
1. Set the hostname to "myname" during installation (or possibly later).
2. Stop and start sendmail.
3. Take a cup of tea.

Actual results:
The computer waits 2 minutes untill sendmail starts.

Expected results:
Sendmail loads in a few seconds or less.


Additional info:
Solved by adding "myname" after "127.0.0.1" in /etc/hosts . Shouldn't it be there right after the installation? Now the /var/log/maillog contains:
Jul 27 14:01:01 domeq sendmail[4413]: starting daemon (8.14.5): SMTP+queueing@01:00:00
Jul 27 14:01:02 domeq sm-msp-queue[4422]: starting daemon (8.14.5): queueing@01:00:00
and everything's fine.

Comment 1 Piotr Suwara 2011-07-27 12:50:24 UTC
And "myname" was in this case "domeq".

Comment 2 Jaroslav Škarvada 2011-08-02 07:58:14 UTC
This is known behaviour. Sendmail tries to lookup your hostname to IP. The correct solution is to add such record to your DNS. It is also possible to bypass the DNS by adding the record to /etc/hosts. I think your request is more about anaconda than sendmail. But I am afraid it could cause problems to users which use DNS, e.g. their DNS record for hostname would be masked by /etc/hosts record (which would be added by anaconda) and resolves to loopback.

Comment 3 Piotr Suwara 2011-08-02 09:04:32 UTC
Well, you're right, my request is rather about anaconda. In my opinion something should be done with it because if, let's say, an 'average' user changes the hostname (it's so easy, just input some text in anaconda), he'll be left with a problem.

I think there could be some information about it in anaconda and maybe some checkbox "Add the approtiate record to /etc/hosts". Still, I understand it's not the correct solution, so I don't want to argue anymore.

Comment 4 Jaroslav Škarvada 2011-08-02 09:21:57 UTC
It makes sense, such checkbox (or at least notice) could help to 'average' users. Reassigning as RFE to anaconda.

Comment 5 Kamil Páral 2011-11-15 16:28:50 UTC
I had a long discussion with anaconda team about this. The hostname should be probably present inside /etc/hosts, but we are not completely certain. Anaconda or some other tool (NetworkManager?) should write out that information. CCing Dan Williams as an expert.

It's not just about sendmail. I remember having problems also with some other tools that rely on resolving hostname.

Reproducer:
1. Change hostname during default DVD installation.
2. Look into /etc/hosts in the installed system.

Comment 6 Jaroslav Škarvada 2011-11-15 16:47:37 UTC
It could make trouble to users who have correct DNS records (they would be overriden by /etc/hosts). Thus such feature if implemented should be made optional (by e.g. checkbox).

Comment 7 Kamil Páral 2011-11-16 07:38:19 UTC
Either /etc/hosts should always contain the local hostname, or applications (like sendmail) should never try to resolve it. One of the approaches should be correct and the other one wrong. We can't have common users waiting minutes for some application timeouts just because they decided to name their computer 'kitty'.

Disclaimer: I know nothing about networking.

Comment 8 Kamil Páral 2011-11-16 08:37:32 UTC
I looked into Ubuntu. After installation with 'kitty' hostname their /etc/hosts looks like this:

127.0.0.1  localhost
127.0.1.1  kitty

Comment 9 Jaroslav Škarvada 2011-11-16 09:55:12 UTC
(In reply to comment #8)
> I looked into Ubuntu. After installation with 'kitty' hostname their /etc/hosts
> looks like this:
> 
> 127.0.0.1  localhost
> 127.0.1.1  kitty

Interesting that it is 127.0.1.1 and not 127.0.0.1.

Consider the situation when your DNS is correctly set to resolve the 'kitty' to some interface IP. It will be then overriden by your loopback address from hosts which would be probably not correct.

Comment 10 Kamil Páral 2011-11-16 13:25:23 UTC
I tried openSUSE 12.1. They don't allow to change the hostname during installation. After installation my hostname was probably generated (linux-7wbc) and it was not present in /etc/hosts.

(In reply to comment #9)
> Consider the situation when your DNS is correctly set to resolve the 'kitty' to
> some interface IP. It will be then overriden by your loopback address from
> hosts which would be probably not correct.

That's a question. If I want to reference my computer as 'kitty', than I probably don't want to have 'kitty' requests routed to some foreign computer, but to my own. Also, DNS setups would probably use some domain, won't they?

So why exactly does sendmail try to resolve the local hostname instead of resolving assigned IP address? If my hostname is already present in the nearby DNS, but routes to a different computer, won't that be a problem?

Comment 11 Jaroslav Škarvada 2011-11-16 16:56:45 UTC
(In reply to comment #10)
Sendmail tries to get its fully qualified domainname (FQDN) by using gethostname followed by gethostbyname. If it doesn't find FQDN, it retries several time (this is the observed delay). The
127.0.0.1  kitty localhost
doesn't solve the problem, you also need to add the localhost.localdomain, i.e.:
127.0.0.1  kitty localhost localhost.localdomain
This can be workaround for e.g. mobile users, but it shouldn't be used on the server.

I think in correctly setup environment the machine should be accessible under FQDN, e.g. kitty.example.com. Under example.com it can be also accessed by its local hostname, i.e. kitty. I think that kitty should be resolved consistently under example.com (i.e. the gethostbyname should return all IPs under which the kitty is accessible). If you did the above mentioned hack you will get only 127.0.0.1 on the kitty which could lead to inconsistency. E.g. if the DNS record kitty.example.com points to another machine you will not get there from your 'kitty' by using kitty.

Comment 12 Vratislav Podzimek 2011-11-24 11:43:54 UTC
So I think we can now agree that this is not anaconda bug, right?

Comment 13 Kamil Páral 2011-11-24 12:07:22 UTC
Hard to tell. I'm missing some official guidance what the correct behavior should be. Is it a good idea to ask FESCo? Or do we have some Network SIG or similar highly knowledgeable group in this area that we could ask for their opinion?

Comment 14 Radek Vykydal 2011-11-24 13:35:45 UTC
NetworkManager already went through this issue some time ago, it used to update /etc/hosts with hostname but finally stopped doing that:

https://bugzilla.redhat.com/show_bug.cgi?id=648725#c1
https://bugzilla.redhat.com/show_bug.cgi?id=648725#c10
https://bugzilla.redhat.com/show_bug.cgi?id=648725#c23

I'd prefer anaconda not imposing some policy beyond what NM does in this matter. I don't feel competent to decide what the policy should be, Dan Williams has broader grasp of the problem and I'd stick to his decision. He is giving some arguments and insights in comments to the NM bug above, although he also suggests installer handling the issue:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=39eed50e470d6f41222e40ce0276b898e8c84dc4

The problem has also its history in Anaconda bugzilla:

Write it!:       bug 506384
Oh no, don't!:   bug 530343 (bug 555748)

Seems to me like we can't make everyone happy and not adding the hostname is better option.

Comment 15 Jaroslav Škarvada 2011-11-24 14:59:09 UTC
What about the checkbox (to add the localhost) in Anaconda with description of the problem and by default off?

Comment 16 Radek Vykydal 2011-11-24 15:45:44 UTC
I just can't imagine any reasonably simple description of the problem/choice (may be just my ignorance of the matter), and I am not sure user should be exposed to such a choice. To me it seems like asking user to decide something that should be handled sanely by the system. Especially considering the simplicity of UI we are aiming for in anaconda UI rewrite.

Comment 17 Kamil Páral 2011-11-25 09:17:46 UTC
Radek, thank you for the links, great reading. It's a pity Dan Williams couldn't respond here, he's probably busy elsewhere. But I learned a great deal.

My opinion that a computer must always be able to resolve its local hostname to a local IP address seems to agree with Dan's opinion. It turns out that nss-myhostname package (installed by default, even on minimal install) should solve these problems even if there is no entry in /etc/hosts. That is *great*.

I experimented with it a bit. I did a default F16 Live and minimal install with 'mole' hostname. Even though it is not present in /etc/hosts, I am able to resolve it flawlessly. If I have eth0 up, I get this:

$ pythoc -c 'import socket; print socket.gethostname(); print socket.gethostbyname(socket.gethostname());'
mole
192.168.1.11

If I have eth0 down, I get this:

$ pythoc -c 'import socket; print socket.gethostname(); print socket.gethostbyname(socket.gethostname());'
mole
127.0.0.2

That seems to be working. However, the sendmail service still times out, I don't understand why. If I start it, no matter whether eth0 up or down, it is still being started for 1 minute with infamous messages in maillog [1]. So either there is some problem in sendmail, or there is a bug in nss-myhostname (I tested only Python calls, not C calls).

[1] Fortunately it doesn't slow down computer boot for me due to systemd parallelism. It just slows down the sendmail service.

Second what caught my attention is this one Dan Williams' comment:

> ... because it's really only a workaround for stupid programs that do
> gethostbyname(gethostname()) to find your IP address.  That's completely 
> broken and will certainly not work in various circumstances (especially 
> if/when your IP address changes);
> ... The reason the mappings for your public IP address were added was due
> to programs that used the gethostbyname(gethostname()) pattern, which is 
> quite busted.

Maybe sendmail developers could speak to Dan Williams and find out what's the recommended approach to achieve their goals (in this case probably retrieve network IP address)? Because the current approach seems to be very suboptimal, according to his words.

Finally, due to nss-myhostname package (thanks Lennart), it seems that Anaconda does no longer need to care about this issue. If the nss-myhostname works correct, there is no need for entry in /etc/hosts. Sendmail still timeouts however and we should find out why. Jaroslav, can you have a look at that issue (try out calling gethostbyname(gethostname()) manually and find why it doesn't work for sendmail)? Or maybe consult Dan Williams about a better approach? Thanks.

Comment 18 Jaroslav Škarvada 2011-11-25 09:48:41 UTC
(In reply to comment #17)
Sendmail uses gethostbyname(gethostname()) not to find your IP, but to find your FQDN. If there is better way, please let us know.

> $ pythoc -c 'import socket; print socket.gethostname(); print
> socket.gethostbyname(socket.gethostname());'
> mole
> 127.0.0.2
>
> That seems to be working. However, the sendmail service still times out, I
> don't understand why.

It's because there is no FQDN for 127.0.0.2
For workaround you need:
/etc/hosts
127.0.0.2 localhost localhost.localdomain

or to configure the nss-myhostname to use the 127.0.0.1. I am not sure why it currently defaults 127.0.0.2 for IPv4 and :1 for IPv6, it seems to be quite inconsistent.

Comment 19 Kamil Páral 2011-11-25 10:42:59 UTC
I'm CCing Lennart Poettering, the author of nss-myhostname. Lennart, could you please give us an advice regarding nss-myhostname and sendmail? 

Is there a reason why nss-myhostname doesn't return standard 127.0.0.1? Is it possible for sendmail to get FQDN using nss-myhostname? Should 127.0.0.2 be added to the default /etc/hosts by Anaconda? Thanks.

Comment 20 Jaroslav Škarvada 2011-11-25 11:01:47 UTC
AFAIK loopback is defined as 127.0.0.0/8, so 127.0.0.2 is one from the pool and I wouldn't add it to /etc/hosts. 

127.0.0.1 is widely used for localhost. Could nss-myhostname return 127.0.0.1?

Comment 21 Jaroslav Škarvada 2011-11-30 16:30:57 UTC
Well, I could lower the timeouts / number of retries or rewrite the code completely, but it would be hard to get such changes upstream - this is about misconfigured DNS which they probably wouldn't like to support. Also I don't want to divert from them.

Is there any reason why the nss-myhostname cannot return 127.0.0.1? It would solve this and maybe it could solve other similar problems. Reassigning to nss-myhostname for investigation.

Comment 22 Fedora End Of Life 2013-04-03 19:31:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 23 Fedora End Of Life 2015-01-09 21:51:25 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 24 Fedora End Of Life 2015-02-18 13:36:06 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.