Description of problem: The postinstall scriptlet of nss-mdns adds on every upgrade an entry to /etc/nsswitch.conf which enables mdns. This is very bad because: * I do not want mDNS * it blocks (or slows at least) resolving of regular .local addresses (I know, there is an rfc draft which reserves .local, but our network was created in the 1990's) There is no way to prevent this script from operating and nss-mdns is a dependency of other packages (wine-core). So, please a) execute the scripts on first installation/final removal only but not on upgrade, or b) add another way to disable mDNS Btw, the .bak backup is useless because 'sed -i .bak' is executed twice (postinstall + preuninstall) and second run overrides the .bak. Version-Release number of selected component (if applicable): nss-mdns-0.10-12.fc19.i686 How reproducible: 100% Steps to Reproduce: 1. configure /etc/nsswitch.conf with | hosts: files dns 2. yum reinstall nss-mdns 3. /etc/nsswitch.conf contains | hosts: files mdns4_minimal [NOTFOUND=return] dns
At least removing [NOTFOUND=return] should prevent it from breaking DNS resolution of .local - for those of use with .local active directory domains for example.
Found this because on (at least) one of my systems, nss-mdns had managed to kill its configuration, possibly related to installing i686 version later (for wine) than x86_64 version. Looking the package changelog, the last non-rebuild change to the nss-mdns package is from 2008, and even that's by non-maintainer. Me thinks some provenpackage love is called for here...
(In reply to Orion Poplawski from comment #1) > At least removing [NOTFOUND=return] should prevent it from breaking DNS > resolution of .local - for those of use with .local active directory domains > for example. Please see http://avahi.org/wiki/AvahiAndUnicastDotLocal, http://www.lowlevelmanager.com/2011/09/fix-linux-dns-issues-with-local.html Removing [NOTFOUND=return] is a suboptimal solution because it will only proceed to DNS if it encounters a mDNS timeout (5s). This will slow down lookups of all .local addresses significantly. It does help to put "dns" before "mdns4_minimal" in nsswitch.conf, like this: hosts: files dns mdns4 myhostname On the web page above, this is mentioned as a possible workarouond but not recommended. Another option is to change the default domain name in /etc/avahi-daemon.conf: domain-name=.zeroconf which seems to be actually the recommended solution (I am not sure what side effects it may have on the zeroconf functionality). There is also a hint for distributors on that web page to disable avahi on networks with a .local domain. However this would not work in our corporate network because only 'fujitsu.local.' is resolved, not 'local.': [root@pdbcooper martin]# host -t SOA local. Host local. not found: 3(NXDOMAIN) [root@pdbcooper martin]# host -t SOA fujitsu.local. fujitsu.local has SOA record f01dedcabgb04.fujitsu.local. hostmaster.fujitsu.local. 55846 900 600 86400 3600
That said, the actual Fedora problem here seems to be a) the bad scripting in nss-mdns package, as described above b) the dependency of wine on nss-mdns. I've found bug 492700, but it gives me no clue why whine depends on mDNS.
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.
Reassigning to F20, where the problem is still present.
Here is what should be changed in Fedora to make nss-mdns work better in Microsoft dominated environmens where top-level admins have chosen to use .local as a unicast DNS domain: - ship /etc/mdns.allow as %config file in the distribution, with comments explanining its use, defaulting to .local - make the list of allowed MDNS suffixes configurable in /etc/sysconfig, defaulting to .local, and making sure that /etc/mdns.allow and the domain-name / browse-domains settings in /etc/avahi/avahi-daemon.conf match each other - instead of hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 just use hosts: files dns mdns The latter measure fixes another misbehavior of nss_mdns and avahi in our enviromemt which hasn't been mentioned here yet: nss-mdns tries to resolve reverse (PTR) lookups for IPv4 addresses and fails after timeout, causing annoying delays whenever hostnames are canonicalized e.g. by ssh. [root@pdbcooper martin]# grep ^hosts /etc/nsswitch.conf hosts: files mdns myhostname dns [root@pdbcooper martin]# time getent hosts 172.25.253.5 172.25.253.5 orion1.pdb.fsc.net real 0m5.002s <========= user 0m0.000s sys 0m0.002s [root@pdbcooper martin]# sed -i 's/mdns myhostname dns/dns myhostname mdns/' /etc/nsswitch.conf [root@pdbcooper martin]# grep ^hosts /etc/nsswitch.conf hosts: files dns myhostname mdns [root@pdbcooper martin]# time getent hosts 172.25.253.5 172.25.253.5 orion1.pdb.fsc.net real 0m0.001s <======== user 0m0.001s sys 0m0.000s
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.