openldap-bugs February 2008

openldap-bugs@openldap.org

42 participants
207 discussions

(ITS#5393) syncrepl push based replication with back-ldap fails
by emmanuel.duru＠atosorigin.com 27 Feb '08

27 Feb '08

Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) I'm trying to set a directory architecture with a syncrepl push based replication, as (partly) stated in the admin guide, chapter 16.1.1. I have a provider slapd with bdb, an intermediate slapd with back-ldap, which points to a consumer slapd with bdb. First, I have to set an updateDN on the consumer slapd, else back-ldap gets a "no user modification allowed" error on operational attributes (structuralobjectclass, contextcsn) when it tries to update the consumer slapd (the admin guide says the opposite). Then this does not work at all when modifying an entry, because back-ldap gets a "modify/delete: hasSubordinates: no such attribute" error when it tries to update the entry.

1 0

(ITS#5392) Some traces are lost
by emmanuel.duru＠atosorigin.com 27 Feb '08

27 Feb '08

Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) Traces related to connections are not logged on file (either default file, or specified file). Examples of traces which are not logged : conn=0 fd=2160 ACCEPT from IP=127.0.0.1:1299 (IP=0.0.0.0:4800) conn=0 op=0 BIND dn="cn=manager,c=fr" method=128 conn=0 op=0 BIND dn="cn=manager,c=fr" mech=SIMPLE ssf=0 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 SRCH base="c=fr" scope=2 deref=0 filter="(o=soc)" conn=0 op=1 SRCH attr=* conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=0 op=2 UNBIND conn=0 fd=2160 closed These traces appear on screen but not on file. The problem is that when starting slapd as a Windows service, these traces are lost.

1 0

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

27 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 27 Feb '08

27 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 27 Feb '08

27 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 27 Feb '08

27 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2008