Bug 508481

Summary: mdns4_minimal [NOTFOUND=return] nsswitch.conf fragment breaks nostname resolution
Product: [Fedora] Fedora Reporter: Yanko Kaneti <yaneti>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: bsund.fed, ffesti, jnovy, lpoetter, mcepl, moneta.mace, neo, pmatilai, pnemade, redhat, redhat
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-01 19:18:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch for spec accompanying in nss-mdns-0.10-7.fc11.src.rpm none

Description Yanko Kaneti 2009-06-27 18:22:46 UTC
Description of problem:
nss-mdns.i[35]86 installed on a x86_64 system without installed nss-mdns.x86_64 breaks x86_64 glibc's name resolution.

Specifically the lookup process modification of [NOTFOUND=return]
Without it even if glibc fails to find mdns4_minimal it still continues on the lookup in dns.

Comment 1 Björn Sund 2009-06-28 15:14:05 UTC
Got bit by this one when installing wine from updates-testing in F11 on a x86_64 system.

Comment 2 Lennart Poettering 2009-06-29 18:43:50 UTC
One of the many reasons why multilib is broken. 

I don't see how this could be fixed.

Comment 3 Yanko Kaneti 2009-06-29 18:55:08 UTC
Just remove the [NOTFOUND=return] part? Why is it needed?

Comment 4 Björn Sund 2009-06-29 20:02:17 UTC
Yes something needs to be done since it break loads of dns lookups on the system just by doing a simple thing like installing wine on a multilib system. 

I got round it by pinging hosts for resolve and then copy/paste my way to bugzilla. :)

Maybe more of a Fedora bug than a mdns one, but it is nasty.

Comment 5 Björn Sund 2009-06-29 21:11:29 UTC
Hmm, I tried to reproduce with no success.

Works fine now, so I blame those solar storms

[bsund@woot ~]$ rpm -qa|grep mdns
nss-mdns-0.10-7.fc11.i586
[bsund@woot ~]$ grep mdns /etc/nsswitch.conf
hosts:      files mdns4_minimal [NOTFOUND=return] dns

Comment 6 Björn Sund 2009-06-29 22:51:21 UTC
Created attachment 349888 [details]
patch for spec accompanying in nss-mdns-0.10-7.fc11.src.rpm

Nope it's still here, it differs from applications.

Attaching a simple patch stripping the return from the .spec, I don't know my regex but it seems to do it's job ;)

No idea if it hurts mdns in any way though.

Comment 7 Parag Nemade 2009-06-30 11:30:05 UTC
Aah. So this is that package which made my rawhide machine broken since 3 days.
Please fix this as soon as possible its just one line change. I applied change given in comment#5 and  I got networking working again.

Comment 8 Parag Nemade 2009-06-30 11:31:30 UTC
I don't understand about this package. I see that
Build Date: Thu 26 Feb 2009 03:14:03 PM IST
but it got installed on my machine on 26 June 2009.

Comment 9 Lennart Poettering 2009-07-01 16:37:42 UTC
(In reply to comment #3)
> Just remove the [NOTFOUND=return] part? Why is it needed?  

Because nss-mdns needs to be authoritative for for the .local domain.

That posted patch is not useful, since it breaks this.

This problem is not fixable with RPM as it stands right now. What would be necessary is that the 64bit version of nss-mdns pulls in the 32bit version if other 32bit binaries are installed, and vice versa. But you cannot express that with RPM dependencies.

So I fear this will stay unfixed and you have to manually make sure you have installed both versions of nss-mdns,

I will now reassign this to rpm, because this needs to be fixed in RPM.

Comment 10 Panu Matilainen 2009-07-01 19:18:37 UTC

*** This bug has been marked as a duplicate of bug 442047 ***

Comment 11 Matěj Cepl 2009-07-03 20:48:04 UTC
*** Bug 509530 has been marked as a duplicate of this bug. ***

Comment 12 Lennart Poettering 2009-07-22 23:08:15 UTC
*** Bug 504951 has been marked as a duplicate of this bug. ***