<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 12:25 PM, Jakub Hrozek <span dir="ltr"><<a href="mailto:jhrozek@redhat.com" target="_blank">jhrozek@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Tue, Dec 17, 2013 at 03:28:45PM +0200, Noam Meltzer wrote:<br>
> On 17 December 2013 11:55, Jakub Hrozek <<a href="mailto:jhrozek@redhat.com">jhrozek@redhat.com</a>> wrote:<br>
><br>
> > On Tue, Dec 17, 2013 at 07:40:29AM +0200, Noam Meltzer wrote:<br>
> > > Hello sssd-developers,<br>
> > ><br>
> > > Allow me to introduce myself and the suggested contribution to the SSSD<br>
> > > project. PrimaryData Inc. is a startup company in the field of<br>
> > distributed<br>
> > > NAS. As such, we would like to contribute to the SSSD project by<br>
> > developing<br>
> > > support for rpc.idmapd.<br>
> > ><br>
> > > Below is our proposed design for this new feature.<br>
> > ><br>
> > > Best regards,<br>
> > > Noam Meltzer<br>
> > ><br>
> > ><br>
> > ><br>
> > > ---<br>
> > ><br>
> ><br>
> > Hi Noam,<br>
> ><br>
> > thanks for this design, it's great to have outside contributions!<br>
> ><br>
> > > *SSS NFS Client (rpc.idmapd plugin) - Design*<br>
> > ><br>
> > > We named the client "sss_nfs" (althogh "sss_idmap" or "idmap" might have<br>
> > > been better names, the term "idmap" is already occupied in the SSSD<br>
> > world).<br>
> > ><br>
> ><br>
> > How does this client work, is it a module that the rpc.idmapd dlopens()<br>
> > ?<br>
> ><br>
><br>
> yes, dlopen() is used.<br>
> in more details: once "sss_nfs" is specified as a "Method" in<br>
> /etc/idmapd.conf the module /usr/lib64/libnfsidmap/sss_nfs.so will be<br>
> dlopen()ed<br>
> (the file paths are under the assumption of fedora19 x86_64)<br>
><br>
><br>
><br>
> > ><br>
> > > *rpc.idmapd - background*<br>
> > ><br>
> > > rpc.idmapd runs on NFSv4 servers as a userspace daemon (part of<br>
> > nfs-utils).<br>
> > > It's role is to assist knfsd by providing the following 6 mapping<br>
> > functions:<br>
> > ><br>
> > > 1. (user) name to uid<br>
> > ><br>
> > > 2. (group) name to gid<br>
> > ><br>
> > > 3. uid to (user) name<br>
> > ><br>
> > > 4. gid to (group) name<br>
> > ><br>
> > > 5. principal (user) name to ids (uid + gid)<br>
> > ><br>
> > > 6. principal (user) name to grouplist (groups which user are member of)<br>
> > ><br>
> > > rpc.idmapd provides API for developing plugins (loaded by dlopen(3))<br>
> > which<br>
> > > implements the actual mapping process.<br>
> > ><br>
> > > * note: 5 + 6 are relevant only for kerberised NFSv4 servers. At the<br>
> > first<br>
> > > stage we only purpose a design without kerberos support.<br>
> > ><br>
> > > * note2: On the kernel level, there's a caching mechanism for the<br>
> > responses<br>
> > > from the userspace daemon.<br>
> > ><br>
> > ><br>
> > > *SSSD - Responder*<br>
> > ><br>
> > > The functionality required from the Responder side is a subset of the<br>
> > > functionality provided by existing NSS Responder's commands.<br>
> > ><br>
> > > As you can see below (on the client part of the design) - no changes are<br>
> > > needed in the NSS Responder.<br>
> > ><br>
> > ><br>
> > > *SSSD - NFS Client*<br>
> > ><br>
> > ><br>
> > > *Responder-Facing Interactions (existing NSS Responder commands)*<br>
> > ><br>
> > > SSS_NSS_GETPWNAM - map (user) name to uid requests<br>
> > > SSS_NSS_GETGRNAM - map (group) name to gid requests<br>
> > > SSS_NSS_GETPWUID - map uid to (user) name requests<br>
> > > SSS_NSS_GETGRGID - map gid to (group) name requests<br>
> > ><br>
> > > The request & reply sent to & from the responder is "standard" in terms<br>
> > of<br>
> > > the NSS Responder.<br>
> > ><br>
> > > The client only needs a portion of the reply. Only this portion will be<br>
> > > extracted from the packet (i.e. uid/gid/user name/group name).<br>
> ><br>
> > Sure, this would work and as long as you see no performance issues, this<br>
> > approach is completely fine.<br>
> ><br>
> > But please note that especially getgr* calls can be quite expensive,<br>
> > especially when nesting is involved. The reason is that normally the<br>
> > getgr* calls also download all the group members, resolving the nesting<br>
> > in the process.<br>
> ><br>
><br>
> This sounds problematic.<br>
><br>
><br>
> > But if you do want to optimize further (perhaps in the future), we could<br>
> > then add a new NSS call that would only download the group entry in<br>
> > order to retrieve the GID. I think the backend part of this change would<br>
> > be also usable for the PAC responder and we already talked about this<br>
> > change recently with Sumit.<br>
> ><br>
> > But for version 1.0 I agree we can just use the existing NSS calls. A<br>
> > future version of the client can switch to another NSS call later, we<br>
> > can do that safely.<br>
> ><br>
><br>
> Ok. lets start that way. Though I believe that we'll provide the extra NSS<br>
> call soon enough...<br>
><br>
><br>
> ><br>
> > ><br>
> > ><br>
> > > *Optimisation Techniques*<br>
> > ><br>
> > > The optimisation techniques used for the NSS client will be used here as<br>
> > > well. i.e. Fast Cache (memcache) & negative-cache.<br>
> > ><br>
> > > It will be possible for the user to disable Fast Cache from the<br>
> > > configuration file. (see below)<br>
> ><br>
> > What problems do you envision with the Fast Cache? Or did yo mostly want<br>
> > to make sure kernel does its own caching and the SSSD stays out of the<br>
> > way?<br>
> ><br>
><br>
> As you guessed, we mostly want to make sure that the kernel does its own<br>
> caching and SSSD stays out the way. :-)<br>
> But that depends on the specific usage pattern. For others Fast Cache might<br>
> be useful.<br>
><br>
><br>
> ><br>
> > ><br>
> > ><br>
> > ><br>
> > > *Configuration File*<br>
> > ><br>
> > > The configuration of the client will be part of rpc.idmap config file<br>
> > > (/etc/idmapd.conf).<br>
> ><br>
> > I think the plan sounds great in general!<br>
> ><br>
><br>
> Thanks!<br>
<br>
</div></div>Hi Noam,<br>
<br>
since there were no other comments to the propsal, I think that means an<br>
ACK :-)<br></blockquote><div><br></div><div>Done.<br> <br></div><div><a href="https://fedorahosted.org/sssd/wiki/DesignDocs/rpc.idmapd%20plugin">https://fedorahosted.org/sssd/wiki/DesignDocs/rpc.idmapd%20plugin</a> <br></div>
</div><br><br clear="all"><br>-- <br><div dir="ltr"><table cellpadding="0" cellspacing="0"><tbody><tr><td>Noam Meltzer<br>Linux Software Engineer<br>PRIMARY DATA<br><br>P.O. Box 12650, Herzliya Pituach 4673300<br>9 Hamenofim St. Akerstein Towers, Tower A, 5th fl. Herzliya<br>
<br>Office: +972-77-8981888 | Fax: +972-3-7617140 | Mobile: +972-54-5873843<br><br>Email: <a href="mailto:noam@primarydata.com" target="_blank">noam@primarydata.com</a><br></td><td><span><label></label></span><br></td></tr>
</tbody></table></div>
</div></div>