On Thu, 2013-02-14 at 17:31 +0100, Petr Viktorin wrote: > On 02/14/2013 05:01 PM, Simo Sorce wrote: > > On Thu, 2013-02-14 at 16:29 +0100, Petr Viktorin wrote: > >> Then I recommend doing this. It avoids problems with delegation (the > >> "real" tree permissions are used) and looping (plugin and IPA write to > >> separate trees). > > > > Virtual objects are not free of issues, you are just trading some issues > > for others here, and I do not think you are properly evaluating the > > trade here. > > > > I am dead set against using staging areas, and I want to see proof they > > are a good idea, not handwaving 'fears' of using json in the server to > > forward operations directly to the framework. > > > >> Other operations (deletes, mods) can be either > >> similarly delegated to the "real" tree, > > > > And *this* is a slippery slope. you are trading delegating one single > > operation to the framework directly, with proper error propagation back > > to the client, with now implementing full virtualized operations for mod > > and delete, and bind ? and search and then ? > > > > You are now basically paving the way for a virtual directory in tree. > > > > Sorry, but no. > > > >> or passed through IPA if we want to do that in the future. > > > >> Problems with replication can be solved by just not replicating the > >> separate tree. > > > > More and more hacks, for this supposedly 'cleaner' or 'simpler' > > solution ... sorry if I don't bite. > > > >> It also doesn't pollute core IPA with special cases, which is what > >> worries me. > > > > What does this mean ? > > > > We *have* a special case, and we are discussing how to handle it. > > > > The situation here (I do not want to call it a 'problem') is that we > > decided to put business logic around user creation in the framework > > because we thought that would be easier to prototype and develop in > > python code rather than in a plugin. > > > > However this special handling *must* be limited. LDAP is our main > > storage, and we must allow LDAP operations against it. Special cases > > needs to be limited to things that are really harder done in plugins > > rather then python code. > > > > For example if we need triggers for some operations in LDAP, they *must* > > be done through a 389ds plugin. Otherwise LDAP quickly becomes a > > read-only interface and interoperability quickly goes out of the window. > > > > I always treated the framework as a *management interface* on top. We > > can do things that are 'convenient', and 'help' admins avoid mistakes, > > but we cannot move core functionality in the framework, it would be a > > grave mistake. User creation *is* a special case, but should remain one > > of very few special exceptions. > > > > This very thread and the need for the interface proposed in this thread > > is a clear example of why we need to be extremely careful not to be too > > liberal with what business logic we move in the framework. > > > > LDAP keeps us honest, so we need to limit what we do in the framework, > > otherwise we'll keep taking shortcuts and soon enough it goes out of > > control and we loose interoperability with anything that is not > > purpose-built to talk to our framework. > > > > This should be an unacceptable scenario because it is like putting > > ourselves in a getto. > > > > We trade greater interoperability and acceptance for small conveniences > > here and there. > > > > We must thread *very* carefully along this line. > > > > Simo. > > > Ah! This is a point we need to stress more, I didn't get it. All this > time I thought of it the other way -- IPA being the main interface, with > LDAP being more of an implementation detail -- the storage, and a > read-only interface for LDAP consumers. > > Thanks for explaining, your solution makes perfect sense then. > > However, if there are more people like me, then there's code in IPA that > assumes IPA is the only interface modifications, and raw LDAP operations > are hacks that happen to work for now. > IPA's command plugins also seem misguided now, as you pointed out. > > > I don't like this view much but, well, I can adapt. > Allowing writes by tools that aren't purpose-built to talk to our > framework, (for example ones that don't honor our schema), still seems > like something to be wary of.
It's a balancing act. The schema is always honored, that's why there are MUST and MAY attributes. If the schema is build with the wrong specification of MUST and MAYs that's a bug on our part. Also, there are some parts of the tree that are more sensitive than others. Some things are pretty IPA specific, and for those cases relying a bit more on the framework is ok for now. But in general LDAP is a primary interface, it's where replication happens, and where all components converge. So it is the center of all things. Think about triggers for example. One of the triggers that gets often requested is to be create home directories when users are created. Now, besides the point of whether we want or can do that, if you were to implement it you would have to do it at the 389ds level. You cannot do it in the framework at all for the simple reason that the creation may need to happen on a completely different server than the one on which the admin is creating the users, so acting at the framework level would be meaningless. This information is transported to all other servers via LDAP replication. So the only sane way to trigger an operation is via a 389ds plugin so that it can trigger on the right destination server. This is just an example, but shows that LDAP is the core. Now the framework is crucial, I do not want to diminish the framework role or importance, but it is has its place and function, and must not be expanded where it shouldn't go. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel