Re: [Freeipa-devel] Using the new LDAP code
On 03/01/2013 11:14 AM, Martin Kosek wrote: Just FYI, I just pushed the relevant patches to master branch. Enjoy! Thanks to Petr and Honza for doing this refactoring! Yes, thanks and kudos to Petr and Honza for this work. We really needed to clean up this part of our code base and I'm confident code maintenance and robustness will benefit and serve the team and project going forward. Thanks again. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the new LDAP code
On 02/27/2013 06:22 PM, John Dennis wrote: > On 02/27/2013 12:22 PM, Jan Cholasta wrote: >> On 27.2.2013 18:14, John Dennis wrote: >>> On 02/27/2013 11:23 AM, Jan Cholasta wrote: Hi, On 27.2.2013 17:09, John Dennis wrote: >> IPA plugins traditionally use (dn, entry_attrs) pairs to represent >> entries. To make that work, iterating over an LDAPEntry will, for now, >> yield the DN and the entry itself. Always use keys() or values() when >> iterating over an entry. > > I'm trying parse what the above means, it seems to be one of the two: > > 1) There is still a bunch of code that continues to use 2-tuples in the > plugins and additional work remains to converge on a single API. > > 2) All the code that used 2-tuples has been cleaned up and expunged, > however if the old 2-tuple methodology was used it would still work. > it's the former, there is still code that uses 2-tuples. >>> >>> O.K. so we're still a ways away from completing the task. Would this be >>> a correct summary? >>> >>> Phase 1 is completed, a consistent API has been defined and implemented. >>> Phase 2 is converting all the code to use the API defined in Phase 1, a >>> task yet to be done. >>> >> >> Correct. But I don't think converting 2-tuples to the new API will be a >> huge task. > > Cool! > Just FYI, I just pushed the relevant patches to master branch. Enjoy! Thanks to Petr and Honza for doing this refactoring! Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the new LDAP code
On 02/27/2013 12:22 PM, Jan Cholasta wrote: On 27.2.2013 18:14, John Dennis wrote: On 02/27/2013 11:23 AM, Jan Cholasta wrote: Hi, On 27.2.2013 17:09, John Dennis wrote: IPA plugins traditionally use (dn, entry_attrs) pairs to represent entries. To make that work, iterating over an LDAPEntry will, for now, yield the DN and the entry itself. Always use keys() or values() when iterating over an entry. I'm trying parse what the above means, it seems to be one of the two: 1) There is still a bunch of code that continues to use 2-tuples in the plugins and additional work remains to converge on a single API. 2) All the code that used 2-tuples has been cleaned up and expunged, however if the old 2-tuple methodology was used it would still work. it's the former, there is still code that uses 2-tuples. O.K. so we're still a ways away from completing the task. Would this be a correct summary? Phase 1 is completed, a consistent API has been defined and implemented. Phase 2 is converting all the code to use the API defined in Phase 1, a task yet to be done. Correct. But I don't think converting 2-tuples to the new API will be a huge task. Cool! -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the new LDAP code
On 27.2.2013 18:14, John Dennis wrote: On 02/27/2013 11:23 AM, Jan Cholasta wrote: Hi, On 27.2.2013 17:09, John Dennis wrote: IPA plugins traditionally use (dn, entry_attrs) pairs to represent entries. To make that work, iterating over an LDAPEntry will, for now, yield the DN and the entry itself. Always use keys() or values() when iterating over an entry. I'm trying parse what the above means, it seems to be one of the two: 1) There is still a bunch of code that continues to use 2-tuples in the plugins and additional work remains to converge on a single API. 2) All the code that used 2-tuples has been cleaned up and expunged, however if the old 2-tuple methodology was used it would still work. it's the former, there is still code that uses 2-tuples. O.K. so we're still a ways away from completing the task. Would this be a correct summary? Phase 1 is completed, a consistent API has been defined and implemented. Phase 2 is converting all the code to use the API defined in Phase 1, a task yet to be done. Correct. But I don't think converting 2-tuples to the new API will be a huge task. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the new LDAP code
On 02/27/2013 11:23 AM, Jan Cholasta wrote: Hi, On 27.2.2013 17:09, John Dennis wrote: IPA plugins traditionally use (dn, entry_attrs) pairs to represent entries. To make that work, iterating over an LDAPEntry will, for now, yield the DN and the entry itself. Always use keys() or values() when iterating over an entry. I'm trying parse what the above means, it seems to be one of the two: 1) There is still a bunch of code that continues to use 2-tuples in the plugins and additional work remains to converge on a single API. 2) All the code that used 2-tuples has been cleaned up and expunged, however if the old 2-tuple methodology was used it would still work. it's the former, there is still code that uses 2-tuples. O.K. so we're still a ways away from completing the task. Would this be a correct summary? Phase 1 is completed, a consistent API has been defined and implemented. Phase 2 is converting all the code to use the API defined in Phase 1, a task yet to be done. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the new LDAP code
Hi, On 27.2.2013 17:09, John Dennis wrote: IPA plugins traditionally use (dn, entry_attrs) pairs to represent entries. To make that work, iterating over an LDAPEntry will, for now, yield the DN and the entry itself. Always use keys() or values() when iterating over an entry. I'm trying parse what the above means, it seems to be one of the two: 1) There is still a bunch of code that continues to use 2-tuples in the plugins and additional work remains to converge on a single API. 2) All the code that used 2-tuples has been cleaned up and expunged, however if the old 2-tuple methodology was used it would still work. it's the former, there is still code that uses 2-tuples. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the new LDAP code
On 02/27/2013 05:09 PM, John Dennis wrote: On 02/27/2013 06:46 AM, Petr Viktorin wrote: Hello, A big refactoring of our LDAP code should be merged soon-ish now. Here's a summary for developers. Great, that's fabulous news and thanks for the good work! IPA plugins traditionally use (dn, entry_attrs) pairs to represent entries. To make that work, iterating over an LDAPEntry will, for now, yield the DN and the entry itself. Always use keys() or values() when iterating over an entry. I'm trying parse what the above means, it seems to be one of the two: 1) There is still a bunch of code that continues to use 2-tuples in the plugins and additional work remains to converge on a single API. 2) All the code that used 2-tuples has been cleaned up and expunged, however if the old 2-tuple methodology was used it would still work. The first. There are minimal changes to the plugins (most changes there are related to the removal of DN normalization). -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the new LDAP code
On 02/27/2013 06:46 AM, Petr Viktorin wrote: Hello, A big refactoring of our LDAP code should be merged soon-ish now. Here's a summary for developers. Great, that's fabulous news and thanks for the good work! IPA plugins traditionally use (dn, entry_attrs) pairs to represent entries. To make that work, iterating over an LDAPEntry will, for now, yield the DN and the entry itself. Always use keys() or values() when iterating over an entry. I'm trying parse what the above means, it seems to be one of the two: 1) There is still a bunch of code that continues to use 2-tuples in the plugins and additional work remains to converge on a single API. 2) All the code that used 2-tuples has been cleaned up and expunged, however if the old 2-tuple methodology was used it would still work. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Using the new LDAP code
Hello,
A big refactoring of our LDAP code should be merged soon-ish now. Here's
a summary for developers.
If you see these outside ipaldap.py, you're looking at deprecated API:
- methods with camelCaseNames
- methods with _s and _ext postfixes (modify_s, search_ext, ...)
The exception is client code and places where we don't want to read the
schema (migration, AD). These are still limited to raw python-ldap for now.
The LDAPEntry class represents LDAP entries. It behaves like a
dictionary of lists: entry.get(attrname) or entry[attrname] should
always give you a list.
LDAPEntry.dn will give you the entry's DN.
Single-value attributes are represented as lists with a single value.
(For now, some code still puts bare values instead of lists in entries,
in that case you'll still get a bare value from get()/__getitem__. That
should be fixed eventually.)
The "single_value" method gets a single value, with checking. Always use
`entry.single_value('abc')` instead of `entry.get('abc')[0]`.
Also, single_value allows a default: `entry.single_value('abc', None)`.
LDAPEntry is case-insensitive and handles attributes with multiple
names: entry['cn'] and entry['CN'] and entry['CommonName'] are equivalent.
IPA plugins traditionally use (dn, entry_attrs) pairs to represent
entries. To make that work, iterating over an LDAPEntry will, for now,
yield the DN and the entry itself. Always use keys() or values() when
iterating over an entry.
LDAPEntry objects are tied to a connection. Do not create them directly,
use a connection method like make_entry() or get_entry().
Speaking of connections, there still are two classes for those: ldap2
and IPAdmin.
ldap2 is an API plugin created using the IPA settings. It works in
Apache (per-thread connections). It also applies the default IPA
settings (time & records limit).
Use IPAdmin if IPA is not installed yet (or when it's being
uninstalled), or if you need to connect to a non-default server or bind
as a user like the DM.
Besides the connecting code, both of these (will ideally) have the same
API, based on the old ldap2. A rough summary:
- make_entry(dn, attrs)
- get_entry(dn)
- add_entry(entry)
- update_entry(entry)
- delete_entry(entry_or_dn)
- get_entries(base_dn, [scope, [filter, [attrs_list]]]): simple search
- find_entries: more powerful (and backwards-compatible) search
- make_filter & friends, unchanged from ldap2
ldap2's DN normalization – appending the suffix to DNs that don't end
with it – is gone, you need to do that manually now.
That should be it, if you don't intend to hack on ipaldap itself or the
ldapupdater. If you have any questions, ask! (Or look at the code :)
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
