Red Hat Bugzilla – Full Text Bug Listing
|Summary:||For some configurations, idmapd needs to access DNS|
|Product:||[Fedora] Fedora||Reporter:||Göran Uddeborg <goeran>|
|Component:||nfs-utils||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||amessina, bfields, jlayton, steved|
|Fixed In Version:||nfs-utils-1.2.5-3.fc16||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-11-19 01:04:03 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Göran Uddeborg 2011-10-23 16:41:25 EDT
Description of problem: My rpc.idmapd came up using the domain "localdomain" rather than the hosts domain name. This is a start order issue, somewhat similar to bug 742746. Version-Release number of selected component (if applicable): nfs-utils-1.2.5-1.fc16.x86_64 How reproducible: Every time Steps to Reproduce: 1. Configure hosts to have their full name in DNS only 2. Reboot Actual results: rpc.idmapd fails to figure out the domain Expected results: rpc.idmapd should use the host's DNS domain name as its domain. Additional info: In my network, hosts have their short names in /etc/sysconfig/network, and rely on DNS to determine their fqdn. So rpc.idmapd needs to be able to access the DNS server to use its default method to decide the domain. Out of the box, it starts too early for that. I've added an "After" line to nfs-idmap.service to ensure things starts in the right order. On the host running the DNS server, I've said "after named", and on other hosts I've said "after network". This solves the problem for me. One could add these conditions to the file as distributed to the package. That would avoid the problem. At the same time, I guess this problem only appears in certain configurations, in other circumstances the idmapper would wait unnecessarily. I'm not sure how much of a problem that would be considered to be. One could also see the additional configurations I've done as the way to handle the problem. However, nfs-idmap.service is not marked as a %config file, so this fix will have to be redone after an upgrade of nfs-utils. Another solution would thus be to mark it as a configuration file, so changes like these become persistent. There are of course other ways, like explicitly specifying the domain in idmapd.conf. Probably using the fqdn in /etc/sysconfig/network, or copying the host's own DNS info into /etc/hosts would also work, though I haven't verified it. I would argue that those methods are workarounds around the problem rather than real fixes of the problem. I realize that might be debatable. That's the situation as I understand it.
Comment 1 Anthony Messina 2011-11-12 12:58:13 EST
I seem to be having a similar problem using a freshly installed Fedora 16 VM for testing, except that even when I specify the Domain in /etc/idmapd.conf and restart the nfs-idmap.service, nothing changes and I continue to get: Nov 12 11:48:40 f16 rpc.idmapd: libnfsidmap: Unable to determine the NFSv4 domain; Using 'localdomain' as the NFSv4 domain which means UIDs will be mapped to the 'Nobody-User' user defined in /etc/idmapd.conf Nov 12 11:48:40 f16 rpc.idmapd: libnfsidmap: using (default) domain: localdomain Nov 12 11:48:40 f16 rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN' Nov 12 11:48:40 f16 rpc.idmapd: libnfsidmap: loaded plugin /lib/libnfsidmap/nsswitch.so for method nsswitch Nov 12 11:48:40 f16 rpc.idmapd: Expiration time is 600 seconds. Nov 12 11:48:40 f16 rpc.idmapd: nfsdopenone: Opening /proc/net/rpc/nfs4.nametoid/channel failed: errno 2 (No such file or directory) In /etc/idmapd.conf, I have specified [General] Verbosity = 5 Domain = messinet.com [Mapping] Nobody-User = nfsnobody Nobody-Group = nfsnobody No matter what I try, i am not able to get ID mapping working. Perhaps worth noting is that I'm using the nfs-secure.service
Comment 2 Steve Dickson 2011-11-14 07:42:29 EST
(In reply to comment #1) > I seem to be having a similar problem using a freshly installed Fedora 16 VM > for testing, except that even when I specify the Domain in /etc/idmapd.conf and [...] > > No matter what I try, i am not able to get ID mapping working. Perhaps worth > noting is that I'm using the nfs-secure.service So added an After=network.target to the [Unit] section of /lib/systemd/system/nfs-idmap.service did not help?
Comment 3 Steve Dickson 2011-11-14 12:30:36 EST
*** Bug 751339 has been marked as a duplicate of this bug. ***
Comment 4 Anthony Messina 2011-11-14 14:04:17 EST
Unfortunately, it does not. It's as if it's completely ignoring the 'Domain = messinet.com' parameter. Though I know the file is getting read, as I can change the Nobody-User or Nobody-Group and see those changes take effect. The following are from the virtual machine, in case these are related. ~]# cat /etc/resolv.conf # Generated by NetworkManager domain messinet.com search messinet.com virt.messinet.com nameserver 192.168.1.3 nameserver 192.168.2.5 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Comment 5 Göran Uddeborg 2011-11-14 16:04:52 EST
Anthony, I don't think you hare hit by this bug, but by bug 746497. Try to comment out ALL settings from idmapd.conf except for Domain. (Add a number of "-v" to RPCIDMAPDARGS in /etc/sysconfig/nfs to make it verbose that way instead.) Retry and see if it behaves differently.
Comment 6 Fedora Update System 2011-11-14 18:13:36 EST
nfs-utils-1.2.5-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/nfs-utils-1.2.5-3.fc16
Comment 7 Fedora Update System 2011-11-15 19:26:12 EST
Package nfs-utils-1.2.5-3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.5-3.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15921 then log in and leave karma (feedback).
Comment 8 Göran Uddeborg 2011-11-17 17:12:35 EST
This change fixes it for clients, and I've given karma. There is nothing that makes nfs-idmap to wait for named to come up on the DNS server, so that case I still have to handle with a local configuration. But maybe that is the intention? The combination is obviously much less common. Since filing this bugzilla, I've learnt one can add a file to /etc/systemd/system which includes the one from /lib/systemd/system. So doing a local configuration to add "after named" isn't as tricky as I first thought. On the other hand, adding "after named" too to the standard nfs-idmap.service wouldn't hurt the common case. On a system which doesn't run named, the "after named" declaration will have no effect. Unless I've misunderstood things.
Comment 9 Steve Dickson 2011-11-18 09:55:58 EST
(In reply to comment #8) > This change fixes it for clients, and I've given karma. > > There is nothing that makes nfs-idmap to wait for named to come up on the DNS > server, so that case I still have to handle with a local configuration. But > maybe that is the intention? The combination is obviously much less common. > > Since filing this bugzilla, I've learnt one can add a file to > /etc/systemd/system which includes the one from /lib/systemd/system. So doing > a local configuration to add "after named" isn't as tricky as I first thought. > > On the other hand, adding "after named" too to the standard nfs-idmap.service > wouldn't hurt the common case. On a system which doesn't run named, the "after > named" declaration will have no effect. Unless I've misunderstood things. I agree with this... I throw it in on an upcoming commit...
Comment 10 Fedora Update System 2011-11-19 01:04:03 EST
nfs-utils-1.2.5-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.