11:55 p.m.
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(a)ericsson.com
9:55 a.m.
Hi,
"Antonio Alonso" <antonio.alonso(a)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
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
11:51 a.m.
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(a)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
1:59 p.m.
Dieter Kluenter wrote:
Hi,
"Antonio Alonso" <antonio.alonso(a)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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:41 p.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:18 a.m.
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
12:27 a.m.
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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5821
days inactive
5824
days old
openldap-software@openldap.org
7 comments
5 participants
participants (5)
-
Antonio Alonso -
Dieter Kluenter -
Hallvard B Furuseth -
Howard Chu -
Michael Ströder