Fw: nfs-idmap.service removed
dennis at ausil.us
Fri Apr 27 14:52:53 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
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
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...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the test