On 02/14/2013 12:33 PM, Endi Sukma Dewata wrote: > On 2/14/2013 8:06 AM, Simo Sorce wrote: >> On Thu, 2013-02-14 at 14:26 +0100, Petr Spacek wrote: >> >>> In my Fedora 17 I found package python-ldaptor. It seems to offer >>> nice support >>> for writing own event-based LDAP servers. For simple LDAP proxy it >>> could be >>> enough. >>> >>> $ yum install python-ldaptor >>> $ python >>> import ldaptor.protocols.ldap.ldapserver >>> help(ldaptor.protocols.ldap.ldapserver) >> >> No. >> LDAP proxies are *not* simple. >> >> Ask Endi he's worked on a meta-directory for years. >> >> Simo. > > It depends on what you want to do with the proxy. If it's only a thin > layer which converts the LDAP ADD to IPA user-add it might not be that > complicated. > > Penrose virtual directory consists of a frontend LDAP interface, a > transformation engine, and backends which may include an LDAP server > as well. The front-end LDAP interface is the proxy we're talking about > here, it's only used to receive LDAP requests and pass them to the > transformation engine. > > The transformation engine is where the complexity occurs. In IPA this > is already handled by the framework. In Penrose it's quite complex > because it aims to provide a generic way to map an LDAP request to > multiple backends which involves dealing with different types of > backends, joining the backends, transforming the DN & attributes back > and forth, etc. > > So I'd say implementing an LDAP frontend for IPA using Python is > something worth exploring. That way it can run in the same process so > there's no concern about JSON performance/stability. > +1 I would rather go this way.
Simo, Your point about how things should have been bight be righteous but Petr confusion about the role framework shows the reality. Currently all framework is developed as if it is the primary interface for creation/modification. LDAP is exposed but can be consumed by external clients as read only. This is how we decided to implement things. I clearly remember a lengthy discussion about this 4 years ago when the framework architecture was discussed. The main reason is plugability. Since we need to provide extensible plugability framework it is the only supportable option. For good or for bad it is how things are now and Petr is correct because this is what was decided and this is what he was told. It might have been a wrong decision (the interaction with the DS team was not at the same level as it is now) but under circumstances it was the one we made. And we now need to live with it. I do not think we have time to reevaluate things and move them into DS plugins is we find the framework abusing its power. I generally disagree with the notion that we can and should view add-user as the only special operation. Because of the framework extensibility any operation can be special. So I think that external LDAP proxy makes more sense. It is a bit more complex than what you propose but has several significant benefits: * We need LDAP proxy for other purposes so there will be a reuse of code and framework * We already have expertise * It allows us to keep what we already have done without any conceptual changes and continue with the approach we have been developing framework for last 4 years * It can be developed independently and incrementally without affecting the core IPA and its release schedule * It does not require and knowledge of the internals of IPA framework or DS plugins and can be developed by an external contributor I agree that virtual entries and staging areas are not the right approach. I also do not think that penrose at least in its current incarnation is the right approach either. Leveraging a python based LDAP proxy sounds like a good starting point. With that I suggest to move this conversation from what to who and how. Do we have an RFE logged? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel