On 01/11/2013 03:55 PM, Rob Crittenden wrote:
John Dennis wrote:
On 01/11/2013 09:10 AM, Rob Crittenden wrote:
Petr Viktorin wrote:
We had a small discussion off-list about how we want IPA's LDAP
to look in the future.
To continue the discussion publicly I've summarized the results and
added some of my own ideas to a page.
John gets credit for the overview (the mistakes & WTFs are mine).
The text is on http://freeipa.org/page/V3/LDAP_code, and echoed below.
IIRC some of the the python-ldap code is used b/c ldap2 may require a
configuration to be set up prior to working. That is one of the nice
things about the IPAdmin interface, it is much easier to create
connections to other hosts.
Good point. But I don't believe that issue affects having a common API
or a single point where LDAP data flows through. It might mean having
more than one initialization method or subclassing.
Yes. I looked at the code again and saw the same thing. Fortunately,
there's not too much that needs the api object: creating the connection,
`get_ipa_config` which shouldn't really be at this level,
CrudBackend-specific things, and `normalize_dn` (which I'd really like
to remove but it's probably not worth the effort).
My working plan now is to have a ipaldap.LDAPBackend base class (please
give me a better name), and subclass ldap2 & IPAdmin from that.
IPAdmin would just add the legacy API which we'll try to move away from;
ldap2 would add the api-specific setup and CrudBackend bits (plus its
own legacy methods).
So, the ticket shouldn't really be named "installer code should use
Right. We may need to decouple from api a bit. I haven't looked at this
for a while but one of the problems is that api locks its values after
finalization which can make things a bit inflexible. We use some nasty
override code in some place but it isn't something I'd want to see
Freeipa-devel mailing list