Hi !
We are interested in deploying an openLDAP-based directory supporting the assertions control extension as defined in RFC 4528.
According to http://www.openldap.org/faq/data/cache/645.html (list of LDAPv3 features/extensions supported by the OpenLDAP server) openLDAP 2.3 already supports the assertion contol (we only need to use it in the LDAPModify operation) but I am not sure about the backends taking care of it (back-ndb and/or back-ldbm would be ok for us). Could any of you provide us this info? I was checking the mail archives, but I did not find the answer .... Thanks in advance Best regards / Antonio
Antonio Alonso Alarcón
CUDB System Engineer
Ericsson España, S.A. Phone: +34 91339 3085
Via de los Poblados 13 Mobile: +34 609640579 (66215) 28033 Madrid, Spain Fax: +34 91339 1636 E-mail: Antonio.Alonso@ericsson.com
Hi,
"Antonio Alonso" antonio.alonso@ericsson.com writes:
Hi !
We are interested in deploying an openLDAP-based directory supporting the assertions control extension as defined in RFC 4528.
According to http://www.openldap.org/faq/data/cache/645.html (list of LDAPv3 features/ extensions supported by the OpenLDAP server) openLDAP 2.3 already supports the assertion contol (we only need to use it in the LDAPModify operation) but I am not sure about the backends taking care of it (back-ndb and/or back-ldbm would be ok for us). Could any of you provide us this info? I was checking the mail archives, but I did not find the answer ….
As this is a DSA operation no backend is envolved, just calling a modify operation according to RFC 4528 will be sufficient.
-Dieter
Hi Dieter !
Thanks for the fast answer. Still some doubts :-( (I included them below your answer)
[mailto:openldap-software-bounces+antonio.alonso=ericsson.com@
OpenLDAP.org] On Behalf Of Dieter Kluenter writes
Hi,
"Antonio Alonso" antonio.alonso@ericsson.com writes:
Hi !
We are interested in deploying an openLDAP-based directory supporting the assertions control extension as defined in RFC 4528.
According to
http://www.openldap.org/faq/data/cache/645.html (list
of LDAPv3 features/ extensions supported by the OpenLDAP server) openLDAP 2.3 already supports the assertion contol (we only need to use it in the LDAPModify operation) but I am not sure about the backends taking care of it (back-ndb and/or back-ldbm would
be ok for
us). Could any of you provide us this info? I was checking the mail archives, but I did not find the
answer ....
As this is a DSA operation no backend is envolved, just calling a modify operation according to RFC 4528 will be sufficient.
I am not sure to understand your answer. What do you mean with "DSA operation"? (I understnd DSA in the X.500 scope and in the related LDAP scope, but I do not see the relation with the "assertion control" defined in this RFC
NOTE: As I understand RFC 4528 it is needed to check an assertion condition (based on one or a set of attribute values stored in the involved entry) before performing the required LDAP operation ... so I presume that backend must be involved in the "assertion check" too as it is the one holding the attribute values associated to an entry ... so the received assertion condition must be passed (from the front-end side) to the backend being used together the LDAP data related to the requested operation (DN, attribute types involved, attribute values involved, etc.)
Sorry if I am forgetting/misundertsanding something ....
-Dieter
-- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Dieter Kluenter wrote:
Hi,
"Antonio Alonso" antonio.alonso@ericsson.com writes:
Hi !
We are interested in deploying an openLDAP-based directory supporting the assertions control extension as defined in RFC 4528.
According to http://www.openldap.org/faq/data/cache/645.html (list of LDAPv3 features/ extensions supported by the OpenLDAP server) openLDAP 2.3 already supports the assertion contol (we only need to use it in the LDAPModify operation) but I am not sure about the backends taking care of it (back-ndb and/or back-ldbm would be ok for us). Could any of you provide us this info? I was checking the mail archives, but I did not find the answer ….
As this is a DSA operation no backend is envolved, just calling a modify operation according to RFC 4528 will be sufficient.
No. Assertion is only supported by back-bdb and back-sql.
Michael Ströder wrote:
Howard Chu wrote:
No. Assertion is only supported by back-bdb and back-sql.
And what about back-hdb?
Of course, back-hdb too. Aside from subtree rename (which back-hdb supports and back-bdb does not) the two backends are functionally identical; I've gotten tired of writing "back-bdb/back-hdb" all the time.
Howard Chu writes:
Of course, back-hdb too. Aside from subtree rename (which back-hdb supports and back-bdb does not) the two backends are functionally identical; I've gotten tired of writing "back-bdb/back-hdb" all the time.
The differences between hdb and bdb look small enough that they can easily be merged, unless they will diverge more in the future or there are arrays of EntryInfo somewhere.
The main ugliness I can see is with the BDB_HIER members of EntryInfo. Would need to move them out of EntryInfo and wrap them and EntryInfo in a struct hdb_hier_entry_info, and set a bit in EntryInfo, bdb_db_info and bdb_info if the database is hierarchical. '#if BDB_HIER' would mostly become if (BDB_IS_HIER(bi)) or if(ENTRY_IS_HIER(ei)), and those macros could return constants if not both bdb and hdb are supported.
Hallvard B Furuseth wrote:
Howard Chu writes:
Of course, back-hdb too. Aside from subtree rename (which back-hdb supports and back-bdb does not) the two backends are functionally identical; I've gotten tired of writing "back-bdb/back-hdb" all the time.
The differences between hdb and bdb look small enough that they can easily be merged, unless they will diverge more in the future or there are arrays of EntryInfo somewhere.
The effort required to do the merge, however trivial it may be (probably not) isn't worth it at the moment, since it offers no gain in functionality and there's currently no problem with maintainability. There's plenty of other things actually worth worrying about.
If you want to spend time changing internal structure definitions, what would actually be useful is doing a survey of structure field alignments, looking for wasted pad bytes and such, particularly in the context of processor cache line alignment. I know we've got a lot of structures that are perfectly well aligned on a 32 bit architecture but are grossly padded on 64 bit, and I suspect we have a lot of cache alignment issues impacting our multiprocessor performance. But again, this is a topic for the -devel list, not the -software list.
openldap-software@openldap.org
-
Antonio Alonso -
Dieter Kluenter -
Hallvard B Furuseth -
Howard Chu -
Michael Ströder