openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8505) LMDB vs. fork()
by lmb＠cloudflare.com 28 Sep '16

28 Sep '16

I think your proposal is going beyond what I was trying to do. >From the documentation, it sounds like a process using LMDB can not safely fork, under any circumstances. My idea was to specialise this to saying that fork() followed immediately by exec() is safe, but that a plain fork() is still not supported. If a child wants to use the same db, it goes through the regular mdb_env_open sequence, rather than somehow inheriting the environment across the fork. I think that should address your pthread_exit concern, as well? On your point that a user may not call mdb_env_close before the fork: the user might not want to, since s/he still wants to use the env in the original process.

1 0

(ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by lmb＠cloudflare.com 27 Sep '16

27 Sep '16

On 26 September 2016 at 20:48, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > I think we can skip sigwait() too since the thread will exit when done. > Then any pending signals are presumably dropped. (I suppose some OS > could give them to another thread, but that goes against delivering > them to a particular thread like SIGPIPE is.) That's what my initial patch did. At least on OS X this leads to the process receiving SIGPIPE and dying. I can attach a test case as well if desired.

1 0

(ITS#8505) LMDB vs. fork()
by h.b.furuseth＠usit.uio.no 27 Sep '16

27 Sep '16

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.18 OS: Linux URL: Submission from: (NULL) (81.191.45.31) Submitted by: hallvard This is from openldap-tecnical thread "Using LMDB safely with fork() and exec()" by Lorenz Bauer: <http://www.openldap.org/lists/openldap-technical/201608/msg00062.html> ==== The doc is too restrictive, it implicitly suggests an LMDB process can't fork another LDMB process (since the old LMDB would still be open). We should document the use of FD_CLOEXEC etc. ==== This breaks LMDB: if (fork() == 0) pthread_exit(NULL); because the child's me_txkey destructor releases the reader slot. This can happen if a single-threaded LMDB process forks a multi- threaded child, which is one way to deal with threads vs. fork(). Simplest fix: Check if (reader->mr_pid == getpid()) in reader_dest(). We could instead use pthread_atfork(), but there is not way to remove an atfork handler. It seems to be implementation-dependent what happens with an atfork handler if liblmdb is dynamically unloaded. ==== LMDB leaks file descriptors to a fork() child, since the user may not call mdb_env_close() and there is no way to get at some of the descriptors. Partial fix: Set FD_CLOEXEC for me_mfd and the mdb_env_copy() FD. Should I code up an mdb_env_child_cleanup() function which may be called in the child if it does not fork()? That makes sense either if the parent is single-threaded and forks a more complex child, or if the child is fairly simple. ==== Branch "mdb/fopen2" in my repo will soon include suggested fixes, except mdb_env_child_cleanup(). (Fixed version of older "mdb/fopen")

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by h.b.furuseth＠usit.uio.no 27 Sep '16

27 Sep '16

On 25/09/16 20:16, lmb(a)cloudflare.com wrote: > * Do not check for pending SIGPIPE: since this is a new thread there can't > be any I think we can skip sigwait() too since the thread will exit when done. Then any pending signals are presumably dropped. (I suppose some OS could give them to another thread, but that goes against delivering them to a particular thread like SIGPIPE is.)

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by lmb＠cloudflare.com 25 Sep '16

25 Sep '16

--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"> </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"> </div><div class=3D"gmail_extra">The URL stays the same.</div></= div> --94eb2c07d07472c185053d5903fe--

1 0

(ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by lmb＠cloudflare.com 24 Sep '16

24 Sep '16

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

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by h.b.furuseth＠usit.uio.no 17 Sep '16

17 Sep '16

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

1 0

(ITS#8503) Provide proper soname to liblmdb.so.1
by gahr＠gahr.ch 16 Sep '16

16 Sep '16

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

1 0

Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by mblagoeva＠axway.com 14 Sep '16

14 Sep '16

--_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"> <style></style> </head> <body> <meta content=3D"text/html; charset=3DUTF-8"> <style type=3D"text/css" style=3D"">  </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"> Hello Howard, Thanks again. This strangely enough works with 2.4.40 version , previous= ly I was using 2.4.31. </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"x_divRplyFwdMsg" dir=3D"ltr">From: Howard Chu <hyc@= 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 <div> </div> </div> </div> <div class=3D"PlainText">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 order= ing rule > is omitted in the request one that is defined must be used, but if not= hing is > defined in the schema nothing will be used, but I do not understand wh= y 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<br= > >    be one that is valid for the attribute type it appli= es to.  If it is >    not, the server will return inappropriateMatching.<b= r> >  If the orderingRule is omitted, the ordering MatchingRule define= d 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 a= nd > 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: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openld= ap.org/incoming/</a> >> Submission from: (NULL) (194.88.228.86) >> >> >> It seems that openldap as of 2.4.31 is not RFC complaint >> (<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 >> match rule is empty while doing server side sorting. Example below= : > > False. OpenLDAP is completely correct and RFC-compliant in its behavio= r. > >> empty ordering rule: >> >> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3Dinet= OrgPerson)(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 subtr= ee >> # filter: (cn=3Dccc*) >> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<b= r> >> # 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 def= ined in > the schema. >> >> # numResponses: 1 >> >> caseIgnoreOrderingMatch ordering rule: >> >> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'<b= r> >> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 = -b >> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1,= ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x >> -W >> # extended LDIF >> # >> # LDAPv3 >> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtr= ee >> # filter: (cn=3Dccc*) >> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<b= r> >> # 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 { >>           &= nbsp;      attributeType   AttributeDesc= ription, >>           &= nbsp;      orderingRule    [0] Matc= hingRuleId OPTIONAL, >>           &= nbsp;      reverseOrder    [1] BOOL= EAN 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 yo= u must > provide one yourself. > > Closing this ITS. > > -- >    -- Howard Chu >    CTO, Symas Corp.      =      <a href=3D"http://www.symas.com">http://www.symas.= com</a> >    Director, Highland Sun     <a hr= ef=3D"http://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a> >    Chief Architect, OpenLDAP  <a href=3D"http://ww= w.openldap.org/project/">http://www.openldap.org/project/</a> --    -- Howard Chu    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>    Chief Architect, OpenLDAP  <a href=3D"http://www.openldap= .org/project/">http://www.openldap.org/project/</a> </div> </body> </html> --_000_AM4PR0101MB19549BBC7F2AB2947F4C5505BBF10AM4PR0101MB1954_--

1 0

Re: (ITS#8490) changes not written to accesslog, causing replicas to loop syncing
by quanah＠zimbra.com 13 Sep '16

13 Sep '16

--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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs