On Tue, Dec 17, 2013 at 07:40:29AM +0200, Noam Meltzer wrote:
Hello sssd-developers,
Allow me to introduce myself and the suggested contribution to the SSSD
project. PrimaryData Inc. is a startup company in the field of distributed
NAS. As such, we would like to contribute to the SSSD project by developing
support for rpc.idmapd.
Below is our proposed design for this new feature.
Best regards,
Noam Meltzer
---
Hi Noam,
thanks for this design, it's great to have outside contributions!
*SSS NFS Client (rpc.idmapd plugin) - Design*
We named the client "sss_nfs" (althogh "sss_idmap" or
"idmap" might have
been better names, the term "idmap" is already occupied in the SSSD world).
How does this client work, is it a module that the rpc.idmapd dlopens()
?
*rpc.idmapd - background*
rpc.idmapd runs on NFSv4 servers as a userspace daemon (part of nfs-utils).
It's role is to assist knfsd by providing the following 6 mapping functions:
1. (user) name to uid
2. (group) name to gid
3. uid to (user) name
4. gid to (group) name
5. principal (user) name to ids (uid + gid)
6. principal (user) name to grouplist (groups which user are member of)
rpc.idmapd provides API for developing plugins (loaded by dlopen(3)) which
implements the actual mapping process.
* note: 5 + 6 are relevant only for kerberised NFSv4 servers. At the first
stage we only purpose a design without kerberos support.
* note2: On the kernel level, there's a caching mechanism for the responses
from the userspace daemon.
*SSSD - Responder*
The functionality required from the Responder side is a subset of the
functionality provided by existing NSS Responder's commands.
As you can see below (on the client part of the design) - no changes are
needed in the NSS Responder.
*SSSD - NFS Client*
*Responder-Facing Interactions (existing NSS Responder commands)*
SSS_NSS_GETPWNAM - map (user) name to uid requests
SSS_NSS_GETGRNAM - map (group) name to gid requests
SSS_NSS_GETPWUID - map uid to (user) name requests
SSS_NSS_GETGRGID - map gid to (group) name requests
The request & reply sent to & from the responder is "standard" in terms
of
the NSS Responder.
The client only needs a portion of the reply. Only this portion will be
extracted from the packet (i.e. uid/gid/user name/group name).
Sure, this would work and as long as you see no performance issues, this
approach is completely fine.
But please note that especially getgr* calls can be quite expensive,
especially when nesting is involved. The reason is that normally the
getgr* calls also download all the group members, resolving the nesting
in the process.
But if you do want to optimize further (perhaps in the future), we could
then add a new NSS call that would only download the group entry in
order to retrieve the GID. I think the backend part of this change would
be also usable for the PAC responder and we already talked about this
change recently with Sumit.
But for version 1.0 I agree we can just use the existing NSS calls. A
future version of the client can switch to another NSS call later, we
can do that safely.
*Optimisation Techniques*
The optimisation techniques used for the NSS client will be used here as
well. i.e. Fast Cache (memcache) & negative-cache.
It will be possible for the user to disable Fast Cache from the
configuration file. (see below)
What problems do you envision with the Fast Cache? Or did yo mostly want
to make sure kernel does its own caching and the SSSD stays out of the
way?
*Configuration File*
The configuration of the client will be part of rpc.idmap config file
(/etc/idmapd.conf).
I think the plan sounds great in general!