Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by lmb@cloudflare.com
--94eb2c07d07472c185053d5903fe
Content-Type: text/plain; charset=UTF-8
I've updated the patch to be much simpler:
* Set pthread_sigmask in copythr and return an error in my->mc_error
* Do not check for pending SIGPIPE: since this is a new thread there can't
be any
The URL stays the same.
--94eb2c07d07472c185053d5903fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">I've updated the patch to b=
e much simpler:</div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">* Set pthread_sigmask in copythr and return an error in my->mc=
_error</div><div class=3D"gmail_extra">* Do not check for pending SIGPIPE: =
since this is a new thread there can't be any</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">The URL stays the same.</div></=
div>
--94eb2c07d07472c185053d5903fe--
6 years, 8 months
(ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by lmb@cloudflare.com
Full_Name: Lorenz Bauer
Version:
OS:
URL: https://gist.github.com/lmb/63189f83c5f00dd59c86f3c9bc07694d
Submission from: (NULL) (2606:4700:1000:8200:5530:fc35:2f95:4f31)
As per the discussion in [1] I'm providing a patch to block and handle SIGPIPE
in the copy thread used when performing a compacting copy.
The attached file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed by
CloudFlare, Inc. CloudFlare, Inc. has not assigned rights and/or interest in
this work to any party. I, Lorenz Bauer am authorized by CloudFlare, Inc., my
employer, to release this work under the following terms.
CloudFlare, Inc. hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
1: http://www.openldap.org/lists/openldap-technical/201609/msg00026.html
6 years, 8 months
Re: (ITS#8475) Feature request: MDB low durability transactions
by h.b.furuseth@usit.uio.no
I'll use this ITS to summarize details for "volatile commits".
Hopefully I've managed to keep it all straight.
"Volatile" vs. "durable" are the most accurate names I can think of.
Not sure if that's more instructive than simply "soft" / "hard".
Description:
* Volatile commits omit fdatasync() without losing consistency. To
survive, they must be checkpointed *before* all processes close the
env. Un-checkpointed volatiles are lost when the env closes.
Thus a separate checkpointing daemon can keep the env open to
protect volatiles from application crash, at least if Robust locks
are supported. (The lmdb.h doc seems a bit unclear about Robust.)
* Checkpointing == committing a durable (non-volatile) write-txn.
(If there is nothing to do, Commit writes nothing.)
mdb_env_sync() will not checkpoint volatiles, since existing
programs do not expect it to wait for the write mutex. It
"checkpoints" MDB_NOMETASYNC/MDB_NOSYNC. Maybe mdb_checkpoint()
will have a special case which obsoletes mdb_env_sync().
* Volatiles are unsupported with MDB_NOLOCK and pointless with
MDB_NOSYNC. OTOH it makes sense to enable MDB_NOMETASYNC.
* Volatiles need a bigger datafile, because it takes two durable
commits to make a freed page reusable. (Plus awaiting old readers).
Configuration. Too many options, ouch:
LMDB can be configured to auto-checkpoint after X volatile commits
and/or Y written kbytes(pages?). Programs can also checkpoint every
Z minutes(seconds?) - configured in LMDB to mimic Berkeley DB's
"checkpoint <kbytes> <minutes>", but regular LMDB ops ignore that.
The lockfile gives the current config. An MDB_env could override
for its particular process, e.g. with an MDB_NO_VOLATILE flag.
Maybe resetting the lockfile should keep the previous config?
OTOH I suppose MDB_meta can have default params the way it has
mm_mapsize. That survives a backup/restore.
Implementation - plain version first:
* Bump MDB_LOCK_FORMAT, MDB_DATA_VERSION (or make MDB_DATA_FORMAT).
* Keep 2 'MDB_meta's in the lockfile, for volatile commits.
MDB_env.me_metas[] gets 4 elements: durable + volatile.
* mdb_env_open() throws away volatiles if it re-inits the lockfile.
* Add field MDB_meta.mm_oldest: 1 + (previous durable meta).mm_txnid
in durable metas, and (previous meta).mm_oldest in volatile metas.
Init 'oldest' in mdb_find_oldest() to new field MDB_env.me_oldest,
which mdb_txn_renew0(write txn) sets to MDB_meta.mm_oldest.
When are no volatiles, this ends up initing 'oldest' = same value
as today. Usually we could just have used 1 + (oldest durable
meta).mm_txnid, but a failed write_meta() may have clobbered that.
* Replace MDB_txninfo.mti_txnid with mti_metaref = txnid*16 + P*4 + M:
M = index to MDB_env.me_metas[],
P = previous M during this session, initialized to the same as M,
so we can get this info atomically.
P may prove unnecessary, but it's simplest to just include it for
now. For when meta M fails a checksum so we want an older meta, for
mdb_mutex_failed(), maybe so we can see if there are volatiles yet.
* Never use mdb_env_pick_meta() when the current metapage is known:
Use it in mdb_env_open(), in mdb_mutex_failed(), and if MDB_NOLOCK.
Or rather, I guess it gets a "force" param for those cases.
* Add config in the lockfile. Maybe per-env config overriding it and
defaults in the datafile. Txn flags "prefer volatile", "checkpoint".
* Track the number of pages and volatiles since last durable commit.
write_meta() compares with the config limits and makes the final
decision of whether the new meta will be volatile.
Add MDB_pgstate.mf_pgcount with #pages used so far. The rest goes
in a lockfile array[4] indexed by mti_metaref % 4, or in MDB_meta.
That way, switching to next snapshot stays atomic - just update
mti_metaref.
* txn_begin must verify metas, since we have no fdatasync barriers.
Re-read and compare, or checksum.
write_meta() and mutex_failed(): memory barrier between making
a volatile meta and updating mti_metaref. Most modern compilers
have that. Maybe a fallback implementation is lock;unlock an
otherwise unused mutex. Should also include CACHEFLUSH().
It may make sense to have more than 2 volatile metas, so read-only
txns will have more time to read a meta before it gets overwritten.
MDB_WRITEMAP (and MDB_VL32?) has non-atomic issues we should deal
with anyway.
* We can have (durable metapage).mp_pgno == (txnid & 1) as before:
mdb_txn_renew0() steps txnid by 2 instead of 1 if 'meta' is volatile.
But note that the txnid doesn't say if the snapshot is durable.
* "Try to checkpoint" feature, which does not await the write mutex:
Trylock the write mutex in mdb_txn_begin(). If it fails, set a
lockfile flag "Please checkpoint" and return. Hopefully someone
will obey and clear the flag. mdb_env_commit(writer) does.
Variants:
* Put volatile MDB_metas in the datafile, behind the usual MDB_metas.
That protects the metas from malicious/broken processes with
read-only envs. Otherwise, using the lockfile (or non-file shared
memory) extended read-only envs' ability to hack/break the DB.
Be careful to not read volatile MDB_metas that are older than last
lockfile-reset, since the reset did not clear them. That also means
this variant does not enable volatiles with MDB_NOLOCK.
* Stay with MDB_DATA_VERSION = 1, no change in datafile format:
- Volatiles share next durable txn's txnid (for freeDB keys), but
put last durable txn's txnid in mti_metaref (for mdb_find_oldest).
- mdb_txn_id() / MDB_envinfo.me_last_txnid can no longer be used to
distinguish txns.
Apps doing that could set an env flag "ignore volatiles", or txn
flag "fail if current snapshot is volatile".
- Define V = 2-bit sequence number incremented by commit(writer).
Include V in MDB_txninfo.mti_metaref. In volatile metas, include
mm_metaref = copy of mti_metaref.
This lets mutex_failed() figure out which MDB_meta is most recent:
abs(V in mm_metaref - V in mti_metaref) is <= 1 whether mm_metaref
or mti_metaref changes first in the thread.
* Support full 32-bit txnids on 32-bit hosts.
mti_metaref eats some txnid bits in order to stay atomic, but we can
get them back:
On 32-bit hosts, make mti_metaref a 64-bit value - something like
((txnid << 32) | R) where R = 32-bit metaref value described before.
When reading mti_metaref, R is authoritative for the low txnid bits.
If (txnid << 32) part does not match, adjust it so it does: That'll
be + or - a small value. mti_metaref's high bits vary slowly, so
this is normally "atomic". txn_renew0's loop re-reads it to verify.
* We can squeeze away some bytes and mti_metaref bits, but don't get
sucked into spending time on that before the rest is working.
E.g. the array[4] counting pages/volatiles can be just [2] if
Commit always toggles the (mti_metaref & 1) bit. And we can likely
include some of the mti_metaref fields in the txnid.
Roads to Hell:
* Support checkpointing without waiting for the write-mutex.
Programs which have used volatiles, may want this so they can exit
quickly. But it requires a new shared mutex for write_meta(), or
some clever tricks I've thought of which would not quite work.
* Rescue volatiles in a dead lockfile when the user "knows" it's safe.
Easy enough, just don't clear them when resetting the lockfile.
But users screw up, and may then blame LMDB. Users who want to
screw up, can run use MDB_NOSYNC instead of volatile commits.
Or if volatile metas are in non-file shared memory which a system
crash will kill, it's _almost_ safe to not reset them along with the
lockfile. Unless someone unmounts/mounts the disk, or replaces the
DB by overwriting it with another DB file, or who knows what else.
--
Hallvard
6 years, 8 months
(ITS#8503) Provide proper soname to liblmdb.so.1
by gahr@gahr.ch
Full_Name: Pietro Cerutti
Version: LMDB 0.9.18
OS: FreeBSD
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (69.191.176.31)
This patch provides the shared lib with a proper soname.
diff --git a/libraries/liblmdb/Makefile b/libraries/liblmdb/Makefile
index 72d0984..4429992 100644
--- a/libraries/liblmdb/Makefile
+++ b/libraries/liblmdb/Makefile
@@ -66,7 +66,7 @@ liblmdb.a: mdb.o midl.o
liblmdb$(SOEXT): mdb.lo midl.lo
# $(CC) $(LDFLAGS) -pthread -shared -Wl,-Bsymbolic -o $@ mdb.o midl.o
$(SOLIBS)
- $(CC) $(LDFLAGS) -pthread -shared -o $@ mdb.lo midl.lo $(SOLIBS)A0A+
4%4(CC) $(LDFLAGS) -pthread -shared -Wl,-soname=$@ -o $@ mdb.lo midl.lo
$(SOLIBS)
mdb_stat: mdb_stat.o liblmdb.a
mdb_copy: mdb_copy.o liblmdb.a
6 years, 8 months
Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by mblagoeva@axway.com
--_000_AM4PR0101MB19549BBC7F2AB2947F4C5505BBF10AM4PR0101MB1954_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Howard,
Thanks again. This strangely enough works with 2.4.40 version , previously =
I was using 2.4.31.
________________________________
From: Howard Chu <hyc(a)symas.com>
Sent: Tuesday, September 13, 2016 9:23:07 PM
To: Maria Blagoeva; openldap-its(a)OpenLDAP.org
Subject: Re: (ITS#8501) OpenLdap not RFC 2891 complaint
Maria Blagoeva wrote:
> Hello Howard,
>
>
> And just one more follow-up question, if you do not mind, just to have th=
e
> full picture. The way the RFC is construct, it seems that if the ordering=
rule
> is omitted in the request one that is defined must be used, but if nothin=
g is
> defined in the schema nothing will be used, but I do not understand why t=
he
> openlap will fail than. Exactly the same request works fine with
> ActiveDirectory server.
ActiveDirectory is not RFC-compliant.
> The quotes from the RFC directly:
> The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD
> be one that is valid for the attribute type it applies to. If it is
> not, the server will return inappropriateMatching.
> If the orderingRule is omitted, the ordering MatchingRule defined for
> use with this attribute MUST be used.
And when no MatchingRule exists for an attribute, matching cannot be
performed. That is part of RFC4511 so there's no need to state it here.
> Thanks again for your insights.
>
>
> -------------------------------------------------------------------------=
-----
> *From:* Maria Blagoeva
> *Sent:* Tuesday, September 13, 2016 8:50:45 AM
> *To:* Howard Chu; openldap-its(a)OpenLDAP.org
> *Subject:* Re: (ITS#8501) OpenLdap not RFC 2891 complaint
>
>
> Hello Howard,
>
>
> This means I need to patch the openldap instance or a default ordering ru=
le
> can be set for that attribute on the fly? Thanks again for your help and
> assistance.
>
>
> BR,
>
> Maria
>
> -------------------------------------------------------------------------=
-----
> *From:* Howard Chu <hyc(a)symas.com>
> *Sent:* Monday, September 12, 2016 6:31:25 PM
> *To:* Maria Blagoeva; openldap-its(a)OpenLDAP.org
> *Subject:* Re: (ITS#8501) OpenLdap not RFC 2891 complaint
>
> mblagoeva(a)axway.com wrote:
>> Full_Name: Maria Blagoeva
>> Version: openldap-2.4.31/debian/build/servers/slapd
>> OS: docker image with 3.10.0-327.28.2.el7.x86_64
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (194.88.228.86)
>>
>>
>> It seems that openldap as of 2.4.31 is not RFC complaint
>> (https://www.ietf.org/rfc/rfc2891.txt) due to failure in response when o=
rdering
>> match rule is empty while doing server side sorting. Example below:
>
> False. OpenLDAP is completely correct and RFC-compliant in its behavior.
>
>> empty ordering rule:
>>
>> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgPerson)=
(cn=3Dccc*))' -H
>> ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "cn=3Daaa1,
>> ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree
>> # filter: (cn=3Dccc*)
>> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))
>> # with server side sorting control
>> #
>>
>> # search result
>> search: 2
>> result: 18 Inappropriate matching
>> text: serverSort control: No ordering rule
>
> This result is correct since the cn attribute has no ordering rule define=
d in
> the schema.
>>
>> # numResponses: 1
>>
>> caseIgnoreOrderingMatch ordering rule:
>>
>> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'
>> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 -b
>> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou=3DUsers,dc=3Dopen=
stack,dc=3Dorg" -x
>> -W
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree
>> # filter: (cn=3Dccc*)
>> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))
>> # with server side sorting control
>> #
>>
>> # ccc0, Users, openstack.org
>> dn: cn=3Dccc0,ou=3DUsers,dc=3Dopenstack,dc=3Dorg
>> # search result
>> search: 2
>> result: 0 Success
>> control: 1.2.840.113556.1.4.474 false MAMKAQA=3D
>> sortResult: (0) Success
>>
>>
>> however the RFC states that the orderingRule is OPTIONAL as below:
>>
>> SortKeyList ::=3D SEQUENCE OF SEQUENCE {
>> attributeType AttributeDescription,
>> orderingRule [0] MatchingRuleId OPTIONAL,
>> reverseOrder [1] BOOLEAN DEFAULT FALSE }
>>
>> however openldap fails to return entries.
>
> The rule is optional in the control itself, but a valid ordering rule mus=
t
> exist somewhere. Since the attribute schema doesn't define one then you m=
ust
> provide one yourself.
>
> Closing this ITS.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--_000_AM4PR0101MB19549BBC7F2AB2947F4C5505BBF10AM4PR0101MB1954_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad=
ding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content=3D"text/html; charset=3DUTF-8">
<style type=3D"text/css" style=3D"">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir=3D"ltr">
<div id=3D"x_divtagdefaultwrapper" style=3D"font-size:12pt; color:#000000; =
background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hello Howard,</p>
<p><br>
</p>
<p>Thanks again. This strangely enough works with 2.4.40 version , previous=
ly I was using 2.4.31.<br>
</p>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Howard Chu <hyc@=
symas.com><br>
<b>Sent:</b> Tuesday, September 13, 2016 9:23:07 PM<br>
<b>To:</b> Maria Blagoeva; openldap-its(a)OpenLDAP.org<br>
<b>Subject:</b> Re: (ITS#8501) OpenLdap not RFC 2891 complaint</font>
<div> </div>
</div>
</div>
<font size=3D"2"><span style=3D"font-size:10pt;">
<div class=3D"PlainText">Maria Blagoeva wrote:<br>
> Hello Howard,<br>
><br>
><br>
> And just one more follow-up question, if you do not mind, just to have=
the<br>
> full picture. The way the RFC is construct, it seems that if the order=
ing rule<br>
> is omitted in the request one that is defined must be used, but if not=
hing is<br>
> defined in the schema nothing will be used, but I do not understand wh=
y the<br>
> openlap will fail than. Exactly the same request works fine with<br>
> ActiveDirectory server.<br>
<br>
ActiveDirectory is not RFC-compliant.<br>
<br>
> The quotes from the RFC directly:<br>
<br>
> The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD<br=
>
> be one that is valid for the attribute type it appli=
es to. If it is<br>
> not, the server will return inappropriateMatching.<b=
r>
<br>
> If the orderingRule is omitted, the ordering MatchingRule define=
d for<br>
> use with this attribute MUST be used.<br>
<br>
And when no MatchingRule exists for an attribute, matching cannot be <br>
performed. That is part of RFC4511 so there's no need to state it here.<br>
<br>
> Thanks again for your insights.<br>
><br>
><br>
> ----------------------------------------------------------------------=
--------<br>
> *From:* Maria Blagoeva<br>
> *Sent:* Tuesday, September 13, 2016 8:50:45 AM<br>
> *To:* Howard Chu; openldap-its(a)OpenLDAP.org<br>
> *Subject:* Re: (ITS#8501) OpenLdap not RFC 2891 complaint<br>
><br>
><br>
> Hello Howard,<br>
><br>
><br>
> This means I need to patch the openldap instance or a default ordering=
rule<br>
> can be set for that attribute on the fly? Thanks again for your help a=
nd<br>
> assistance.<br>
><br>
><br>
> BR,<br>
><br>
> Maria<br>
><br>
> ----------------------------------------------------------------------=
--------<br>
> *From:* Howard Chu <hyc(a)symas.com><br>
> *Sent:* Monday, September 12, 2016 6:31:25 PM<br>
> *To:* Maria Blagoeva; openldap-its(a)OpenLDAP.org<br>
> *Subject:* Re: (ITS#8501) OpenLdap not RFC 2891 complaint<br>
><br>
> mblagoeva(a)axway.com wrote:<br>
>> Full_Name: Maria Blagoeva<br>
>> Version: openldap-2.4.31/debian/build/servers/slapd<br>
>> OS: docker image with 3.10.0-327.28.2.el7.x86_64<br>
>> URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openld=
ap.org/incoming/</a><br>
>> Submission from: (NULL) (194.88.228.86)<br>
>><br>
>><br>
>> It seems that openldap as of 2.4.31 is not RFC complaint<br>
>> (<a href=3D"https://www.ietf.org/rfc/rfc2891.txt">https://www.ietf=
.org/rfc/rfc2891.txt</a>) due to failure in response when ordering<br>
>> match rule is empty while doing server side sorting. Example below=
:<br>
><br>
> False. OpenLDAP is completely correct and RFC-compliant in its behavio=
r.<br>
><br>
>> empty ordering rule:<br>
>><br>
>> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3Dinet=
OrgPerson)(cn=3Dccc*))' -H<br>
>> ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D=
"cn=3Daaa1,<br>
>> ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W<br>
>> # extended LDIF<br>
>> #<br>
>> # LDAPv3<br>
>> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtr=
ee<br>
>> # filter: (cn=3Dccc*)<br>
>> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<b=
r>
>> # with server side sorting control<br>
>> #<br>
>><br>
>> # search result<br>
>> search: 2<br>
>> result: 18 Inappropriate matching<br>
>> text: serverSort control: No ordering rule<br>
><br>
> This result is correct since the cn attribute has no ordering rule def=
ined in<br>
> the schema.<br>
>><br>
>> # numResponses: 1<br>
>><br>
>> caseIgnoreOrderingMatch ordering rule:<br>
>><br>
>> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'<b=
r>
>> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 =
-b<br>
>> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1,=
ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x<br>
>> -W<br>
>> # extended LDIF<br>
>> #<br>
>> # LDAPv3<br>
>> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtr=
ee<br>
>> # filter: (cn=3Dccc*)<br>
>> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<b=
r>
>> # with server side sorting control<br>
>> #<br>
>><br>
>> # ccc0, Users, openstack.org<br>
>> dn: cn=3Dccc0,ou=3DUsers,dc=3Dopenstack,dc=3Dorg<br>
>> # search result<br>
>> search: 2<br>
>> result: 0 Success<br>
>> control: 1.2.840.113556.1.4.474 false MAMKAQA=3D<br>
>> sortResult: (0) Success<br>
>><br>
>><br>
>> however the RFC states that the orderingRule is OPTIONAL as below:=
<br>
>><br>
>> SortKeyList ::=3D SEQUENCE OF =
SEQUENCE {<br>
>> &=
nbsp; attributeType AttributeDesc=
ription,<br>
>> &=
nbsp; orderingRule [0] Matc=
hingRuleId OPTIONAL,<br>
>> &=
nbsp; reverseOrder [1] BOOL=
EAN DEFAULT FALSE }<br>
>><br>
>> however openldap fails to return entries.<br>
><br>
> The rule is optional in the control itself, but a valid ordering rule =
must<br>
> exist somewhere. Since the attribute schema doesn't define one then yo=
u must<br>
> provide one yourself.<br>
><br>
> Closing this ITS.<br>
><br>
> --<br>
> -- Howard Chu<br>
> CTO, Symas Corp. =
<a href=3D"http://www.symas.com">http://www.symas.=
com</a><br>
> Director, Highland Sun <a hr=
ef=3D"http://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a><br>
> Chief Architect, OpenLDAP <a href=3D"http://ww=
w.openldap.org/project/">http://www.openldap.org/project/</a><br>
<br>
<br>
-- <br>
-- Howard Chu<br>
CTO, Symas Corp. &nbs=
p; <a href=3D"http://www.symas.com">http://www.symas.com</a><br=
>
Director, Highland Sun <a href=3D"http=
://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a><br>
Chief Architect, OpenLDAP <a href=3D"http://www.openldap=
.org/project/">http://www.openldap.org/project/</a><br>
</div>
</span></font>
</body>
</html>
--_000_AM4PR0101MB19549BBC7F2AB2947F4C5505BBF10AM4PR0101MB1954_--
6 years, 8 months
Re: (ITS#8490) changes not written to accesslog, causing replicas to loop syncing
by quanah@zimbra.com
--On Friday, September 09, 2016 9:40 PM +0000 quanah(a)zimbra.com wrote:
> --On Thursday, September 01, 2016 9:50 AM +0000 quanah(a)zimbra.com wrote:
Backing out various changes, I tracked this down to the recent rewrite of
ITS8054. As soon as that patch is introduced, changes are lost, causing
this issue (and 8493).
--Quanah
--
Quanah Gibson-Mount
6 years, 8 months
Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by hyc@symas.com
Maria Blagoeva wrote:
> Hello Howard,
>
>
> And just one more follow-up question, if you do not mind, just to have the
> full picture. The way the RFC is construct, it seems that if the ordering rule
> is omitted in the request one that is defined must be used, but if nothing is
> defined in the schema nothing will be used, but I do not understand why the
> openlap will fail than. Exactly the same request works fine with
> ActiveDirectory server.
ActiveDirectory is not RFC-compliant.
> The quotes from the RFC directly:
> The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD
> be one that is valid for the attribute type it applies to. If it is
> not, the server will return inappropriateMatching.
> If the orderingRule is omitted, the ordering MatchingRule defined for
> use with this attribute MUST be used.
And when no MatchingRule exists for an attribute, matching cannot be
performed. That is part of RFC4511 so there's no need to state it here.
> Thanks again for your insights.
>
>
> ------------------------------------------------------------------------------
> *From:* Maria Blagoeva
> *Sent:* Tuesday, September 13, 2016 8:50:45 AM
> *To:* Howard Chu; openldap-its(a)OpenLDAP.org
> *Subject:* Re: (ITS#8501) OpenLdap not RFC 2891 complaint
>
>
> Hello Howard,
>
>
> This means I need to patch the openldap instance or a default ordering rule
> can be set for that attribute on the fly? Thanks again for your help and
> assistance.
>
>
> BR,
>
> Maria
>
> ------------------------------------------------------------------------------
> *From:* Howard Chu <hyc(a)symas.com>
> *Sent:* Monday, September 12, 2016 6:31:25 PM
> *To:* Maria Blagoeva; openldap-its(a)OpenLDAP.org
> *Subject:* Re: (ITS#8501) OpenLdap not RFC 2891 complaint
>
> mblagoeva(a)axway.com wrote:
>> Full_Name: Maria Blagoeva
>> Version: openldap-2.4.31/debian/build/servers/slapd
>> OS: docker image with 3.10.0-327.28.2.el7.x86_64
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (194.88.228.86)
>>
>>
>> It seems that openldap as of 2.4.31 is not RFC complaint
>> (https://www.ietf.org/rfc/rfc2891.txt) due to failure in response when ordering
>> match rule is empty while doing server side sorting. Example below:
>
> False. OpenLDAP is completely correct and RFC-compliant in its behavior.
>
>> empty ordering rule:
>>
>> ldapsearch -E sss=cn '(cn=ccc*)' cn' (&(objectClass=inetOrgPerson)(cn=ccc*))' -H
>> ldap://IP:389 -b "ou=Users,dc=openstack,dc=org" -D "cn=aaa1,
>> ou=Users,dc=openstack,dc=org" -x -W
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=Users,dc=openstack,dc=org> with scope subtree
>> # filter: (cn=ccc*)
>> # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*))
>> # with server side sorting control
>> #
>>
>> # search result
>> search: 2
>> result: 18 Inappropriate matching
>> text: serverSort control: No ordering rule
>
> This result is correct since the cn attribute has no ordering rule defined in
> the schema.
>>
>> # numResponses: 1
>>
>> caseIgnoreOrderingMatch ordering rule:
>>
>> ldapsearch -E sss=cn:caseIgnoreOrderingMatch '(cn=ccc*)' cn'
>> (&(objectClass=inetOrgPerson)(cn=ccc*))' -H ldap://IP:389 -b
>> "ou=Users,dc=openstack,dc=org" -D "c3D3Daaa1, ou=Users,dc=openstack,dc=org" -x
>> -W
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=Users,dc=openstack,dc=org> with scope subtree
>> # filter: (cn=ccc*)
>> # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*))
>> # with server side sorting control
>> #
>>
>> # ccc0, Users, openstack.org
>> dn: cn=ccc0,ou=Users,dc=openstack,dc=org
>> # search result
>> search: 2
>> result: 0 Success
>> control: 1.2.840.113556.1.4.474 false MAMKAQA=
>> sortResult: (0) Success
>>
>>
>> however the RFC states that the orderingRule is OPTIONAL as below:
>>
>> SortKeyList ::= SEQUENCE OF SEQUENCE {
>> attributeType AttributeDescription,
>> orderingRule [0] MatchingRuleId OPTIONAL,
>> reverseOrder [1] BOOLEAN DEFAULT FALSE }
>>
>> however openldap fails to return entries.
>
> The rule is optional in the control itself, but a valid ordering rule must
> exist somewhere. Since the attribute schema doesn't define one then you must
> provide one yourself.
>
> Closing this ITS.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 8 months
(ITS#8502) mdb_cursor_count() == EINVAL for empty DB
by h.b.furuseth@usit.uio.no
Full_Name: Hallvard B Furuseth
Version: mdb.master, 26e226b2a8cdba4208eabca394537900c4eda3b3
OS:
URL:
Submission from: (NULL) (81.191.45.31)
Submitted by: hallvard
mdb_cursor_count() has code to return MDB_NOTFOUND if !mc_snum,
but it comes after if (! ... C_INITIALIZED) return EINVAL.
6 years, 8 months
Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by mblagoeva@axway.com
--_000_AM4PR0101MB1954B05EC18907733774338FBBFE0AM4PR0101MB1954_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Howard,
And just one more follow-up question, if you do not mind, just to have the =
full picture. The way the RFC is construct, it seems that if the ordering r=
ule is omitted in the request one that is defined must be used, but if noth=
ing is defined in the schema nothing will be used, but I do not understand =
why the openlap will fail than. Exactly the same request works fine with Ac=
tiveDirectory server.
The quotes from the RFC directly:
The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD
be one that is valid for the attribute type it applies to. If it is
not, the server will return inappropriateMatching.
If the orderingRule is omitted, the ordering MatchingRule defined for
use with this attribute MUST be used.
Thanks again for your insights.
________________________________
From: Maria Blagoeva
Sent: Tuesday, September 13, 2016 8:50:45 AM
To: Howard Chu; openldap-its(a)OpenLDAP.org
Subject: Re: (ITS#8501) OpenLdap not RFC 2891 complaint
Hello Howard,
This means I need to patch the openldap instance or a default ordering rule=
can be set for that attribute on the fly? Thanks again for your help and a=
ssistance.
BR,
Maria
________________________________
From: Howard Chu <hyc(a)symas.com>
Sent: Monday, September 12, 2016 6:31:25 PM
To: Maria Blagoeva; openldap-its(a)OpenLDAP.org
Subject: Re: (ITS#8501) OpenLdap not RFC 2891 complaint
mblagoeva(a)axway.com wrote:
> Full_Name: Maria Blagoeva
> Version: openldap-2.4.31/debian/build/servers/slapd
> OS: docker image with 3.10.0-327.28.2.el7.x86_64
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (194.88.228.86)
>
>
> It seems that openldap as of 2.4.31 is not RFC complaint
> (https://www.ietf.org/rfc/rfc2891.txt) due to failure in response when or=
dering
> match rule is empty while doing server side sorting. Example below:
False. OpenLDAP is completely correct and RFC-compliant in its behavior.
> empty ordering rule:
>
> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgPerson)(=
cn=3Dccc*))' -H
> ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "cn=3Daaa1,
> ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W
> # extended LDIF
> #
> # LDAPv3
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree
> # filter: (cn=3Dccc*)
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))
> # with server side sorting control
> #
>
> # search result
> search: 2
> result: 18 Inappropriate matching
> text: serverSort control: No ordering rule
This result is correct since the cn attribute has no ordering rule defined =
in
the schema.
>
> # numResponses: 1
>
> caseIgnoreOrderingMatch ordering rule:
>
> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'
> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 -b
> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou=3DUsers,dc=3Dopens=
tack,dc=3Dorg" -x
> -W
> # extended LDIF
> #
> # LDAPv3
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree
> # filter: (cn=3Dccc*)
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))
> # with server side sorting control
> #
>
> # ccc0, Users, openstack.org
> dn: cn=3Dccc0,ou=3DUsers,dc=3Dopenstack,dc=3Dorg
> # search result
> search: 2
> result: 0 Success
> control: 1.2.840.113556.1.4.474 false MAMKAQA=3D
> sortResult: (0) Success
>
>
> however the RFC states that the orderingRule is OPTIONAL as below:
>
> SortKeyList ::=3D SEQUENCE OF SEQUENCE {
> attributeType AttributeDescription,
> orderingRule [0] MatchingRuleId OPTIONAL,
> reverseOrder [1] BOOLEAN DEFAULT FALSE }
>
> however openldap fails to return entries.
The rule is optional in the control itself, but a valid ordering rule must
exist somewhere. Since the attribute schema doesn't define one then you mus=
t
provide one yourself.
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--_000_AM4PR0101MB1954B05EC18907733774338FBBFE0AM4PR0101MB1954_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad=
ding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;back=
ground-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hello Howard,</p>
<p><br>
</p>
<p>And just one more follow-up question, if you do not mind, just to have t=
he full picture. The way the RFC is construct, it seems that if the orderin=
g rule is omitted in the request one that is defined must be used, but if n=
othing is defined in the schema
nothing will be used, but I do not understand why the openlap will fail th=
an. Exactly the same request works fine with ActiveDirectory server.
<br>
</p>
<p><br>
</p>
<p>The quotes from the RFC directly:</p>
<p><br>
</p>
<p></p>
<pre>The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD=0A=
be one that is valid for the attribute type it applies to. If it is=0A=
not, the server will return inappropriateMatching.</pre>
<p></p>
<p><br>
</p>
<p></p>
<pre> If the orderingRule is omitted, the ordering MatchingRule defined for=
=0A=
use with this attribute MUST be used.<br><br><span style=3D"font-family:=
Calibri,Arial,Helvetica,sans-serif;">Thanks again for your insights. </spa=
n></pre>
<br>
<p></p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Maria Blagoeva<br>
<b>Sent:</b> Tuesday, September 13, 2016 8:50:45 AM<br>
<b>To:</b> Howard Chu; openldap-its(a)OpenLDAP.org<br>
<b>Subject:</b> Re: (ITS#8501) OpenLdap not RFC 2891 complaint</font>
<div> </div>
</div>
<div>
<meta content=3D"text/html; charset=3DUTF-8">
<style type=3D"text/css" style=3D"">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir=3D"ltr">
<div id=3D"x_divtagdefaultwrapper" style=3D"font-size:12pt; color:#000000; =
background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hello Howard,</p>
<p><br>
</p>
<p>This means I need to patch the openldap instance or a default ordering r=
ule can be set for that attribute on the fly? Thanks again for your help an=
d assistance.</p>
<p><br>
</p>
<p>BR,</p>
<p>Maria<br>
</p>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Howard Chu <hyc@=
symas.com><br>
<b>Sent:</b> Monday, September 12, 2016 6:31:25 PM<br>
<b>To:</b> Maria Blagoeva; openldap-its(a)OpenLDAP.org<br>
<b>Subject:</b> Re: (ITS#8501) OpenLdap not RFC 2891 complaint</font>
<div> </div>
</div>
</div>
<font size=3D"2"><span style=3D"font-size:10pt;">
<div class=3D"PlainText">mblagoeva(a)axway.com wrote:<br>
> Full_Name: Maria Blagoeva<br>
> Version: openldap-2.4.31/debian/build/servers/slapd<br>
> OS: docker image with 3.10.0-327.28.2.el7.x86_64<br>
> URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o=
rg/incoming/</a><br>
> Submission from: (NULL) (194.88.228.86)<br>
><br>
><br>
> It seems that openldap as of 2.4.31 is not RFC complaint<br>
> (<a href=3D"https://www.ietf.org/rfc/rfc2891.txt">https://www.ietf.org=
/rfc/rfc2891.txt</a>) due to failure in response when ordering<br>
> match rule is empty while doing server side sorting. Example below:<br=
>
<br>
False. OpenLDAP is completely correct and RFC-compliant in its behavior.<br=
>
<br>
> empty ordering rule:<br>
><br>
> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgP=
erson)(cn=3Dccc*))' -H<br>
> ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D &qu=
ot;cn=3Daaa1,<br>
> ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W<br>
> # extended LDIF<br>
> #<br>
> # LDAPv3<br>
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b=
r>
> # filter: (cn=3Dccc*)<br>
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<br>
> # with server side sorting control<br>
> #<br>
><br>
> # search result<br>
> search: 2<br>
> result: 18 Inappropriate matching<br>
> text: serverSort control: No ordering rule<br>
<br>
This result is correct since the cn attribute has no ordering rule defined =
in <br>
the schema.<br>
><br>
> # numResponses: 1<br>
><br>
> caseIgnoreOrderingMatch ordering rule:<br>
><br>
> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'<br>
> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 -b<b=
r>
> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou=
=3DUsers,dc=3Dopenstack,dc=3Dorg" -x<br>
> -W<br>
> # extended LDIF<br>
> #<br>
> # LDAPv3<br>
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b=
r>
> # filter: (cn=3Dccc*)<br>
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<br>
> # with server side sorting control<br>
> #<br>
><br>
> # ccc0, Users, openstack.org<br>
> dn: cn=3Dccc0,ou=3DUsers,dc=3Dopenstack,dc=3Dorg<br>
> # search result<br>
> search: 2<br>
> result: 0 Success<br>
> control: 1.2.840.113556.1.4.474 false MAMKAQA=3D<br>
> sortResult: (0) Success<br>
><br>
><br>
> however the RFC states that the orderingRule is OPTIONAL as below:<br>
><br>
> SortKeyList ::=3D SEQUENCE OF SEQU=
ENCE {<br>
>  =
; attributeType AttributeDescript=
ion,<br>
>  =
; orderingRule [0] Matching=
RuleId OPTIONAL,<br>
>  =
; reverseOrder [1] BOOLEAN =
DEFAULT FALSE }<br>
><br>
> however openldap fails to return entries.<br>
<br>
The rule is optional in the control itself, but a valid ordering rule must =
<br>
exist somewhere. Since the attribute schema doesn't define one then you mus=
t <br>
provide one yourself.<br>
<br>
Closing this ITS.<br>
<br>
-- <br>
-- Howard Chu<br>
CTO, Symas Corp. &nbs=
p; <a href=3D"http://www.symas.com">http://www.symas.com</a><br=
>
Director, Highland Sun <a href=3D"http=
://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a><br>
Chief Architect, OpenLDAP <a href=3D"http://www.openldap=
.org/project/">http://www.openldap.org/project/</a><br>
</div>
</span></font></div>
</body>
</html>
--_000_AM4PR0101MB1954B05EC18907733774338FBBFE0AM4PR0101MB1954_--
6 years, 8 months
Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by mblagoeva@axway.com
--_000_AM4PR0101MB1954FD1169119D8DC1DD9008BBFE0AM4PR0101MB1954_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Howard,
This means I need to patch the openldap instance or a default ordering rule=
can be set for that attribute on the fly? Thanks again for your help and a=
ssistance.
BR,
Maria
________________________________
From: Howard Chu <hyc(a)symas.com>
Sent: Monday, September 12, 2016 6:31:25 PM
To: Maria Blagoeva; openldap-its(a)OpenLDAP.org
Subject: Re: (ITS#8501) OpenLdap not RFC 2891 complaint
mblagoeva(a)axway.com wrote:
> Full_Name: Maria Blagoeva
> Version: openldap-2.4.31/debian/build/servers/slapd
> OS: docker image with 3.10.0-327.28.2.el7.x86_64
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (194.88.228.86)
>
>
> It seems that openldap as of 2.4.31 is not RFC complaint
> (https://www.ietf.org/rfc/rfc2891.txt) due to failure in response when or=
dering
> match rule is empty while doing server side sorting. Example below:
False. OpenLDAP is completely correct and RFC-compliant in its behavior.
> empty ordering rule:
>
> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgPerson)(=
cn=3Dccc*))' -H
> ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "cn=3Daaa1,
> ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W
> # extended LDIF
> #
> # LDAPv3
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree
> # filter: (cn=3Dccc*)
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))
> # with server side sorting control
> #
>
> # search result
> search: 2
> result: 18 Inappropriate matching
> text: serverSort control: No ordering rule
This result is correct since the cn attribute has no ordering rule defined =
in
the schema.
>
> # numResponses: 1
>
> caseIgnoreOrderingMatch ordering rule:
>
> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'
> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 -b
> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou=3DUsers,dc=3Dopens=
tack,dc=3Dorg" -x
> -W
> # extended LDIF
> #
> # LDAPv3
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree
> # filter: (cn=3Dccc*)
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))
> # with server side sorting control
> #
>
> # ccc0, Users, openstack.org
> dn: cn=3Dccc0,ou=3DUsers,dc=3Dopenstack,dc=3Dorg
> # search result
> search: 2
> result: 0 Success
> control: 1.2.840.113556.1.4.474 false MAMKAQA=3D
> sortResult: (0) Success
>
>
> however the RFC states that the orderingRule is OPTIONAL as below:
>
> SortKeyList ::=3D SEQUENCE OF SEQUENCE {
> attributeType AttributeDescription,
> orderingRule [0] MatchingRuleId OPTIONAL,
> reverseOrder [1] BOOLEAN DEFAULT FALSE }
>
> however openldap fails to return entries.
The rule is optional in the control itself, but a valid ordering rule must
exist somewhere. Since the attribute schema doesn't define one then you mus=
t
provide one yourself.
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--_000_AM4PR0101MB1954FD1169119D8DC1DD9008BBFE0AM4PR0101MB1954_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad=
ding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content=3D"text/html; charset=3DUTF-8">
<style type=3D"text/css" style=3D"">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir=3D"ltr">
<div id=3D"x_divtagdefaultwrapper" style=3D"font-size:12pt; color:#000000; =
background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hello Howard,</p>
<p><br>
</p>
<p>This means I need to patch the openldap instance or a default ordering r=
ule can be set for that attribute on the fly? Thanks again for your help an=
d assistance.</p>
<p><br>
</p>
<p>BR,</p>
<p>Maria<br>
</p>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Howard Chu <hyc@=
symas.com><br>
<b>Sent:</b> Monday, September 12, 2016 6:31:25 PM<br>
<b>To:</b> Maria Blagoeva; openldap-its(a)OpenLDAP.org<br>
<b>Subject:</b> Re: (ITS#8501) OpenLdap not RFC 2891 complaint</font>
<div> </div>
</div>
</div>
<font size=3D"2"><span style=3D"font-size:10pt;">
<div class=3D"PlainText">mblagoeva(a)axway.com wrote:<br>
> Full_Name: Maria Blagoeva<br>
> Version: openldap-2.4.31/debian/build/servers/slapd<br>
> OS: docker image with 3.10.0-327.28.2.el7.x86_64<br>
> URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o=
rg/incoming/</a><br>
> Submission from: (NULL) (194.88.228.86)<br>
><br>
><br>
> It seems that openldap as of 2.4.31 is not RFC complaint<br>
> (<a href=3D"https://www.ietf.org/rfc/rfc2891.txt">https://www.ietf.org=
/rfc/rfc2891.txt</a>) due to failure in response when ordering<br>
> match rule is empty while doing server side sorting. Example below:<br=
>
<br>
False. OpenLDAP is completely correct and RFC-compliant in its behavior.<br=
>
<br>
> empty ordering rule:<br>
><br>
> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgP=
erson)(cn=3Dccc*))' -H<br>
> ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D &qu=
ot;cn=3Daaa1,<br>
> ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W<br>
> # extended LDIF<br>
> #<br>
> # LDAPv3<br>
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b=
r>
> # filter: (cn=3Dccc*)<br>
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<br>
> # with server side sorting control<br>
> #<br>
><br>
> # search result<br>
> search: 2<br>
> result: 18 Inappropriate matching<br>
> text: serverSort control: No ordering rule<br>
<br>
This result is correct since the cn attribute has no ordering rule defined =
in <br>
the schema.<br>
><br>
> # numResponses: 1<br>
><br>
> caseIgnoreOrderingMatch ordering rule:<br>
><br>
> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'<br>
> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 -b<b=
r>
> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou=
=3DUsers,dc=3Dopenstack,dc=3Dorg" -x<br>
> -W<br>
> # extended LDIF<br>
> #<br>
> # LDAPv3<br>
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b=
r>
> # filter: (cn=3Dccc*)<br>
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<br>
> # with server side sorting control<br>
> #<br>
><br>
> # ccc0, Users, openstack.org<br>
> dn: cn=3Dccc0,ou=3DUsers,dc=3Dopenstack,dc=3Dorg<br>
> # search result<br>
> search: 2<br>
> result: 0 Success<br>
> control: 1.2.840.113556.1.4.474 false MAMKAQA=3D<br>
> sortResult: (0) Success<br>
><br>
><br>
> however the RFC states that the orderingRule is OPTIONAL as below:<br>
><br>
> SortKeyList ::=3D SEQUENCE OF SEQU=
ENCE {<br>
>  =
; attributeType AttributeDescript=
ion,<br>
>  =
; orderingRule [0] Matching=
RuleId OPTIONAL,<br>
>  =
; reverseOrder [1] BOOLEAN =
DEFAULT FALSE }<br>
><br>
> however openldap fails to return entries.<br>
<br>
The rule is optional in the control itself, but a valid ordering rule must =
<br>
exist somewhere. Since the attribute schema doesn't define one then you mus=
t <br>
provide one yourself.<br>
<br>
Closing this ITS.<br>
<br>
-- <br>
-- Howard Chu<br>
CTO, Symas Corp. &nbs=
p; <a href=3D"http://www.symas.com">http://www.symas.com</a><br=
>
Director, Highland Sun <a href=3D"http=
://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a><br>
Chief Architect, OpenLDAP <a href=3D"http://www.openldap=
.org/project/">http://www.openldap.org/project/</a><br>
</div>
</span></font>
</body>
</html>
--_000_AM4PR0101MB1954FD1169119D8DC1DD9008BBFE0AM4PR0101MB1954_--
6 years, 8 months