On Fri, 2012-04-27 at 14:44 -0400, Steve Dickson wrote:
On 04/27/2012 12:07 PM, Adam Williamson wrote:
On Fri, 2012-04-27 at 17:07 +0100, Adam Williamson wrote:
On Thu, 2012-04-26 at 10:53 -0400, Steve Dickson wrote:
Steve, can you elaborate? Do pure clients never need idmap?
With F17 we moved to the keyring based ID mapping, which eliminates the need for the rpc.idmapd daemon to be started on the client side.
Here is how it works...
With NFS v4 traffic, the kernel will receives a uid string of "steved@redhat.com" that needs to be translated into a UID integer. So the kernel will do a keyring upcall to the nfsidmap binary. The upcall is enabled with the existence of the /etc/request-key.d/id_resolver.conf file.
The nfsidmap binary then converts the "steved@redhat.com" string into the 3606 uid. That mapping is cached in the keyring which makes available the next time its needed.
The nfsidmap(5) man page explains how entires on that keyring can be manipulated.
I hope this helps...
Thanks, but how about NFSv3 traffic? F17 clients will presumably still need to interact with NFSv3 servers.
Oh, never mind, of course I'm being dumb: idmap doesn't apply to NFSv3.
No problem.... I guess people are trying to use the f17 nfs-utils on with a f15 kernel... which means there will be problems.. maybe I should add something to the f17 nfs-utils to start rpc.idmap on kernels non 3.3 kernels?
No, I don't think we need to support that. 17's supported kernel is 3.3.