On Fri, 2014-05-30 at 00:09 -0400, Dmitri Pal wrote: > On 05/29/2014 02:13 PM, Simo Sorce wrote: > > On Thu, 2014-05-29 at 12:35 -0400, Dmitri Pal wrote: > >> On 05/29/2014 11:41 AM, Simo Sorce wrote: > >>> 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. > >>> > >>> > >> I do not care about the name i care about the content. Imagine that > >> there can be several different views. Which one is the default one? How > >> it is picked? Id there a way to change from one view to another? Also > >> this means that all legacy clients would have just one view because > >> there will be a single compat all of them can be pointed to. May be if > >> we can switch views on different replicas we would be able to create > >> zones such that different replicas are used to serve different groups of > >> legacy clients. > > No we can't switch the default view for external users via LDAP on > > different replicas, as that would cause clients to have conflicting > > data. > > > > If we need different views via LDAP we will have to explicitly enable > > additional compat views. > > > > Simo. > > > > May be we can enhance the compat view to use sub types for posix > attributes that denote a view. > Then use mapping of client IP/Hostname to a view using some kind of > relation object. > DS can already consider IP of the client so may be we can extend it to > use IP to pick the right sub-type value from a MV attribute.
Using the IP of a client in general is unreliable, we cannot base a change of behavior on that information. It would be a nightmare to debug. NAT, mobile clients, etc... will all cause any policy based on IP addresses to be unusable in various situations. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel