[Freeipa-devel] [RFC] Migrating existing environments to Trust

[Jakub Hrozek]

On Tue, May 27, 2014 at 04:01:41PM +0200, Sumit Bose wrote:
> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote:
> > Hi,
> > 
> > I have started to write a design page for 'Migrating existing
> > environments to Trust'
> > http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust
> > It shall cover https://fedorahosted.org/freeipa/ticket/3318 and
> > https://fedorahosted.org/freeipa/ticket/3979 .
> > 
> 
> while working on a new version of the page with more details on design
> and implementation I came across the following problem. On the IPA
> server there should be a way for SSSD to deliver unmodified data (no
> view applied) or views other than the one for the IPA server to
> processes which delivers user and group data to other clients. This are
> mainly the extdom and the compat plugin of dirsrv.

btw in the previous discussion, you proposed to get rid of the extdom
plugin completely, is it still the plan?

> 
> The two currently use standard glibc calls like getpwnam_r() to get the
> needed data from SSSD. While they can read the view objects form the
> LDAP tree there is no way to read the original data for users from
> trusted domains because it is only in the cache of SSSD.
> 
> I'm looking for a way to allow SSSD to deliver the data without changing
> the protocol used by the NSS responder.
> 
> One way I can think of is to use a new socket like
> /var/lib/sss/pipes/nss_noview and create a small library for the extdom
> and compat plugin to use the new socket. With this the plugin have to
> apply the views on their own if needed.

Can we have a separate memory cache for the original view (or per-view)
in this case used by this new small library? Since the memory cache has
a fixed size and it would be used by a single process only, we wouldn't
risk growing the memory consumption too much..

The NSS responder would have to be aware of multiple memory caches,
which might be ugly, though..

> 
> Another way would be a new command for the NSS responder with two
> arguments, the view name (or empty for unmodified data) and a blob which
> contains the data for the corresponding request like e.g. getpwnam_r() or
> getgrgid_r(). Here the plugins have to use some new calls but all view
> processing can happen in sssd and the plugins can deliver the data
> directly.

So there would be a special call in the nss client library
(getpwnam_ipa()?) just for the server mode? Then I think the previous
suggestion souds better to me, I think we should keep the current client
library minimal and stable.

> 
> A drawback in both cases is that the memcache cannot be used.
> 
> If someone has suggestions for SSSD or other ways how to deliver user
> and group data to client with other views than the IPA server I'm all
> ears.
> 
> bye,
> Sumit
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel