Created attachment 1097572 [details]
enable myhostname

With this change gone now, builds that run mpich fail because the koji builder cannot resolve its own name.

Could we have this change implemented quickly then (independently of mymachines)? I'd prefer to have this done properly in glibc than to restore the hack in systemd %post.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> Could we have this change implemented quickly then (independently of
> mymachines)? I'd prefer to have this done properly in glibc than to restore
> the hack in systemd %post.

For now I'm going to wait until we resolve mymachines and then move forward with both if that's appropriate.

In the meantime this is just an enhancement since the present system appears to work with the exception of more complex sites which just require administrative intervention.

Well, not entirely.  Since the removal of the configuration from systemd, builds that need to run mpich are failing in koji since the machine cannot resolve its own name.  Not sure if anything else is affected.  But some things are definitely broken right now.

Can we get myhostname back please?  It's now blocking updating to netcdf 4.4.0 in rawhide, which is needed for the hdf5 rebuild.  We're going to have a lot of broken deps in rawhide.

(In reply to Orion Poplawski from comment #6)
> Can we get myhostname back please?  It's now blocking updating to netcdf
> 4.4.0 in rawhide, which is needed for the hdf5 rebuild.  We're going to have
> a lot of broken deps in rawhide.

I'm confused why this is even an issue.  Is /etc/hosts in the build chroots not set up correctly?  Why does the presence of nss_myhostname make a difference?

+ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain
::1       localhost localhost.localdomain localhost6 localhost6.localdomain6

So the machine name is not there.  I'm not sure if this has changed in mock or not.

(In reply to Orion Poplawski from comment #8)
> + cat /etc/hosts
> 127.0.0.1 localhost localhost.localdomain
> ::1       localhost localhost.localdomain localhost6 localhost6.localdomain6
> 
> So the machine name is not there.  I'm not sure if this has changed in mock
> or not.

Even if we adjust mock, the question remains: Do we accept nss_myhostname as a convenience to our users.

I think this question needs to be discussed on Fedora Devel and minimally be turned into a Change Request to make this the default for all Fedora systems.

Discussion hopefully started here: https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/VM6GIT2GDK6AQEM2UYQ5XYNVWPZKWB45/

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Zbigniew, I had a long conversation today with Carlos O'Donnell about how to handle nss_myhostname.

Carlos's main concern[1] was that a temporary DNS failure could result in a cache (like nscd) getting the wrong result code and thus returning NOTFOUND for the cache timeout rather than handling TRYAGAIN or UNAVAIL properly.

I suggested that instead of just having
hosts: files dns myhostname
we should have systemd add a conjunction so that it doesn't attempt to handle a response during an error case:

hosts: files dns [TRYAGAIN=return UNAVAIL=return] myhostname

This would address the major concern while still allowing us to have myhostname present to deal with NOTFOUND cases from DNS. It's not a *perfect* solution, since it does mean that a temporary DNS failure could result in myhostname not being queried for a case where it might have had a correct answer, but this is an edge-case[2] and would still resolve the two primary issues here: it restores the guarantee that a machine understands its own name and it doesn't poison the cache with a false negative value.

Also, after the discussion with Carlos, I agree that this change doesn't belong in the default nsswitch.conf configuration and really should be re-added to the systemd package. Zbigniew, could you make the above changes in the systemd packaging and then I think we'll be in a much better place.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1238628
[2] Carlos and I have also discussed that glibc may need to grow the ability for an nss plugin to respond "I'm not authoritative, continue with whatever the previous module responded" so that we can avoid this edge-case. nss_myhostname would be able to return that response for anything that it wasn't equipped to answer.

> hosts: files dns [TRYAGAIN=return UNAVAIL=return] myhostname

I don't think this is a change for the better. For most people it's dns that's unreliable, and that change would just make breakage more painful. Personally I put myhostname *before* dns, because I try the hostname I configured more than any dns server I could be connected to at the moment. Doing things this way would avoid the problem you describe, and probably make things more robust in general.

> Carlos and I have also discussed that glibc may need to grow the ability for an nss plugin to respond "I'm not authoritative, continue with whatever the previous module responded" so that we can avoid this edge-case. nss_myhostname would be able to return that response for anything that it wasn't equipped to answer.

That sounds like a good idea too.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #13)
> > hosts: files dns [TRYAGAIN=return UNAVAIL=return] myhostname
> 
> I don't think this is a change for the better. For most people it's dns
> that's unreliable, and that change would just make breakage more painful.
> Personally I put myhostname *before* dns, because I try the hostname I
> configured more than any dns server I could be connected to at the moment.
> Doing things this way would avoid the problem you describe, and probably
> make things more robust in general.
> 

This is a change that is better than the (at the time) current state of not having myhostname at all in play. After our discussion, Carlos and I felt that this was a better solution than listing it without conditional returns because the effect of having myhostname "hiding" a temporary failure from nss_dns is significant. (Many real-world deployments have a very long nscd cache timeout for hosts and this would result in nscd caching "no such hostname" for temporary failures rather than retrying to deal with the temporary failure.)

Carlos and I generally agreed that the slight risk of having myhostname fail if the DNS setup is broken is probably a less-frequent issue than the caching problem.

As for sorting it before dns, I don't think that makes sense as a *default*, simply because there are many cases where I think it might be beneficial for a machine to respect the DNS view of itself rather than an auto-configured view (such as cases when only a subset of available interfaces should be associated with the hostname).


> > Carlos and I have also discussed that glibc may need to grow the ability for an nss plugin to respond "I'm not authoritative, continue with whatever the previous module responded" so that we can avoid this edge-case. nss_myhostname would be able to return that response for anything that it wasn't equipped to answer.
> 
> That sounds like a good idea too.

This is definitely the better long-term solution, but it's significant work and probably an ABI break for the NSS plugins, so at best we'd be looking at F25 for this and no chance of backporting it to any stable Fedora or downstream distro.

(In reply to Stephen Gallagher from comment #14)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #13)
> > > hosts: files dns [TRYAGAIN=return UNAVAIL=return] myhostname
> > 
> > I don't think this is a change for the better. For most people it's dns
> > that's unreliable, and that change would just make breakage more painful.
> > Personally I put myhostname *before* dns, because I try the hostname I
> > configured more than any dns server I could be connected to at the moment.
> > Doing things this way would avoid the problem you describe, and probably
> > make things more robust in general.
> > 
> 
> This is a change that is better than the (at the time) current state of not
> having myhostname at all in play. After our discussion, Carlos and I felt
> that this was a better solution than listing it without conditional returns
> because the effect of having myhostname "hiding" a temporary failure from
> nss_dns is significant. (Many real-world deployments have a very long nscd
> cache timeout for hosts and this would result in nscd caching "no such
> hostname" for temporary failures rather than retrying to deal with the
> temporary failure.)
> 
> Carlos and I generally agreed that the slight risk of having myhostname fail
> if the DNS setup is broken is probably a less-frequent issue than the
> caching problem.
I think that's the source of differing views. It seems that either only one
of two cases cases can be supported optimally:
- the case of "normal user", i.e. unreliable and semi-trusted DNS, where
  localhost and $hostname should be resolved even if DNS does not respond.
  For this case myhostname should be before dns.
- the case of "corporate user", where DNS-provided answers always have priority,
  and myhostname is just a fallback. In that case the config you suggested
  of course works best.

After writing this out in full, I see that current version, "hosts: files dns myhostname"
does not serve either case very well. nss-myhostname is an
improved/config-less/automatic nss-files replacement. Because of this, it
should be configured at higher priority then dns, just like files.
For example, current configuration allows dns to resolve "localhost" to
arbitrary values (and I know servers which do that). If I have "localhost"
configured in nss-files, this is avoided. With nss-myhostname at high priority,
the issue is avoided too. But with current config, with nss-myhostname only
as fallback, I'm vulnerable.

There's a good reason not to put nss-myhostname early, and it it is resolution
of "gateway". I guess that's yet another reason to get rid of it.

> As for sorting it before dns, I don't think that makes sense as a *default*,
> simply because there are many cases where I think it might be beneficial for
> a machine to respect the DNS view of itself rather than an auto-configured
> view (such as cases when only a subset of available interfaces should be
> associated with the hostname).
Sure, that happens. But not very often. If you have such specialized needs
then you should be able to adjust the configuration to your needs. The default
config should prioritize standard setups and general robustness over edge
cases.

> > > Carlos and I have also discussed that glibc may need to grow the ability for an nss plugin to respond "I'm not authoritative, continue with whatever the previous module responded" so that we can avoid this edge-case. nss_myhostname would be able to return that response for anything that it wasn't equipped to answer.
> > 
> > That sounds like a good idea too.
> 
> This is definitely the better long-term solution, but it's significant work
> and probably an ABI break for the NSS plugins, so at best we'd be looking at
> F25 for this and no chance of backporting it to any stable Fedora or
> downstream distro.

Ack.

*** Bug 1404476 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

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

This can be dealt with in the setup package once it has taken ownership of /etc/nsswitch.conf.