Bug 1284323 - glibc: add nss_myhostname to /etc/nsswitch.conf
glibc: add nss_myhostname to /etc/nsswitch.conf
Status: NEW
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: glibc team
Fedora Extras Quality Assurance
: FutureFeature
: 1404476 (view as bug list)
Depends On: 1284325
Blocks: 1318303
  Show dependency treegraph
 
Reported: 2015-11-22 22:43 EST by Zbigniew Jędrzejewski-Szmek
Modified: 2017-07-25 18:51 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
enable myhostname (703 bytes, patch)
2015-11-22 22:44 EST, Zbigniew Jędrzejewski-Szmek
no flags Details | Diff

  None (edit)
Description Zbigniew Jędrzejewski-Szmek 2015-11-22 22:43:16 EST
Currently systemd.rpm has a %post scriptlet that adds 'myhostname' at the end of hosts line. This is error prone, and can mangle local changes to that file. Please consider adding 'myhostname' to the default /etc/nsswitch.conf file provided installed by glibc.rpm.

The myhostname nss module provides resolution of 'localhost' and locally configured IP addresses and the default gateway (see http://www.freedesktop.org/software/systemd/man/nss-myhostname.html). It is installed after dns, to provide fallback entries as a fallback. It has been enabled by default in all systems having systemd, i.e. probably almost all, without reported problems, so should be fairly safe.

If an nss module cannot be loaded, it is silently skipped. So it is OK to add it without introducing a dependency on the systemd package.
Comment 1 Zbigniew Jędrzejewski-Szmek 2015-11-22 22:44 EST
Created attachment 1097572 [details]
enable myhostname
Comment 2 Orion Poplawski 2015-12-01 16:37:06 EST
With this change gone now, builds that run mpich fail because the koji builder cannot resolve its own name.
Comment 3 Zbigniew Jędrzejewski-Szmek 2015-12-01 17:08:38 EST
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.
Comment 4 Carlos O'Donell 2015-12-02 22:28:41 EST
(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.
Comment 5 Orion Poplawski 2015-12-04 16:21:22 EST
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.
Comment 6 Orion Poplawski 2016-01-21 15:25:45 EST
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.
Comment 7 Florian Weimer 2016-01-21 15:59:03 EST
(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?
Comment 8 Orion Poplawski 2016-01-21 16:12:31 EST
+ 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.
Comment 9 Carlos O'Donell 2016-01-21 16:52:29 EST
(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.
Comment 11 Jan Kurik 2016-02-24 09:00:53 EST
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
Comment 12 Stephen Gallagher 2016-03-21 14:39:47 EDT
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.
Comment 13 Zbigniew Jędrzejewski-Szmek 2016-03-22 19:28:47 EDT
> 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.
Comment 14 Stephen Gallagher 2016-03-22 22:32:28 EDT
(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.
Comment 15 Zbigniew Jędrzejewski-Szmek 2016-03-23 10:28:36 EDT
(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.
Comment 16 Robert 2016-12-14 12:30:03 EST
*** Bug 1404476 has been marked as a duplicate of this bug. ***
Comment 17 Fedora End Of Life 2017-07-25 15:32:49 EDT
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.

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