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

[Simo Sorce]

On Tue, 2014-05-27 at 20:57 +0200, Jakub Hrozek wrote:
> 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?

Is this possible at all ?
We'd break existing clients that rely on it.

> > 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..

no see my other reply, at most we can get a cache in extdom if we really
care, but we shouldn't have special behavior in sssd for this feature.

One server has one canonical view, and IPA server should be bound to the
default view and not be able to be configured to use any other 'view'.

In other words, 'views' are really only for ipa clients, not for the
servers themselves.

> > 
> > 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.

I am against it indeed.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York