Fw: nfs-idmap.service removed

Dennis Gilmore dennis at ausil.us
Fri Apr 27 14:52:53 UTC 2012

Hash: SHA1

Begin forwarded message:

Date: Fri, 27 Apr 2012 10:51:34 -0400
From: Steve Dickson <SteveD at redhat.com>
To: Dennis Gilmore <dennis at ausil.us>
Subject: Fwd: Re: nfs-idmap.service removed

- -------- Original Message --------
Subject: Re: nfs-idmap.service removed
Date: Thu, 26 Apr 2012 10:53:16 -0400
From: Steve Dickson <SteveD at RedHat.com>
To: Adam Williamson <awilliam at redhat.com>
CC: For testing and quality assurance of Fedora releases
<test at lists.fedoraproject.org>

On 04/26/2012 07:31 AM, Adam Williamson wrote:
> On Thu, 2012-04-26 at 07:49 +0800, Ed Greshko wrote:
>> Is there anywhere documentation outlining the decision to remove a
>> separate nfs-idmap.service from F17?  It seems that
>> nfs-server.service must be enabled and started in order for
>> rpc.idmapd.  It doesn't seem logical that a system running a NFS
>> Client Only should be required to also run an NFS server.
> The changelog message reads:
> "Removed the nfs-idmap service. rpc.idmap is now part of the
> nfs-server service"
> 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 at 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 at 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...


Version: GnuPG v2.0.18 (GNU/Linux)


More information about the test mailing list