- openldap-bugs - openldap.org

Bug in Proxy mode..
by K C, Sachin (Sachin) 26 Feb '08

26 Feb '08

OpenLDAP Team, Seems to be a bug in OpenLDAP 2.4.8 configured in Proxy mode with --enable-ldap and --enable-rewrite The proxy config is database ldap suffix "o=<O>" # List of proxy servers delimited by space # uri <Server List> uri "ldap://<Main>:<port>/ ldap://<Secondary>:<port>/" When the "Main" was running, all requests were passed onto Main. I brought it down and saw that the requests were sent to "Secondary" server. After sometime, I brought the Main server back to live simulating a recovery from crash. The requests were still redirected to "Secondary" despite the "Main" server being accessible. I brought down the "Secondary" server and the requests were directed to Main server.!! Is this the correct behaviour? ( I believe that the server in the head of the list should be contacted everytime a request comes to proxy! ) ThanX Sachin

2 1

Re: (ITS#5391) hdb deadlock
by hyc＠symas.com 26 Feb '08

26 Feb '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > One hdb backend on one slave died ~21:58 yesterday... > > current thread: t@5 > [1] _libc_poll(0xffffffff4f3ff430, 0x0, 0x3e8, 0x0, 0x0, 0x0), at > 0xffffffff7f0a741c > [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, > 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c > [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff4f3ff5b0, 0x0), at > 0xffffffff7e0108e8 > =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in > "os_sleep.c" > [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = > DB_SYNC_CACHE, wrotep = (nil)), line 362 in "mp_sync.c" > [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" > [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1389 in "txn.c" > [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1288 in "txn.c" > [9] hdb_checkpoint(ctx = 0xffffffff4f3ffc30, arg = 0x1004b4c60), line 165 in > "config.c" > [10] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" > > (dbx) where > current thread: t@16 > [1] _libc_poll(0xffffffff46ffe3e0, 0x0, 0x3e8, 0x0, 0x0, 0x0), at > 0xffffffff7f0a741c > [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, > 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c > [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff46ffe560, 0x0), at > 0xffffffff7e0108e8 > =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in > "os_sleep.c" > [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = > DB_SYNC_CACHE, wrotep = (nil)), line 439 in "mp_sync.c" > [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" > [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1389 in "txn.c" > [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1288 in "txn.c" > [9] hdb_delete(op = 0xffffffff46fff618, rs = 0xffffffff46fff088), line 537 in > "delete.c" > [10] syncrepl_entry(si = 0x1004b4e50, op = 0xffffffff46fff618, entry = (nil), > modlist = 0xffffffff46fff320, syncstate = 3, syncUUID = 0xffffffff46fff3c0, > syncCookie_req = 0xffffffff46fff360, syncCSN = > 0xffffffff46fff390), line 2006 in "syncrepl.c" > [11] do_syncrep2(op = 0xffffffff46fff618, si = 0x1004b4e50), line 731 in > "syncrepl.c" > [12] do_syncrepl(ctx = 0xffffffff46fffc30, arg = 0x1004b5030), line 1095 in > "syncrepl.c" > [13] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" > > > I can't get db_stat to join the environment. If there's anything else that can > be gleaned from slapd itself, I'd be glad to poke around the core; otherwise, > I'm off to rm/slapadd... > > "This makes sense and shouldn't happen in 2.3.41" would be fine too, but none of > the changes (to my eye) looked locking related. Unfortunately no, nothing familiar here. There's nothing in the BDB documentation that says two threads are not allowed to call txn_checkpoint concurrently, but I suppose it may be excessive to make multiple calls in rapid succession. One thing that I've started doing recently in my configs is to skip the #bytes option (leave it zero), so that only time-based checkpoints occur. Since they're done in a dedicated task, only one thread at a time can trigger a checkpoint. -- -- 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 0

(ITS#5391) hdb deadlock
by richton＠nbcs.rutgers.edu 26 Feb '08

26 Feb '08

Full_Name: Aaron Richton Version: 2.3.40 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) One hdb backend on one slave died ~21:58 yesterday... current thread: t@5 [1] _libc_poll(0xffffffff4f3ff430, 0x0, 0x3e8, 0x0, 0x0, 0x0), at 0xffffffff7f0a741c [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff4f3ff5b0, 0x0), at 0xffffffff7e0108e8 =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in "os_sleep.c" [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = DB_SYNC_CACHE, wrotep = (nil)), line 362 in "mp_sync.c" [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1389 in "txn.c" [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1288 in "txn.c" [9] hdb_checkpoint(ctx = 0xffffffff4f3ffc30, arg = 0x1004b4c60), line 165 in "config.c" [10] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" (dbx) where current thread: t@16 [1] _libc_poll(0xffffffff46ffe3e0, 0x0, 0x3e8, 0x0, 0x0, 0x0), at 0xffffffff7f0a741c [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff46ffe560, 0x0), at 0xffffffff7e0108e8 =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in "os_sleep.c" [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = DB_SYNC_CACHE, wrotep = (nil)), line 439 in "mp_sync.c" [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1389 in "txn.c" [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1288 in "txn.c" [9] hdb_delete(op = 0xffffffff46fff618, rs = 0xffffffff46fff088), line 537 in "delete.c" [10] syncrepl_entry(si = 0x1004b4e50, op = 0xffffffff46fff618, entry = (nil), modlist = 0xffffffff46fff320, syncstate = 3, syncUUID = 0xffffffff46fff3c0, syncCookie_req = 0xffffffff46fff360, syncCSN = 0xffffffff46fff390), line 2006 in "syncrepl.c" [11] do_syncrep2(op = 0xffffffff46fff618, si = 0x1004b4e50), line 731 in "syncrepl.c" [12] do_syncrepl(ctx = 0xffffffff46fffc30, arg = 0x1004b5030), line 1095 in "syncrepl.c" [13] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" I can't get db_stat to join the environment. If there's anything else that can be gleaned from slapd itself, I'd be glad to poke around the core; otherwise, I'm off to rm/slapadd... "This makes sense and shouldn't happen in 2.3.41" would be fine too, but none of the changes (to my eye) looked locking related.

1 0

Re: (ITS#5390) Error while parsing a schema
by elecharny＠gmail.com 26 Feb '08

26 Feb '08

Howard Chu wrote: > Emmanuel Lecharny wrote: >> Howard Chu wrote: >>> There's no bug here, and the schema parser isn't causing your problem. >>> As documented in slapd.conf(5), directives must form a single logical >>> line. Lines that are split must be continued by a leading space >>> character. > >> Assuming this is not a bug, this is still really painfull... It would be >> much better to consider that the AttributeType, being parenthesed, can >> be scanned without taking into account the leading white space, until >> the closing ')'. > > The config file parser breaks the input into lines before scanning to > see what keywords are actually on those lines. The syntax of the > config file has been documented to behave this way for over 10 years. > Nobody else has cared to change it until now... FYI, before having RTFM, I thought that the only possible "include" I can use was for schema file. It made sense to me then that OpenLDAP was using a specific parser for schema, but I was wrong. It seems that I have missed the part of the doc where this 'first space requirement' is mentionned... We were lucky enough in ADS to be able to use a contextfull parser for those schema file (we support the same format), so we were able to relax this constraint. Supposing that ADS behavior is to be expected by OpenLDAP is obviously a mistake ... I wish I have some time to provide some patch for OpenLDAP to relax such a constraint, but, eh, if I say so, that would be a damn lie ! > > Of course, all of that is going to be phased out as we move to pure > LDIF in the future. (Which again, requires a leading space character > for line continuations. And again, is a well documented feature of the > format.) Yeah, the problem will remain, but at least, there is a RFC for idiot like me who don't do their homeworks... The *big* advantage to have LDIF formatted schemas is that you won't have anymore to care about ordering the elements inside attributeTypes and objectClasses... Btw, we do have some LDIF format for Shcema, and I was wondering if it won't be a good idea to try to define a common format ? I would really appreciate if a LDIF schema file could be directly injected in both ADS and OpenLDAP ! Thanks. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org

1 0

Re: (ITS#5390) Error while parsing a schema
by hyc＠symas.com 26 Feb '08

26 Feb '08

Emmanuel Lecharny wrote: > Howard Chu wrote: >> There's no bug here, and the schema parser isn't causing your problem. >> As documented in slapd.conf(5), directives must form a single logical >> line. Lines that are split must be continued by a leading space >> character. > Assuming this is not a bug, this is still really painfull... It would be > much better to consider that the AttributeType, being parenthesed, can > be scanned without taking into account the leading white space, until > the closing ')'. The config file parser breaks the input into lines before scanning to see what keywords are actually on those lines. The syntax of the config file has been documented to behave this way for over 10 years. Nobody else has cared to change it until now... Of course, all of that is going to be phased out as we move to pure LDIF in the future. (Which again, requires a leading space character for line continuations. And again, is a well documented feature of the format.) > That being said, as soon as I have fixed the schema file, I'm not > suffering anymore. I was just thinking about the poor other users ;) > > Thanks Howard ! You're welcome ;) -- -- 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 0

Re: (ITS#5390) Error while parsing a schema
by elecharny＠gmail.com 26 Feb '08

26 Feb '08

Howard Chu wrote: > There's no bug here, and the schema parser isn't causing your problem. > As documented in slapd.conf(5), directives must form a single logical > line. Lines that are split must be continued by a leading space > character. Assuming this is not a bug, this is still really painfull... It would be much better to consider that the AttributeType, being parenthesed, can be scanned without taking into account the leading white space, until the closing ')'. That being said, as soon as I have fixed the schema file, I'm not suffering anymore. I was just thinking about the poor other users ;) Thanks Howard ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org

1 0

Re: (ITS#5390) Error while parsing a schema
by hyc＠symas.com 26 Feb '08

26 Feb '08

There's no bug here, and the schema parser isn't causing your problem. As documented in slapd.conf(5), directives must form a single logical line. Lines that are split must be continued by a leading space character. elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.3.39 (stable) > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.245.116.110) > > > Trying to load a schema, I got an error because the schema parser is expecting a > WSP before the closing parenthese. Here is the attributeType : > > attributetype ( 1.3.6.1.4.1.30267.0.1 > NAME 'ApplicationName' > SUP name > EQUALITY caseIgnoreMatch > ORDERING caseIgnoreOrderingMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > SINGLE-VALUE > ) > ^ > | > +--- note that there is no space here. > > If I add a spece before the ')', the schema is parsed correctly. > > This is breaking RFC 4512 : This has nothing to do with RFC 4512. -- -- 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 0

(ITS#5390) Error while parsing a schema
by elecharny＠apache.org 26 Feb '08

26 Feb '08

Full_Name: Emmanuel Lecharny Version: 2.3.39 (stable) OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.245.116.110) Trying to load a schema, I got an error because the schema parser is expecting a WSP before the closing parenthese. Here is the attributeType : attributetype ( 1.3.6.1.4.1.30267.0.1 NAME 'ApplicationName' SUP name EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ^ | +--- note that there is no space here. If I add a spece before the ')', the schema is parsed correctly. This is breaking RFC 4512 : WSP = 0*SPACE ; zero or more " " AttributeTypeDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "SUP" SP oid ] ; supertype [ SP "EQUALITY" SP oid ] ; equality matching rule [ SP "ORDERING" SP oid ] ; ordering matching rule [ SP "SUBSTR" SP oid ] ; substrings matching rule [ SP "SYNTAX" SP noidlen ] ; value syntax [ SP "SINGLE-VALUE" ] ; single-value [ SP "COLLECTIVE" ] ; collective [ SP "NO-USER-MODIFICATION" ] ; not user modifiable [ SP "USAGE" SP usage ] ; usage extensions WSP RPAREN ; extensions The main problem with this kind of parsing error is that some users may spent _hours_ finding out what's going on... I just spoilt one full hour myself :/ Also the logs are not really self-explanatory... : ... AttributeTypeDescription = "(" whsp numericoid whsp ; AttributeType identifier [ "NAME" qdescrs ] ; name used in AttributeType [ "DESC" qdstring ] ; description [ "OBSOLETE" whsp ] [ "SUP" woid ] ; derived from this other ; AttributeType [ "EQUALITY" woid ] ; Matching Rule name [ "ORDERING" woid ] ; Matching Rule name [ "SUBSTR" woid ] ; Matching Rule name [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 [ "SINGLE-VALUE" whsp ] ; default multi-valued [ "COLLECTIVE" whsp ] ; default not collective [ "NO-USER-MODIFICATION" whsp ]; default user modifiable [ "USAGE" whsp AttributeUsage ]; default userApplications ; userApplications ; directoryOperation ; distributedOperation ; dSAOperation whsp ")" /opt/ldap/openldap/etc/openldap/schema/sofinco.schema: line 13: <attributetype> handler exited with 1! ...

1 0

(ITS#5389) Contribution: JLDAP support for password policy response control
by t2tre＠skyblue.eu.com 25 Feb '08

25 Feb '08

Full_Name: Raymond Edah Version: JLDAP CVS HEAD OS: Windows URL: http://www.cs.skyblue.eu.com/ray/code/LDAPPasswordPolicyResponse.tar.gz Submission from: (NULL) (81.3.106.202) Hi, I have written a class for handling the password policy response control as described in draft-behera-ldap-password-policy-09.txt. I would like to contribute it to the OpenLDAP project. A copy of the code can be found at http://www.cs.skyblue.eu.com/ray/code/LDAPPasswordPolicyResponse.tar.gz. Regards, Ray Edah

1 0

(ITS#5388) NULL pointer dereference
by dhen42＠yahoo.co.uk 25 Feb '08

25 Feb '08

Full_Name: Dennis Henriksen Version: 2.4.8 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.10) In server/slapd/oc.c(oc_next) suffers from a potential NULL pointer dereference in the statement '*oc = LDAP_STAILQ_NEXT(*oc,soc_next);'. Perhaps this should read (if *oc != NULL) *oc = LDAP_STAILQ_NEXT(*oc,soc_next);'

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by jclarke＠linagora.com 25 Feb '08

25 Feb '08

h.b.furuseth(a)usit.uio.no a écrit : > jclarke(a)linagora.com writes: >> When slapcat is writing it's output to disk, it ignores any errors >> (with slapcat -l output_file or slapcat > output_file). If an error is >> encountered, such as "No space left on device", slapcat then exits >> normally with a return code of 0. > > Eh. API design bug. ldif_tool_entry_first()/ldif_tool_entry_next() > have no way to return error. At best they can set an "error" flag > in the internal database structure, and API calls which are able > to return errors can react to that. Hmmm. I may have misunderstood, but it seems this concerns internal errors, whereas I was referring to the output (writing the data to stdout or to a file) errors. The patch I attached addresses this issue, is there any chance of seeing it included in OpenLDAP, or does it need some more work? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by h.b.furuseth＠usit.uio.no 20 Feb '08

20 Feb '08

jclarke(a)linagora.com writes: > When slapcat is writing it's output to disk, it ignores any errors > (with slapcat -l output_file or slapcat > output_file). If an error is > encountered, such as "No space left on device", slapcat then exits > normally with a return code of 0. Eh. API design bug. ldif_tool_entry_first()/ldif_tool_entry_next() have no way to return error. At best they can set an "error" flag in the internal database structure, and API calls which are able to return errors can react to that. -- Hallvard

1 0

(ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by jclarke＠linagora.com 20 Feb '08

20 Feb '08

Full_Name: Jonathan Clarke Version: 2.3, HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-20080220.patch.3 Submission from: (NULL) (213.41.243.192) Hi all, When slapcat is writing it's output to disk, it ignores any errors (with slapcat -l output_file or slapcat > output_file). If an error is encountered, such as "No space left on device", slapcat then exits normally with a return code of 0. This seems pretty dangerous to me - if you back up your database with slapcat, but don't get an error on failure, it could easily lead to data loss. Please find at the address below a patch to stop on such errors. It may require some cleaning up - apologies if so. Regards, Jonathan

1 0

Re: ITS#5375
by quanah＠zimbra.com 19 Feb '08

19 Feb '08

I suggest you download and build OpenLDAP 2.4.8. ;) <http://www.openldap.org/software/download/> --Quanah --On Monday, February 18, 2008 12:10 PM +0000 ecizaguirre(a)gmv.com wrote: > > Hi again Pierangelo and Quanah, I have tested the REL_ENG_2_4 version > with the fix under heavy worload and it seems to be working correctly so > the problem is fixed. > > I'm still not able to compile 2.4.7 version with the fix applied. > > Thanks for all and for this great software. > > Cheers. > > Eduardo > > ______________________ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, > puede contener informacion clasificada por su emisor como confidencial > en el marco de su Sistema de Gestion de Seguridad de la > Informacion siendo para uso exclusivo del destinatario, quedando > prohibida su divulgacion copia o distribucion a terceros sin la > autorizacion expresa del remitente. Si Vd. ha recibido este mensaje > erroneamente, se ruega lo notifique al remitente y proceda a su borrado. > Gracias por su colaboracion. > ______________________ > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are addressed. > Any unauthorised copy, disclosure or distribution of this message > is strictly forbidden. If you have received this transmission in error, > please notify the sender immediately and delete it. > ______________________ > > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: [JunkMail] Re: (ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com 19 Feb '08

19 Feb '08

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> In RE24 the config schema are only exposed for DEVEL builds. >> >> Why that? Especially why was it changed compared to RE23? > > They were probably exposed in RE23 by mistake. Another option would be to completely disable the subschema subentry for back-config. In this case users of web2ldap could work around it by using a locally stored schema LDIF file for back-config. Ciao, Michael.

1 0

Re: (ITS#5386) Bad value of entryUUID in filter crashes slapd
by ando＠sys-net.it 18 Feb '08

18 Feb '08

silk(a)boktor.net wrote: > If client sends a filter that lookups entries based on entryUUID, and the value > of entryUUID is invalid (eg. not properly formed) slapd dies with an assertion. Fixed in HEAD (servers/slapd/filter.c 1.148->1.149) Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5385) contextCSN not propagated in cascading syncrepl refreshAndPersist
by hyc＠symas.com 18 Feb '08

18 Feb '08

bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: OPENLDAP_REL_ENG_2_3 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.15.129.131) > > > One of our environments does cascading replication of one database (the master > for the other databases in this environment is a syncrepl refreshAndPersist > syncrepl client to a database in another environment). > > We monitor the replication status of all our slaves by comparing the contextCSN > on each database with the contextCSN of the updateref, and I have noticed that > the contextCSN on the cascaded replicas is not being updated, even though the > entries have been replicated (according to logging at sync level on these > slaves). All other replication (including non-cascaded refreshAndPersist > databases) works fine. All the servers in question are currently on 2.3.40. > > It seems that the issue can be reproduced with current REL_ENG_2_3, with a > slight modification to test019 (see patch below) to include the contextCSN in > the comparison, which will then fail as follows: I've reproduced this issue in RE23 as well. I note that there's no such problem with RE24. If we can't track this down easily I'm inclined to just ignore it. -- -- 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 0

(ITS#5386) Bad value of entryUUID in filter crashes slapd
by silk＠boktor.net 18 Feb '08

18 Feb '08

Full_Name: Grzegorz Sobanski Version: 2.4.7(-5) OS: Debain unstable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (150.254.130.134) If client sends a filter that lookups entries based on entryUUID, and the value of entryUUID is invalid (eg. not properly formed) slapd dies with an assertion. Example filter: (entryUUID=baka) Steps to reproduce: ldapsearch -x "(entryUUID=baka)" Reproducible: always Error logged by slapd: slapd: /home/devel/openldap/build-area/openldap2.3-2.4.7/servers/slapd/schema_init.c:2537: UUIDNormalize: Assertion `val->bv_len == 16' failed. Expected behaviour: Server does not dies, and: - backwards compatible: filter on entryUUID is skipped - not backward compatible: client is informed about malformed search filter If any more information or tests are needed, please ask.

1 0

ITS#5375
by ecizaguirre＠gmv.com 18 Feb '08

18 Feb '08

Hi again Pierangelo and Quanah, I have tested the REL_ENG_2_4 version with the fix under heavy worload and it seems to be working correctly so the problem is fixed. I'm still not able to compile 2.4.7 version with the fix applied. Thanks for all and for this great software. Cheers. Eduardo ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

Re: (ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com 18 Feb '08

18 Feb '08

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> In RE24 the config schema are only exposed for DEVEL builds. >> >> Why that? Especially why was it changed compared to RE23? > > They were probably exposed in RE23 by mistake. The config schema uses an > OID from the OpenLDAP Experimental arc and the Project's policy is not > to publish experimental OIDs for general use, only for Development. But then back-config SHOULD be hidden by DEVEL as well. Frankly no-one will ever recognize when you change an OID arc. There would be no issues with LDAP clients at all. > Given that things in cn=config have pretty much stabilized, we probably > ought to have migrated to a non-experimental arc for RE24. Yes, please. Given that back-config is endorsed to be deployed in production schema-aware LDAP clients must have the chance to retrieve required information for processing the data. > Note that the cn=config schema still relies on an unfinished spec > (draft-chu-ldap-xordered) and that needs to be finalized still. Whatever "unfinished" means. From the IETF point-of-view this is simply a proprietary feature not documented anywhere in the IETF process so far. From OpenLDAP project point-of-view it is yet another not fully documented feature. This is not a real issue which should hold back providing the schema to the client. But if back-config is activated in normal builds then the interface definition SHOULD be complete which includes providing the relevant schema information in subschema subentry. Ciao, Michael.

1 0

(ITS#5385) contextCSN not propagated in cascading syncrepl refreshAndPersist
by bgmilne＠staff.telkomsa.net 18 Feb '08

18 Feb '08

Full_Name: Buchan Milne Version: OPENLDAP_REL_ENG_2_3 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.15.129.131) One of our environments does cascading replication of one database (the master for the other databases in this environment is a syncrepl refreshAndPersist syncrepl client to a database in another environment). We monitor the replication status of all our slaves by comparing the contextCSN on each database with the contextCSN of the updateref, and I have noticed that the contextCSN on the cascaded replicas is not being updated, even though the entries have been replicated (according to logging at sync level on these slaves). All other replication (including non-cascaded refreshAndPersist databases) works fine. All the servers in question are currently on 2.3.40. It seems that the issue can be reproduced with current REL_ENG_2_3, with a slight modification to test019 (see patch below) to include the contextCSN in the comparison, which will then fail as follows: $ ./run test019 Running ./scripts/test019-syncreplication-cascade... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd (pid=23363) is running... Using ldapadd to create the context prefix entry in the master... Starting R1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that R1 slave slapd (pid=23370) is running... Starting R2 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R2 slave slapd (pid=23376) is running... Starting P1 slave slapd on TCP/IP port 9014... Using ldapsearch to check that P1 slave slapd (pid=23382) is running... Starting P2 slave slapd on TCP/IP port 9015... Using ldapsearch to check that P2 slave slapd (pid=23388) is running... Starting P3 slave slapd on TCP/IP port 9016... Using ldapsearch to check that P3 slave slapd (pid=23395) is running... Using ldapadd to populate the master directory... Waiting 25 seconds for syncrepl to receive changes... Using ldapmodify to modify master directory... Waiting 25 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the master... Using ldapsearch to read all the entries from the R1 slave... Using ldapsearch to read all the entries from the R2 slave... Using ldapsearch to read all the entries from the P1 slave... Using ldapsearch to read all the entries from the P2 slave... Using ldapsearch to read all the entries from the P3 slave... Filtering master ldapsearch results... Filtering R1 slave ldapsearch results... Filtering R2 slave ldapsearch results... Filtering P1 slave ldapsearch results... Filtering P2 slave ldapsearch results... Filtering P3 slave ldapsearch results... Comparing retrieved entries from master and R1 slave... Comparing retrieved entries from master and R2 slave... Comparing retrieved entries from master and P1 slave... Comparing retrieved entries from master and P2 slave... test failed - master and P2 slave databases differ $ diff -u testrun/server{1,5}.flt --- testrun/server1.flt 2008-02-18 12:00:52.000000000 +0200 +++ testrun/server5.flt 2008-02-18 12:00:52.000000000 +0200 @@ -108,7 +108,7 @@ postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US telephoneNumber: +1 313 555 1817 associatedDomain: example.com -contextCSN: 20080218100027Z#000002#00#000000 +contextCSN: 20080218100027Z#000000#00#000000 dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc= com Index: scripts/test019-syncreplication-cascade =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/tests/scripts/test019-syncreplication-cascade,v retrieving revision 1.13.2.7 diff -u -r1.13.2.7 test019-syncreplication-cascade --- scripts/test019-syncreplication-cascade 11 Feb 2008 23:24:28 -0000 1.13.2.7 +++ scripts/test019-syncreplication-cascade 18 Feb 2008 10:02:51 -0000 @@ -331,7 +331,7 @@ echo "Using ldapsearch to read all the entries from the master..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT1 \ - 'objectclass=*' > $MASTEROUT 2>&1 + 'objectclass=*' '*' contextCSN > $MASTEROUT 2>&1 RC=$? if test $RC != 0 ; then @@ -342,7 +342,7 @@ echo "Using ldapsearch to read all the entries from the R1 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \ - 'objectclass=*' > $SERVER2OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER2OUT 2>&1 RC=$? if test $RC != 0 ; then @@ -353,7 +353,7 @@ echo "Using ldapsearch to read all the entries from the R2 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT3 \ - 'objectclass=*' > $SERVER3OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER3OUT 2>&1 RC=$? if test $RC != 0 ; then @@ -364,7 +364,7 @@ echo "Using ldapsearch to read all the entries from the P1 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT4 \ - 'objectclass=*' > $SERVER4OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER4OUT 2>&1 RC=$? if test $RC != 0 ; then @@ -375,7 +375,7 @@ echo "Using ldapsearch to read all the entries from the P2 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT5 \ - 'objectclass=*' > $SERVER5OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER5OUT 2>&1 RC=$? if test $RC != 0 ; then @@ -386,7 +386,7 @@ echo "Using ldapsearch to read all the entries from the P3 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT6 \ - 'objectclass=*' > $SERVER6OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER6OUT 2>&1 RC=$? if test $RC != 0 ; then

1 0

Re: [JunkMail] Re: (ITS#5383) olc* not present in subschema subentry
by hyc＠symas.com 17 Feb '08

17 Feb '08

Michael Ströder wrote: > Howard Chu wrote: >> In RE24 the config schema are only exposed for DEVEL builds. > > Why that? Especially why was it changed compared to RE23? They were probably exposed in RE23 by mistake. The config schema uses an OID from the OpenLDAP Experimental arc and the Project's policy is not to publish experimental OIDs for general use, only for Development. Given that things in cn=config have pretty much stabilized, we probably ought to have migrated to a non-experimental arc for RE24. I suppose we can take this ITS as a reminder to do that. Note that the cn=config schema still relies on an unfinished spec (draft-chu-ldap-xordered) and that needs to be finalized still. -- -- 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 0

(ITS#5384) access control: "attrs" field handled incorrectly in URI form of sets
by ando＠sys-net.it 17 Feb '08

17 Feb '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando There seems to be an error in (optional) attribute handling in URIs used in sets. Background: in OpenLDAP 2.3 sets were enhanced by allowing to dereference URIs by performing the corresponding internal search; the syntax was: [<uri>]/<attr> returning the value of <attr> after searching for <uri>; if optional attrs were specified in the URI, their values could be added to the result set; so [ldap:///o=suffix?cn,sn?sub]/uid would have collected the "cn", the "sn" and the "uid" of entries matching the URI. Well, this is broken: it seems to only work as expected when no optional attrs are given. A fix for HEAD is about to come. p.

1 0

Re: (ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com 17 Feb '08

17 Feb '08

Howard Chu wrote: > > In RE24 the config schema are only exposed for DEVEL builds. Why that? Especially why was it changed compared to RE23? Ciao, Michael.

1 0

Re: (ITS#5383) olc* not present in subschema subentry
by hyc＠symas.com 17 Feb '08

17 Feb '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: OpenSUSE Linux 10.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.120.38) > > > IMO a show-stopper for 2.4.8! > > The schema elements for back-config (olc*) are not present/readable in the > subschema subentry. They are present with the very same config in RE23. Note > that the schema elements have to be retrieved by schema-aware clients for doing > the right thing... In RE24 the config schema are only exposed for DEVEL builds. This is not a regression from 2.4.7 or any other 2.4 releases, so this is certainly not a show-stopper. -- -- 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 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs