Red Hat Bugzilla – Bug 748275
For some configurations, idmapd needs to access DNS
Last modified: 2011-11-19 01:04:03 EST
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):
Steps to Reproduce:
1. Configure hosts to have their full name in DNS only
rpc.idmapd fails to figure out the domain
rpc.idmapd should use the host's DNS domain name as its domain.
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.
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
Verbosity = 5
Domain = messinet.com
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
(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?
*** Bug 751339 has been marked as a duplicate of this bug. ***
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
search messinet.com virt.messinet.com
~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
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.
nfs-utils-1.2.5-3.fc16 has been submitted as an update for Fedora 16.
* 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:
then log in and leave karma (feedback).
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.
(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...
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.