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

[Simo Sorce]

On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote:
> On 05/28/2014 11:20 PM, Simo Sorce wrote:
> > On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote:
> >> On 05/27/2014 03:52 PM, Simo Sorce wrote:
> >>> On Tue, 2014-05-27 at 16:01 +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.
> >>>>
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>> 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.
> >>> Ok this one is hard to deal with in a way that will satisfy every
> >>> possible user.
> >>>
> >>> I think what we need to aim is simplicity and predictability at the
> >>> expense of flexibility.
> >>>
> >>> What I mean is that freeipa servers should be allowed to only stick to
> >>> one view, the default view for external users.
> >> I do not understand what you mean by "one" view?
> > The "one" view is the view exposed via the (default) compat tree.
> >
> >> Server should be able to have "all" views.
> >> "View" is an equivalent of the "zones".
> >>
> >> SSSD has to get raw data from the external domain and give it to IPA.
> >> IPA would have to merge the data coming from SSSD in server mode with
> >> some set of data associated with a subset of clients.
> >> I am not sure how it will be done (compat, cos or some other mechanism)
> >> but this is the requirement.
> > This would require multiple compat trees, one per view, it would be very
> > expensive.
> >
> >> So for clarity let me restate the use cases:
> >>
> >> a) I had my users in a NIS or LDAP with POSIX attributes there. I used
> >> to sync users from AD. I migrate from that to IPA but want to use trust
> >> for my users because AD is authoritative source and I do not want/can
> >> put POSIX into AD.
> >> b) I have several NIS domains that I need to consolidate. For whatever
> >> reasons I can't migrate to the unified POSIX namespace. I want an
> >> equivalent of the Centrify Zones when different clients get different
> >> uid/gid assignments for the same users.
> >> c) I used sync so my POSIX attributes are in IPA but now I want to
> >> switch to trust.
> >> d) I had a third party solution that had posix zoning and I want to
> >> replace it with the similar solution based on IPA.
> >>
> >> Views (plural) are a way to merge data and present it to a subset of
> >> clients. In this context it is not really clear what you mean by "one"
> >> view.
> > In order to see views you'll need a modern SSSD client that knows how to
> > apply them. Ie viewS are applied on the client side. The server shows
> > only one view via LDAP.
> >
> > Simo.
> >
> OK, I agree with multiple views being expensive and merging things on 
> the client but how you define which one is the "default" on the server?

We'll have one called "default" ?

Simo.


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