Description of problem: Currently, /etc/nsswitch.conf has hosts configured this way: hosts: files mdns4_minimal [NOTFOUND=return] dns I would expect that if there is no mdns4_minimal module available that it would attempt files, then error out on the mdns4_minimal module (which would override [NOTFOUND=return], then attempt dns. This works if there is no mdns4_minimal module at all (neither x86_64, nor ix86), but fails if e.g. the ix86 mdns4_minimal module is installed, but the application run is x86_64. This happened to me because I tried out Spot's chromium test package (which is 32bit only due to limitations in the v8 JavaScript engine it needs), which pulled in nss-mdns.i586. Version-Release number of selected component (if applicable): glibc-2.10.1-2.i686 glibc-2.10.1-2.x86_64 nss-mdns-0.10-7.fc11.i586 How reproducible: Reproducible Steps to Reproduce: 1. Install nss-mdns.i586, but not nss-mdns.x86_64 2. try to telnet/ssh somewhere which is only resolvable via DNS Actual results: nils@gibraltar:~> host www.redhat.com www.redhat.com is an alias for origin-www.redhat.com. origin-www.redhat.com has address 209.132.177.50 nils@gibraltar:~> telnet www.redhat.com 80 telnet: www.redhat.com: Name or service not known nils@gibraltar:~> Expected results: nils@gibraltar:~> host www.redhat.com www.redhat.com is an alias for origin-www.redhat.com. origin-www.redhat.com has address 209.132.177.50 nils@gibraltar:~> telnet www.redhat.com 80 Trying 209.132.177.50... Connected to www.redhat.com. Escape character is '^]'. Additional info: The above results are both with nss-mdns.i586, the first without, the second with nss-mdns.x86_64 installed.
It is equally broken in non-multilib environments, if you add a NSS module name to nsswitch.conf when that module doesn't exist, you get the same issue. The problem is just that nss-mdns inserts something into nsswitch.conf when just one of the modules is installed.
Hmm, the commentary in /etc/nsswitch.conf seems to suggest to me that such an entry should be skipped: # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. That's if you count "listed NSS module is missing" as a failure (which I would ;-), though this is a bit of a gray area... Glibc neatly side-steps the problem as it is (and its NSS modules are) pretty much guaranteed to be installed for the architecture of your binaries. External modules though can't rely on that. I still think that glibc should interpret [NOTFOUND=return] as I described above because if e.g. external NSS module packages would require all other arch counterparts to have this work (e.g. nss-mdns.i?86 would require nss-mdns.x86_64 and vice versa), this would always pull in all glibc arch packages. Granted, nss-mdns shouldn't really mess around in nsswitch.conf on package installation, but even if people would change it manually (after all why would they install the package otherwise), it either needs to work with such a configuration or ensure that all architectures are installed (which is hard to do properly on a packaging level).
We could also work around this by having one nsswitch.conf for 32bit, one for 64bit, but I guess we don't want to go there ;-).
*** Bug 512675 has been marked as a duplicate of this bug. ***
glibc-2.10.1-5 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/glibc-2.10.1-5
glibc-2.10.1-5 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update glibc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8784
*** Bug 521117 has been marked as a duplicate of this bug. ***
glibc-2.10.1-5 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.