Bug 726054

And "myname" was in this case "domeq".

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.

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.

It makes sense, such checkbox (or at least notice) could help to 'average' users. Reassigning as RFE to anaconda.

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.

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

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.

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

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

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?

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

So I think we can now agree that this is not anaconda bug, right?

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?

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.

What about the checkbox (to add the localhost) in Anaconda with description of the problem and by default off?

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.

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.

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

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.

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?

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.

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

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.

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.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days