- openldap-bugs - openldap.org

(ITS#5668) Invalid entryCSN generated, and slapd will not restart
by emmanuel.duru＠atosorigin.com 26 Aug '08

26 Aug '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: Submission from: (NULL) (80.78.0.137) On Windows, slapd generates entryCSN values such as: 20080822124130.-657205Z#000000#000#000000 (the problem is the minus sign). This is also the case when generating the cn=config branch from a slapd.conf file. Following this, slapd will not restart, because it checks the validity of entryCSN values on cn=config branch at startup. I believe that the problem comes from non initialized static variables in lutil_gettime() function. Do notice that initializations are also missing in non WIN32 section.

1 0

(ITS#5665)
by toby＠inf.ed.ac.uk 25 Aug '08

25 Aug '08

Hi there, I've patched pcache.c and it seems fine. I'll put it through some more testing and confirm. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5665) slapd crashing with slapo-pcache when using attrset "*"
by ando＠sys-net.it 23 Aug '08

23 Aug '08

Should be fixed in HEAD; please test. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5667) Problem in the startTLS Command processing
by Kurt＠OpenLDAP.org 23 Aug '08

23 Aug '08

On Aug 22, 2008, at 2:53 PM, john.w.clark(a)hp.com wrote: > Full_Name: > Version: 2.3.36 and earlier and I assume also later > OS: Red Hat Enterprise Linux 4.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.233.75) > > > This problem was previously described one the openLDAP websiste at: > > http://www.openldap.org/lists/openldap-bugs/200405/msg00096.html > > The described fix is not included in release 2.3.36 and I assume > that it has not > been included in later releases either. > > The probem is with the response to the 'startTLS' command in the > 'slapd' server. > > > Here is an excerpt from the write up at the above URL: > > ************************************************************** > Having fixed described above we came across another issues which > concerns > TLS extended operation response. > > As RFC2830 states: RFC 2830 has been replaced by RFC 4510, 4511, and RFC 4513. > ... > A Start TLS extended response MUST contain a responseName field > which > MUST be set to the same string as that in the responseName field > present in the Start TLS extended request. > ... This MUST was purposely removed from the revised LDAP specifications by the IETF. > Unfortunately OpenLDAP server doesn't return the 'responseName' > field. This > defect may prevent other LDAP APIs from understanding the response of > OpenLDAP servers. Clients are suppose to message-ids to match up responses with requests. > For instance, Microsoft LDAP API doesn't accept the > response without this field. Sounds like a bug in Microsoft LDAP, especially given the current Start TLS specification. I suggest you report this to them. > We suggest to add the responseName field to the > response. This is also a trivial one: > > rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS); > > before 'rc = LDAP_SUCCESS;' in starttls_extop() function (starttls.c). See my comments in my response to ITS#3037 as to why I think such should not be done. > > > 3. Patch > > Unfortunately didn't manage to get access to the /incoming FTP folder > despite the fact I used my email as password. So here is a patch for > both > problems: > > ============= > --- orig/starttls.c 2004-01-01 21:15:32.000000000 +0200 > +++ fixed/starttls.c 2004-05-27 14:14:54.000000000 +0300 > @@ -94,6 +94,8 @@ > op->o_conn->c_is_tls = 1; > op->o_conn->c_needs_tls_accept = 1; > > + rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS); > + > rc = LDAP_SUCCESS; > > done: > ============= > > Looking forward for your comments... > > Sincerely yours, > > Kirill Kovalenko > Softerra LLC > ************************************************************ > > > Thanks and Regards, > John Clark > > john.w.clark(a)hp.com > Sr. Software Engineer > Hewlett-Packard > Atalla Security Products > >

1 0

(ITS#5667) Problem in the startTLS Command processing
by john.w.clark＠hp.com 22 Aug '08

22 Aug '08

Full_Name: Version: 2.3.36 and earlier and I assume also later OS: Red Hat Enterprise Linux 4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.203.233.75) This problem was previously described one the openLDAP websiste at: http://www.openldap.org/lists/openldap-bugs/200405/msg00096.html The described fix is not included in release 2.3.36 and I assume that it has not been included in later releases either. The probem is with the response to the 'startTLS' command in the 'slapd' server. Here is an excerpt from the write up at the above URL: ************************************************************** Having fixed described above we came across another issues which concerns TLS extended operation response. As RFC2830 states: ... A Start TLS extended response MUST contain a responseName field which MUST be set to the same string as that in the responseName field present in the Start TLS extended request. ... Unfortunately OpenLDAP server doesn't return the 'responseName' field. This defect may prevent other LDAP APIs from understanding the response of OpenLDAP servers. For instance, Microsoft LDAP API doesn't accept the response without this field. We suggest to add the responseName field to the response. This is also a trivial one: rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS); before 'rc = LDAP_SUCCESS;' in starttls_extop() function (starttls.c). 3. Patch Unfortunately didn't manage to get access to the /incoming FTP folder despite the fact I used my email as password. So here is a patch for both problems: ============= --- orig/starttls.c 2004-01-01 21:15:32.000000000 +0200 +++ fixed/starttls.c 2004-05-27 14:14:54.000000000 +0300 @@ -94,6 +94,8 @@ op->o_conn->c_is_tls = 1; op->o_conn->c_needs_tls_accept = 1; + rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS); + rc = LDAP_SUCCESS; done: ============= Looking forward for your comments... Sincerely yours, Kirill Kovalenko Softerra LLC ************************************************************ Thanks and Regards, John Clark john.w.clark(a)hp.com Sr. Software Engineer Hewlett-Packard Atalla Security Products

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 22 Aug '08

22 Aug '08

Kurt Zeilenga wrote: > > On Aug 21, 2008, at 9:57 AM, michael(a)stroeder.com wrote: > >> Hallvard B Furuseth wrote: >>> michael(a)stroeder.com writes: >>>> hyc(a)symas.com wrote: >>>>> Who benefits from this feature? >>>> An admin copying&pasting a schema from an standard document which uses >>>> this format. I'm currently looking at such a document with ~500 >>>> occurences of OIDs used in declarations instead of NAMEs. >>> >>> Which one? It's not RFC 4512 format. RFC 4512 uses ';' for comments >>> _about_ the syntax of schema elements, not _in_ their syntax. >> >> http://tools.ietf.org/draft/draft-dally-acp133-and-ldap/ > > There is a lot of crap in I-Ds, and even some crap in RFCs. Yes. :-/ That's why I was asking whether it's feasible to be liberal in what you receive (read from config) but to be strict in what you send (add to the schema). Ciao, Michael.

1 0

Re: (ITS#5666) getpeereid.c:65: error: storage size of peercred isnt known
by ghenry＠OpenLDAP.org 22 Aug '08

22 Aug '08

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > Presumably a dup of ITS#5464. > Workaround: Compile with CPPFLAGS=-D_GNU_SOURCE. Yeah, that's compiling now. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5666) getpeereid.c:65: error: storage size of peercred isnt known
by h.b.furuseth＠usit.uio.no 22 Aug '08

22 Aug '08

Presumably a dup of ITS#5464. Workaround: Compile with CPPFLAGS=-D_GNU_SOURCE. -- Hallvard

1 0

(ITS#5666) getpeereid.c:65: error: storage size of peercred isnt known
by ghenry＠OpenLDAP.org 22 Aug '08

22 Aug '08

Full_Name: Gavin Henry Version: 2.4.11 OS: Fedora 9 i386 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Submitted by: ghenry gcc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB.4.2/include -c -o fetch.o fetch.c gcc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB.4.2/include -c -o setproctitle.o setproctitle.c gcc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB.4.2/include -c -o getpeereid.o getpeereid.c getpeereid.c: In function lutil_getpeereid: getpeereid.c:65: error: storage size of peercred isnt known make[2]: *** [getpeereid.o] Error 1 Hi all, For some reason this is dieing on my laptop at above, but I haven't tested this on Fedora 9 i386 before, sorry. Any ideas?

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ghenry＠OpenLDAP.org 22 Aug '08

22 Aug '08

> The fact that the two servers scan the whole database is a side effect > > of the incorrect contextCSN; I wouldn't bother, as soon as the > corruption gets tracked and fixed. Is there anything that should be updated for the MirrorMode docs here? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5665) slapd crashing with slapo-pcache when using attrset "*"
by toby＠inf.ed.ac.uk 22 Aug '08

22 Aug '08

Full_Name: Toby Blake Version: 2.4.11 OS: Scientific Linux 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.215.24.127) Hi there, I have been seeing problems when using slapo-pcache with openldap-2.4.11, specifically when using an attrset of "*". - openldap-2.4.11 on scientific linux 5.1 - We build our own RPMs. I have built them with no optimisation (-O0) for the purposes of debugging. Relevant part of slapd.conf: overlay pcache proxycache bdb 5000 1 500 60 proxycachequeries 10000 proxyattrset 0 "*" proxytemplate (uid=) 0 60 60 What seems to happen is that a matching query will get answered and added to the cache - all is fine until that entry expires and is then deleted from the cache. The next matching query will then cause slapd to crash, either with an abort or a segfault. This is repeatable. I have been testing with the above configuration and the following queries: ldapsearch -x "uid=toby" ldapsearch -x "uid=blah" (the first for a positive reply, the second for a negative) I have seen three different types of crash, all at the same point (i.e. directly triggered by the query following the entry being deleted from the cache). So, here are the 3 different backtraces: backtrace 1: Thread 1 (process 13771): #0 0x081c39fb in ber_put_string (ber=0x9839c00, str=0x79626f74 <Address 0x79626f74 out of bounds>, tag=4294967295) at encode.c:396 #1 0x081c488a in ber_printf (ber=0x9839c00, fmt=0x8227d5d "v}N}") at encode.c:828 #2 0x08198957 in ldap_build_search_req (ld=0x9827920, base=0xb56051a4 "dc=inf,dc=ed,dc=ac,dc=uk", scope=2, filter=0xb5605234 "(uid=toby)", attrs=0x9831838, attrsonly=0, sctrls=0x0, cctrls=0x0, timelimit=3600, sizelimit=24576, idp=0xb5f05d78) at search.c:328 #3 0x081982fa in ldap_search_ext (ld=0x9827920, base=0xb56051a4 "dc=inf,dc=ed,dc=ac,dc=uk", scope=2, filter=0xb5605234 "(uid=toby)", attrs=0x9831838, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0xb5f05e28, sizelimit=24576, msgidp=0xb5f05e3c) at search.c:100 #4 0x08116466 in ldap_back_search (op=0x9811140, rs=0xb5f07110) at search.c:216 #5 0x080eb88e in overlay_op_walk (op=0x9811140, rs=0xb5f07110, which=op_search, oi=0x97a6da8, on=0x0) at backover.c:646 #6 0x080eba96 in over_op_func (op=0x9811140, rs=0xb5f07110, which=op_search) at backover.c:698 #7 0x080ebb3a in over_op_search (op=0x9811140, rs=0xb5f07110) at backover.c:720 #8 0x08070e83 in fe_op_search (op=0x9811140, rs=0xb5f07110) at search.c:366 #9 0x080707e1 in do_search (op=0x9811140, rs=0xb5f07110) at search.c:217 #10 0x0806d530 in connection_operation (ctx=0xb5f07200, arg_v=0x9811140) at connection.c:1084 #11 0x0806da1d in connection_read_thread (ctx=0xb5f07200, argv=0x18) at connection.c:1211 #12 0x08192de9 in ldap_int_thread_pool_wrapper (xpool=0x9785880) at tpool.c:663 #13 0x0076046b in start_thread () from /lib/libpthread.so.0 #14 0x006b7dbe in clone () from /lib/libc.so.6 (gdb) backtrace 2: Thread 1 (process 27627): #0 0x0065305a in free () from /lib/libc.so.6 #1 0x081c69ca in ber_memfree_x (p=0x9c8a1a0, ctx=0x0) at memory.c:152 #2 0x080d4020 in slap_sl_free (ptr=0x9c8a1a0, ctx=0x9c87c40) at sl_malloc.c:456 #3 0x080708de in do_search (op=0x9c89d78, rs=0xb5b8d110) at search.c:233 #4 0x0806d530 in connection_operation (ctx=0xb5b8d200, arg_v=0x9c89d78) at connection.c:1084 #5 0x0806da1d in connection_read_thread (ctx=0xb5b8d200, argv=0x10) at connection.c:1211 #6 0x08192de9 in ldap_int_thread_pool_wrapper (xpool=0x9bfe880) at tpool.c:663 #7 0x0076046b in start_thread () from /lib/libpthread.so.0 #8 0x006b7dbe in clone () from /lib/libc.so.6 (gdb) backtrace 3: Thread 1 (process 10333): #0 0x080bc4b2 in ad_inlist (desc=0x8efa9c8, attrs=0x8f8c488) at ad.c:586 #1 0x08080641 in fe_aux_operational (op=0x8f8bce0, rs=0xb5b8b110) at backend.c:1885 #2 0x08080809 in backend_operational (op=0x8f8bce0, rs=0xb5b8b110) at backend.c:1933 #3 0x080829f6 in slap_send_search_entry (op=0x8f8bce0, rs=0xb5b8b110) at result.c:778 #4 0x0811684c in ldap_back_search (op=0x8f8bce0, rs=0xb5b8b110) at search.c:338 #5 0x080eb88e in overlay_op_walk (op=0x8f8bce0, rs=0xb5b8b110, which=op_search, oi=0x8f21da8, on=0x0) at backover.c:646 #6 0x080eba96 in over_op_func (op=0x8f8bce0, rs=0xb5b8b110, which=op_search) at backover.c:698 #7 0x080ebb3a in over_op_search (op=0x8f8bce0, rs=0xb5b8b110) at backover.c:720 #8 0x08070e83 in fe_op_search (op=0x8f8bce0, rs=0xb5b8b110) at search.c:366 #9 0x080707e1 in do_search (op=0x8f8bce0, rs=0xb5b8b110) at search.c:217 #10 0x0806d530 in connection_operation (ctx=0xb5b8b200, arg_v=0x8f8bce0) at connection.c:1084 #11 0x0806da1d in connection_read_thread (ctx=0xb5b8b200, argv=0x10) at connection.c:1211 #12 0x08192de9 in ldap_int_thread_pool_wrapper (xpool=0x8f00880) at tpool.c:663 #13 0x0076046b in start_thread () from /lib/libpthread.so.0 #14 0x006b7dbe in clone () from /lib/libc.so.6 (gdb) In an hour of testing (with a positive query) yesterday, nine of the crashes were with backtrace 3, two were with backtrace 1, and one was with backtrace 2. In an hour of testing with a negative query, all of the crashes were essentially backtrace 2, but with a longer stack: Thread 1 (process 18684): #0 0x00220402 in __kernel_vsyscall () #1 0x0060fd20 in raise () from /lib/libc.so.6 #2 0x00611631 in abort () from /lib/libc.so.6 #3 0x00647e6b in __libc_message () from /lib/libc.so.6 #4 0x0064fb16 in _int_free () from /lib/libc.so.6 #5 0x00653070 in free () from /lib/libc.so.6 #6 0x081c69ca in ber_memfree_x (p=0x9bf1488, ctx=0x0) at memory.c:152 #7 0x080d4020 in slap_sl_free (ptr=0x9bf1488, ctx=0x9bee420) at sl_malloc.c:456 #8 0x080708de in do_search (op=0x9bf1110, rs=0xb5f27110) at search.c:233 #9 0x0806d530 in connection_operation (ctx=0xb5f27200, arg_v=0x9bf1110) at connection.c:1084 #10 0x0806da1d in connection_read_thread (ctx=0xb5f27200, argv=0x10) at connection.c:1211 #11 0x08192de9 in ldap_int_thread_pool_wrapper (xpool=0x9b65880) at tpool.c:663 #12 0x0076046b in start_thread () from /lib/libpthread.so.0 #13 0x006b7dbe in clone () from /lib/libc.so.6 (gdb) Please let me know if there is any additional information I can provide. Cheers Toby Blake School of Informatics University of Edinburgh

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ali.pouya＠free.fr 22 Aug '08

22 Aug '08

Hi Pierangelo, >> contextCSN: 20080727021429.070493Z#000000#000#000000 >> contextCSN:: +HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA== > > which looks like > > 4 bytes of garbage + "0802033718.300111Z#000000#001#000000" > Yes, but I would like to bring a precision : under VI the 4 bytes are handled as 2 characters only. In fact each time the problem occurs I repair my database using a BDB C program wich reads the first key from id2entry.bdb and writes it on disk. Then I use vi to fix the contextCSN, before writing the key back to the database. Using vi I do not delete any characters. I only replace them by 20, then I fix the rest of the fields. Another precision : when the first two chars take corrupted, the rest of the contextCSN gets stuck and does not follow write operations. > I note that, according to the sid values you assigned to servers A and > B, the first contextCSN should not appear, since it has sid == 0, > while the second one, apart from the corruption, is plausible (as > you're writing to server A, with sid == 1). > Yes. The contextCSN with sid=0 is there because at the beginning I initiated my directory without SID (defaults to 0), then I set two difrent SIDs for A and B. Best Regards Ali

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ando＠sys-net.it 21 Aug '08

21 Aug '08

ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.11 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > I think there is a documentation issue for OpenLdap 2.4.11 : > The chapter 17.4.4 of the Admin Guide recommends configuring TWO sycrepl > directives for each mirror side. If I do so, the contextCSN of the stand by > mirror gets corrupted very easily. But if I confugure the mirrors with only ONE > syncrepl directive it's OK. > > The test environment : > I have a test directory with two mirrors A (sid=1) and B (sid=2) configured as > recommended in the Admin's Guide, and a replica C connected to A. > The directory contains 10 million objects, and I use the server A for writing > 500 000 new ones. > > Very often and without any apparent reason the contextCSN in the memory of B > gets suddenly corrupted while those of A and C are OK. > In this situation the contextCSN of B gets stuck but B continues to receive data > from A. > > The value of contextCSN in base 64 is : > > contextCSN: 20080727021429.070493Z#000000#000#000000 > contextCSN:: +HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA== which looks like 4 bytes of garbage + "0802033718.300111Z#000000#001#000000" I note that, according to the sid values you assigned to servers A and B, the first contextCSN should not appear, since it has sid == 0, while the second one, apart from the corruption, is plausible (as you're writing to server A, with sid == 1). > I note that only the part indicating the year (2008) is garbled. May be this > part is handled differently ? No. > At service shutdown B writes the corrupt contextCSN to the disk. > At service startup B reads the corrupt contextCSN from the disk and begins to > scan ALL of the data base. > > Also it sends a sync request to A (a persitent search containing the corrupt > contextCSN in the control field) causing A to scan the WHOLE data base. > The replica C remains safe. The fact that the two servers scan the whole database is a side effect of the incorrect contextCSN; I wouldn't bother, as soon as the corruption gets tracked and fixed. > If I reverse the roles of A and B the corruption occurs on A (always on the > stand by mirror). > > I have already encountered the contextCSN corruption problem in OpenLdap 2.3 and > this was one of my reasons to migrate to 2.4.11. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5652) configure errors
by ando＠sys-net.it 21 Aug '08

21 Aug '08

edpena(a)cisco.com wrote: > Full_Name: Ed Pena > Version: openldap-2.3.39 > OS: hpux 11.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.102.254.33) Please provide config.log resulting from the execution of configure. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5653) Segmentation Fault running slapd with mysql back-end
by ando＠sys-net.it 21 Aug '08

21 Aug '08

A fix is in HEAD code; it checks args before trying to parse them. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by Kurt＠OpenLDAP.org 21 Aug '08

21 Aug '08

On Aug 21, 2008, at 9:57 AM, michael(a)stroeder.com wrote: > Hallvard B Furuseth wrote: >> michael(a)stroeder.com writes: >>> hyc(a)symas.com wrote: >>>> Who benefits from this feature? >>> An admin copying&pasting a schema from an standard document which >>> uses >>> this format. I'm currently looking at such a document with ~500 >>> occurences of OIDs used in declarations instead of NAMEs. >> >> Which one? It's not RFC 4512 format. RFC 4512 uses ';' for comments >> _about_ the syntax of schema elements, not _in_ their syntax. > > http://tools.ietf.org/draft/draft-dally-acp133-and-ldap/ There is a lot of crap in I-Ds, and even some crap in RFCs. -- Kurt

1 0

Re: (ITS#5664) Deadlocks when writing in parallell (two processes)
by quanah＠zimbra.com 21 Aug '08

21 Aug '08

--On Thursday, August 21, 2008 6:29 PM +0000 hyc(a)symas.com wrote: > stelios.xx.grigoriadis(a)ericsson.com wrote: >> tom.bjorkholm(a)aastra.com wrote: >>> Full_Name: Stelios Grigoriadis& Tom Bj?rkholm >>> Version: 2.3.39 >>> OS: Novell SLES 10 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (194.237.142.7) >>> >>> >>> We get a lot of DB_LOCK_DEADLOCK when using client programs that for a >>> period of time continuously writes to OpenLDAP. >>> Version is 2.3.39. >>> >>> The information added is of the form: >>> ebcmdCustomer=0+ebcmdDir=220xx,ou=AuthCodes,ebcmdVersion=0,ebcmdProduct >>> =ebcmd,dc=example,dc=com where xx varies. >>> >>> Snippet of the output: >>> Mar 27 13:03:21 ldapt1 slapd[7589]: => bdb_dn2id_add: subtree >>> (ebcmdCustomer=0+ebcmdDir=22037,ou=authcodes,ebcmdVersion=0,ebcmdProduc >>> t=ebcmd,dc=example,dc=com) put failed: -30995 >>> Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id >>> failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) >>> Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_dn2id_add: parent >>> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) >>> insert failed: -30995 >>> Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id >>> failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) >>> Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_dn2id_add: parent >>> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) >>> insert failed: -30995 >>> Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id >>> failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) >>> Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_dn2id_add: parent >>> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) >>> insert failed: -30995 >>> Mar 27 13:03:38 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id >>> failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) >>> >>> >>> >> >> We've temporarily fixed the problem by introducing a static mutex before >> any add/update operation. > > There's no problem to fix. Deadlocks are normal in these scenarios, and > the code automatically retries. This ITS will be closed. I will note that testing on 2.3 has shown time and again that serialized updates perform better, regardless. Using accesslog with delta-syncrepl replication essentially enforces this. The more you can serialize updates, particularly with batch provisioning, the smoother your system will operate. This may not apply to 2.4. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5664) Deadlocks when writing in parallell (two processes)
by hyc＠symas.com 21 Aug '08

21 Aug '08

stelios.xx.grigoriadis(a)ericsson.com wrote: > tom.bjorkholm(a)aastra.com wrote: >> Full_Name: Stelios Grigoriadis& Tom Björkholm >> Version: 2.3.39 >> OS: Novell SLES 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (194.237.142.7) >> >> >> We get a lot of DB_LOCK_DEADLOCK when using client programs that for a period of >> time continuously writes to OpenLDAP. >> Version is 2.3.39. >> >> The information added is of the form: >> ebcmdCustomer=0+ebcmdDir=220xx,ou=AuthCodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com >> where xx varies. >> >> Snippet of the output: >> Mar 27 13:03:21 ldapt1 slapd[7589]: => bdb_dn2id_add: subtree >> (ebcmdCustomer=0+ebcmdDir=22037,ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) >> put failed: -30995 >> Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: >> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) >> Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_dn2id_add: parent >> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert >> failed: -30995 >> Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: >> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) >> Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_dn2id_add: parent >> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert >> failed: -30995 >> Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: >> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) >> Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_dn2id_add: parent >> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert >> failed: -30995 >> Mar 27 13:03:38 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: >> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) >> >> >> > > We've temporarily fixed the problem by introducing a static mutex before > any add/update operation. There's no problem to fix. Deadlocks are normal in these scenarios, and the code automatically retries. This ITS will be closed. -- -- Howard Chu CTO, 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#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 21 Aug '08

21 Aug '08

Hallvard B Furuseth wrote: > michael(a)stroeder.com writes: >> hyc(a)symas.com wrote: >>> Who benefits from this feature? >> An admin copying&pasting a schema from an standard document which uses >> this format. I'm currently looking at such a document with ~500 >> occurences of OIDs used in declarations instead of NAMEs. > > Which one? It's not RFC 4512 format. RFC 4512 uses ';' for comments > _about_ the syntax of schema elements, not _in_ their syntax. http://tools.ietf.org/draft/draft-dally-acp133-and-ldap/ Not for my professional work. I was just looking for really complex schemas for testing web2ldap. Ciao, Michael.

1 0

Re: (ITS#5653) Segmentation Fault running slapd with mysql back-end
by ando＠sys-net.it 21 Aug '08

21 Aug '08

ollieeillo(a)yahoo.co.uk wrote: > backsql_oc_get_attr_mapping(): executing at_query > "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u > FROM ldap_attr_mappings WHERE oc_map_id=?" > for objectClass "document" > with param oc_id="2" > attributeType: > name="(null)" > sel_expr="(null)" > from="(null)" > join_where="(null)" > add_proc="(null)" > delete_proc="(null)" > sel_expr_u="" > Segmentation fault This log seems to indicate that the ldap_attr_mappings table contains NULLs for required fields. A check will be added to the code, but yours definitely looks like a user error... fix your table and retry. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by h.b.furuseth＠usit.uio.no 21 Aug '08

21 Aug '08

michael(a)stroeder.com writes: >hyc(a)symas.com wrote: >>Michael Ströder wrote: >>> The comments wouldn't have to persist in cn=config. >> >> Perhaps not, but that makes the data in cn=config less comprehensible >> than it would be in slapd.conf. Well, that's no different from #comments at the beginning of lines. Or the default values which back-config inserts. One can't tell whether a value is present because the admin knew and thought about it or because cn=config defaulted it. However: >> Who benefits from this feature? > > An admin copying&pasting a schema from an standard document which uses > this format. I'm currently looking at such a document with ~500 > occurences of OIDs used in declarations instead of NAMEs. Which one? It's not RFC 4512 format. RFC 4512 uses ';' for comments _about_ the syntax of schema elements, not _in_ their syntax. -- Hallvard

1 0

Re: (ITS#5664) Deadlocks when writing in parallell (two processes)
by stelios.xx.grigoriadis＠ericsson.com 21 Aug '08

21 Aug '08

tom.bjorkholm(a)aastra.com wrote: > Full_Name: Stelios Grigoriadis & Tom Björkholm > Version: 2.3.39 > OS: Novell SLES 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > > > We get a lot of DB_LOCK_DEADLOCK when using client programs that for a period of > time continuously writes to OpenLDAP. > Version is 2.3.39. > > The information added is of the form: > ebcmdCustomer=0+ebcmdDir=220xx,ou=AuthCodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com > where xx varies. > > Snippet of the output: > Mar 27 13:03:21 ldapt1 slapd[7589]: => bdb_dn2id_add: subtree > (ebcmdCustomer=0+ebcmdDir=22037,ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) > put failed: -30995 > Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: > DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) > Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_dn2id_add: parent > (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert > failed: -30995 > Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: > DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) > Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_dn2id_add: parent > (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert > failed: -30995 > Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: > DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) > Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_dn2id_add: parent > (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert > failed: -30995 > Mar 27 13:03:38 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: > DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) > > > We've temporarily fixed the problem by introducing a static mutex before any add/update operation. By doing so, we have effectively serialized the add/update operations from within slapd. This is just intended as a temporary solution as we hope the issue will be resolved in future releases. The patch: # This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software # represented in the following patch(es) were developed by Stelios Grigoriadis stelios.xx.grigoriadis(a)ericsson.com. # These modifications are not subject to any license of Ericsson AB. # I, Stelios Grigoriadis, 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. # Bug Fix - This patch fixes the bug ITS#5133. # The fix works as follows. A periodic check in the runqueue (called do_mastercheck). The intervall is determined by # a slapd.conf parameter (mastercheckint) in the syncrepl section and is optional. If it's not specified, it's not # inserted in the runqueue. --- servers/slapd/connection.c 2007-06-15 01:49:38.000000000 +0200 +++ connection.c 2008-06-10 16:30:08.000000000 +0200 @@ -1052,19 +1052,24 @@ /* FIXME: returns 0 in case of failure */ ldap_pvt_mp_add_ulong(slap_counters.sc_ops_initiated, 1); ldap_pvt_thread_mutex_unlock( &slap_counters.sc_ops_mutex ); + static pthread_mutex_t op_upd_mutex = PTHREAD_MUTEX_INITIALIZER; + int upd_tag=0; op->o_threadctx = ctx; #ifdef LDAP_DEVEL op->o_tid = ldap_pvt_thread_pool_tid( ctx ); #endif /* LDAP_DEVEL */ switch ( tag ) { - case LDAP_REQ_BIND: - case LDAP_REQ_UNBIND: case LDAP_REQ_ADD: case LDAP_REQ_DELETE: case LDAP_REQ_MODDN: case LDAP_REQ_MODIFY: + ldap_pvt_thread_mutex_lock( &op_upd_mutex ); + upd_tag=1; + break; + case LDAP_REQ_BIND: + case LDAP_REQ_UNBIND: case LDAP_REQ_COMPARE: case LDAP_REQ_SEARCH: case LDAP_REQ_ABANDON: @@ -1178,6 +1183,10 @@ connection_resched( conn ); ldap_pvt_thread_mutex_unlock( &conn->c_mutex ); + if (upd_tag) { + ldap_pvt_thread_mutex_unlock( &op_upd_mutex ); + } + return NULL; }

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 21 Aug '08

21 Aug '08

hyc(a)symas.com wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> As for truncating the comments on input - kind of pointless. In >>> particular, that means those comments won't be persisted in cn=config. >> The comments wouldn't have to persist in cn=config. > > Perhaps not, but that makes the data in cn=config less comprehensible than it > would be in slapd.conf. On the other hand, OID macros *are* preserved in > cn=config, which is yet another reason to use them. > > Who benefits from this feature? An admin copying&pasting a schema from an standard document which uses this format. I'm currently looking at such a document with ~500 occurences of OIDs used in declarations instead of NAMEs. > The comment is there for the benefit of a > human admin who has to read this definition. If the comment is stripped, then > the benefit is lost; anyone inspecting the schema remotely will just be faced > with the unwieldy numeric OIDs. Well, in web2ldap's schema viewer I'm always trying to display the NAME instead of the OID if possible. slapd could also normalize the schema declarations to list the NAME instead of OID if available (but that would be another ITS). > It still wouldn't persist because e.g. at_unparse() (which provides the value > that actually gets stored) works by constructing the string out of the LDAP > Attribute structure. So again, all of the comments would be gone, and there > would be no embedded line endings. My request was simply to truncate and ignore the comments. Ciao, Michael.

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by hyc＠symas.com 21 Aug '08

21 Aug '08

Michael Ströder wrote: > Howard Chu wrote: >> As for truncating the comments on input - kind of pointless. In >> particular, that means those comments won't be persisted in cn=config. > > The comments wouldn't have to persist in cn=config. Perhaps not, but that makes the data in cn=config less comprehensible than it would be in slapd.conf. On the other hand, OID macros *are* preserved in cn=config, which is yet another reason to use them. Who benefits from this feature? The comment is there for the benefit of a human admin who has to read this definition. If the comment is stripped, then the benefit is lost; anyone inspecting the schema remotely will just be faced with the unwieldy numeric OIDs. Remember also, slapd.conf is going to be phased out down the road. It's better not to add features to it that people are going to rely on, if the analogous feature won't be exposed in cn=config. Instead, we should be making use of whatever features already exist that are supported in both. Hallvard wrote: > back-config could accept > attributeTypes:: base64("description with line endings and comments") > if it doesn't already. It still wouldn't persist because e.g. at_unparse() (which provides the value that actually gets stored) works by constructing the string out of the LDAP Attribute structure. So again, all of the comments would be gone, and there would be no embedded line endings. -- -- Howard Chu CTO, 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#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 21 Aug '08

21 Aug '08

Howard Chu wrote: > As for truncating the comments on input - kind of pointless. In > particular, that means those comments won't be persisted in cn=config. The comments wouldn't have to persist in cn=config. Ciao, Michael.

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by h.b.furuseth＠usit.uio.no 21 Aug '08

21 Aug '08

Michael Ströder writes: >> but someone who schema via some LDAP-friendly tool might. > > ??? > > My schema viewer always trys to display NAME(s) of any schema element > linked. Oops, some words disappeard. I meant someone who reads/writes schema using a LDAP-friendly (and LDIF-friendly) tool, so they'd see the base64-decoded version of the attribute. -- Hallvard

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 21 Aug '08

21 Aug '08

h.b.furuseth(a)usit.uio.no wrote: > Personally I wouldn't write such a file anytime > soon, Me neither. But if you just copy&paste schema declarations from a RFC or I-D it would be handy to accept this. > but someone who schema via some LDAP-friendly tool might. ??? My schema viewer always trys to display NAME(s) of any schema element linked. Ciao, Michael.

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by hyc＠symas.com 21 Aug '08

21 Aug '08

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> It might be helpful if the schema config file parser would accept lines with >>> comments at the end separated by semicolon. >> The parser doesn't know anything about line endings. Remember, lines with >> leading white space are continuations of the previous line. The schema parser >> is just fed a single string as one long line, the line endings were removed >> long before it ever got there. > > Maybe lines with ; could be truncated before passing it to the schema > parser? I don't know if that has any impact on processing slapd.conf in > general. > The slapd.conf parser has to already know in advance that this > part is a schema declaration (started by key-word objectclass etc.) and > could change pre-processing? Actually no, the parser doesn't know there's anything special about schema declarations. It doesn't parse the lines any differently than any other directives. Nor should it. As for truncating the comments on input - kind of pointless. In particular, that means those comments won't be persisted in cn=config. -- -- Howard Chu CTO, 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#5662) Comments in schema declarations separated by semicolon
by h.b.furuseth＠usit.uio.no 21 Aug '08

21 Aug '08

hyc(a)symas.com writes: > It would be smarter to just standardize OID macros for each of these > OIDs, the way X.500 did, and not require the humans reading these > specs to memorize these numeric OIDs... Yup. slapd/schema/syntaxes.schema? Syntax names like olsDirectoryString or just DirectoryString? (I don't know if OID macro names are a separate namespace or not.) > I don't see any straightforward way to modify our parser as you're > suggesting. Unless someone else feels like jumping in, I think we > should reject this ITS. back-config could accept attributeTypes:: base64("description with line endings and comments") if it doesn't already. Personally I wouldn't write such a file anytime soon, but someone who schema via some LDAP-friendly tool might. -- Hallvard

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 21 Aug '08

21 Aug '08

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> It might be helpful if the schema config file parser would accept lines with >> comments at the end separated by semicolon. > > The parser doesn't know anything about line endings. Remember, lines with > leading white space are continuations of the previous line. The schema parser > is just fed a single string as one long line, the line endings were removed > long before it ever got there. Maybe lines with ; could be truncated before passing it to the schema parser? I don't know if that has any impact on processing slapd.conf in general. The slapd.conf parser has to already know in advance that this part is a schema declaration (started by key-word objectclass etc.) and could change pre-processing? Ciao, Michael.

1 0

(ITS#5664) Deadlocks when writing in parallell (two processes)
by tom.bjorkholm＠aastra.com 21 Aug '08

21 Aug '08

Full_Name: Stelios Grigoriadis & Tom Björkholm Version: 2.3.39 OS: Novell SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) We get a lot of DB_LOCK_DEADLOCK when using client programs that for a period of time continuously writes to OpenLDAP. Version is 2.3.39. The information added is of the form: ebcmdCustomer=0+ebcmdDir=220xx,ou=AuthCodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com where xx varies. Snippet of the output: Mar 27 13:03:21 ldapt1 slapd[7589]: => bdb_dn2id_add: subtree (ebcmdCustomer=0+ebcmdDir=22037,ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) put failed: -30995 Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_dn2id_add: parent (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert failed: -30995 Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_dn2id_add: parent (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert failed: -30995 Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_dn2id_add: parent (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert failed: -30995 Mar 27 13:03:38 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by hyc＠symas.com 21 Aug '08

21 Aug '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.84.234) > > > It might be helpful if the schema config file parser would accept lines with > comments at the end separated by semicolon. The parser doesn't know anything about line endings. Remember, lines with leading white space are continuations of the previous line. The schema parser is just fed a single string as one long line, the line endings were removed long before it ever got there. > Example (derived from http://tools.ietf.org/draft/draft-dally-acp133-and-ldap/ > using mainly OIDs): > > attributetype ( 2.16.840.1.101.2.2.1.69 NAME 'transferStation' > EQUALITY 2.5.13.13 ; booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ; BOOLEAN > SINGLE-VALUE ) It would be smarter to just standardize OID macros for each of these OIDs, the way X.500 did, and not require the humans reading these specs to memorize these numeric OIDs... I don't see any straightforward way to modify our parser as you're suggesting. Unless someone else feels like jumping in, I think we should reject 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/

1 0

(ITS#5663) Declaring substitute syntax as LDAP syntax
by michael＠stroeder.com 21 Aug '08

21 Aug '08

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.84.234) Sometimes one wants to add a custom schema which also defines LDAP syntaxes which are not supported yet but could be substituted by another LDAP syntax already implemented. Instead of changing SYNTAX of all attribute type declarations in the custom schema it might be handy if declaring a substitute LDAP syntax would be possible while still providing the original syntax declaration to the client which might know better what to do with it. Example for emulating custom LDAP syntax with PrintableString: ldapsyntax ( 1.3.6.1.4.1.5427.666.42.42.42 X-SUBST 1.3.6.1.4.1.1466.115.121.1.44 ) This should fail with parsing error if one trys to add a substitute syntax for a syntax already implemented.

1 0

(ITS#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 21 Aug '08

21 Aug '08

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.84.234) It might be helpful if the schema config file parser would accept lines with comments at the end separated by semicolon. Example (derived from http://tools.ietf.org/draft/draft-dally-acp133-and-ldap/ using mainly OIDs): attributetype ( 2.16.840.1.101.2.2.1.69 NAME 'transferStation' EQUALITY 2.5.13.13 ; booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ; BOOLEAN SINGLE-VALUE )

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther＠sendmail.com 21 Aug '08

21 Aug '08

I have an updated patch, but can't post it: ftp.openldap.org's incoming is full: ftp> cd incoming 250 CWD command successful. ftp> put guenther-080820.patch local: guenther-080820.patch remote: guenther-080820.patch 150 Opening BINARY mode data connection for 'guenther-080820.patch'. 100% |**************************************************| 9215 00:00 452 Error writing file: No space left on device. 9215 bytes sent in 0.13 seconds (66.79 KB/s) ftp> (Once we get a patch that looks good, I'll follow it with a patch for the docs.)

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by hyc＠symas.com 20 Aug '08

20 Aug '08

Philip Guenther wrote: > On Tue, 19 Aug 2008, Howard Chu wrote: >> guenther(a)sendmail.com wrote: > ... >>> TLS_PROTOCOL_MIN<major>,<minor> >> Let's use US convention<major>.<minor>... > > Ok. > >>> C: >>> struct ldap_tls_protocol { unsigned char major, minor; } val; >>> val.major = 3; val.minor=0; >>> ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN,&val); >> I would just use an int, and have the caller OR in the appropriate >> values. > > So: > /* force TLS 1.0 or later */ > ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN, (3<< 8) + 1); The set_option interface requires a pointer. So min = (3<<8)+1; ldap_set_option(ld, LDAP_OPT_X_TLS_PROTOCOL_MIN, &min); > > >> You could also define a few macros for the currently known versions. > > Preferences on the format of those macros? > > #define LDAP_OPT_X_TLS_PROTOCOL_SSLv2 (2<< 8) > #define LDAP_OPT_X_TLS_PROTOCOL_SSLv3 (3<< 8) > #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 ((3<< 8) + 1) > #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_1 ((3<< 8) + 2) > #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_2 ((3<< 8) + 3) > > ? > Drop the 'v' and I think it'll be fine -- -- Howard Chu CTO, 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#5655) add option for setting minimum TLS/SSL protocol
by guenther＠sendmail.com 20 Aug '08

20 Aug '08

On Tue, 19 Aug 2008, Howard Chu wrote: > guenther(a)sendmail.com wrote: ... > > TLS_PROTOCOL_MIN<major>,<minor> > > Let's use US convention <major>.<minor>... Ok. > > C: > > struct ldap_tls_protocol { unsigned char major, minor; } val; > > val.major = 3; val.minor=0; > > ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN,&val); > > I would just use an int, and have the caller OR in the appropriate > values. So: /* force TLS 1.0 or later */ ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN, (3 << 8) + 1); > You could also define a few macros for the currently known versions. Preferences on the format of those macros? #define LDAP_OPT_X_TLS_PROTOCOL_SSLv2 (2 << 8) #define LDAP_OPT_X_TLS_PROTOCOL_SSLv3 (3 << 8) #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 ((3 << 8) + 1) #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_1 ((3 << 8) + 2) #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_2 ((3 << 8) + 3) ? > What are the values for TLS1.1, 1.2, etc? So far, TLS 1.x == SSL version 3.(x+1). Philip Guenther

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by hyc＠symas.com 19 Aug '08

19 Aug '08

guenther(a)sendmail.com wrote: > On Fri, 15 Aug 2008, Philip Guenther wrote: > ... >> That said, it's more important to me that *some* option gets in so that I >> (and Sendmail) don't have to maintain forever a patch to add it. If >> someone 'official' will make a decision and simply state what the option >> should look like in its three forms (C API, ldap.conf, slapd config), I'll >> munge the patch to match. > > Any opinions? > > ldap.conf: > TLS_PROTOCOL_MIN<major>,<minor> Let's use US convention <major>.<minor>... > C: > struct ldap_tls_protocol { unsigned char major, minor; } val; > val.major = 3; val.minor=0; > ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN,&val); I would just use an int, and have the caller OR in the appropriate values. You could also define a few macros for the currently known versions. What are the values for TLS1.1, 1.2, etc? > > ? > > > (I'm running out of time to get _something_ into Sendmail's local copy, at > which point I'll just commit something there and have to leave you guys to > hack whatever you get around into the official repository.) > > > Philip Guenther > > > -- -- Howard Chu CTO, 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#5655) add option for setting minimum TLS/SSL protocol
by guenther＠sendmail.com 19 Aug '08

19 Aug '08

On Fri, 15 Aug 2008, Philip Guenther wrote: ... > That said, it's more important to me that *some* option gets in so that I > (and Sendmail) don't have to maintain forever a patch to add it. If > someone 'official' will make a decision and simply state what the option > should look like in its three forms (C API, ldap.conf, slapd config), I'll > munge the patch to match. Any opinions? ldap.conf: TLS_PROTOCOL_MIN <major>,<minor> C: struct ldap_tls_protocol { unsigned char major, minor; } val; val.major = 3; val.minor=0; ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN, &val); ? (I'm running out of time to get _something_ into Sendmail's local copy, at which point I'll just commit something there and have to leave you guys to hack whatever you get around into the official repository.) Philip Guenther

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ghenry＠OpenLDAP.org 19 Aug '08

19 Aug '08

----- "ali pouya" <ali.pouya(a)free.fr> wrote: > Hi Gavin; > > Below you find the answers to your questions : > > > Can we get your bdb version, your config and the logs of an empty > mirrormode > > node B pulling in the data loaded in mirrormode A (posted/hosted > online > > somewhere). > > The BDB version is 4.6.21. > You find here attached the file conf.tar.gz containing the > configuration of B. Thanks. > The file syncrepl.conf.simple works well, but the file > syncrepl.conf.double > garbles the contextCSN (I write more than 1000 entries per minute). > Do you want a log for the 10 million entries ? Which loglevel ? Nope, not yet. loglevel sync > The problem only happens if there are write operations on A, not if > the server A > is stationary. Also note that serverID is a *global* directive not per database. Move that out of "database bdb". > > Also, has this always happened on the same machine? What are the > specs of the > > servers? > > The problem happens on the stand by server : If I write on B the > contextCSN of > A gets corrupted (I have already tested this). > > My servers are quadri-processor Xeon 2.2 GHz. > I think this is not related to the hardware but the "year" part of > contextCSN is > not well protected against concurrent operations (?). > > > > > Is this a fresh install? > Yes for 2.4.11, but I use OpenLdap since 5 years for my different > projects. OK, well you should then know that "rootdn cn=admin,ou=ressources-dgi,ou=mefi,o=gouv,c=fr" by passes all ACLs, so you don't need: access to * by dn.base="cn=admin,ou=ressources-dgi,ou=mefi,o=gouv,c=fr" write -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Fwd: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ghenry＠OpenLDAP.org 19 Aug '08

19 Aug '08

------=_Part_5_5686568.1219150476998 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit For Ticket records. Please keep to openldap-its ----- Forwarded Message ----- From: "ali pouya" <ali.pouya(a)free.fr> To: ghenry(a)OpenLDAP.org Sent: Tuesday, 19 August, 2008 1:48:53 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror Hi Gavin; Below you find the answers to your questions : > Can we get your bdb version, your config and the logs of an empty mirrormode > node B pulling in the data loaded in mirrormode A (posted/hosted online > somewhere). The BDB version is 4.6.21. You find here attached the file conf.tar.gz containing the configuration of B. The file syncrepl.conf.simple works well, but the file syncrepl.conf.double garbles the contextCSN (I write more than 1000 entries per minute). Do you want a log for the 10 million entries ? Which loglevel ? The problem only happens if there are write operations on A, not if the server A is stationary. > > Also, has this always happened on the same machine? What are the specs of the > servers? The problem happens on the stand by server : If I write on B the contextCSN of A gets corrupted (I have already tested this). My servers are quadri-processor Xeon 2.2 GHz. I think this is not related to the hardware but the "year" part of contextCSN is not well protected against concurrent operations (?). > > Is this a fresh install? Yes for 2.4.11, but I use OpenLdap since 5 years for my different projects. Best Regards Ali > -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ ------=_Part_5_5686568.1219150476998 Content-Type: application/x-gzip; name=conf.tar.gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=conf.tar.gz H4sIAJrAqkgAA+2Z3VMbNxDAeT39FRp4SELJfWI7YeYeaNym6aTUKSXN9E0+ybbSO+miD4Lb6f/e vTsbjI1rHLAZEv2YwWd97Z6kXa3WfrCzcUKg02rVn8D8Z/0cRWErbh1CwwTKO52wvYNbm1dtZ8dq QxTGO0pK83/tVtU/UvxAj0WmWJn7mRQDX/OizNn9yqgWuH14uHT9D8PW9fWPkk6Y7ODwftW4mW98 /ffQdP2x4jQNwxjhUslzTplKc0rKoyCIQj9qtf3EjzrJUfLiJcJmXLJUsYFienQsaI8pzbVBWDGj xuluFOPvdhHWjKhs1CeapbtZOlBQNOC5gYF3n8r+R5aZVznROt1/VjXOJIypbb96HLGCwL/sLy6G qRwMEO5zQQtmRpKmzRZtiqiAoUVavcOBtKCS1tKqjOnndMirkoIN4DMdSnt+MNEB3pYyYTjJdd0R oYdehAcE7D8nJa2Nf1MyVth/EiVT+0/gmIjB/qN2J3b2vw327gbawwv0lPzIjMZECEu4YpgynBPc ff1moSn0v7P8H3k24kxVUqpNzIdWEcOlqMU+uVTi15KJt93jHi7BQczIn21DmcYlUYZnNoch9eK7 bUD/95XzBHWPcOh3VkpckI+7xFSaKwEaM1xIygc8a2YAw6DRyyBsB3EYvljS/9gaZtWSEY7wcc5x T9ox2cz7c5HlljLPC6xWQS4zkgfMZAEcBqI6foLmMAgyqZjfPK/RR3Oxdi/oYqQalrAsUqzbuSxl zrPxut3gsMpkUdj15V3t1mlXtJfLYc7OWe49jxAqOYVD9/pI50QFyoqJ64cWiKihrpstbVW1QKv1 Ihkcvro+ThCixJDq+MdeIQWHWb0q8vq0jzRT50y96Xox0nYw4BeeNwkUKm9LhefB2U5owcXtDve6 W/nZw94/p6c/Hf8bvbMn3T+S8tO7bu9lYn7Jxh9k+1X+5/c/x+97rQ+vEQWrz0CvsRdA0EMtNzoA xYJKy9XvCvEHu5i8ah2tlJIL40XNsYbbIdq7oTgKbzGNOS9Al8nYqzfDbAiPCq6UVGDGMO9SICRh jnMyxlWrKrRD04fnV9rhWr1Kt8tKDdMNLgA2U1N5VSNkCWsBIZT3+29nP1yVK5ZLQkd8WvEtx1WP hfn7H5W2v+X7XwR/c/Ff0m63XPy3DRbuf9F93P/Cx3X/W+sK3HJXYMdXw5z/34iM2+f/Kv8fgf+P D2N3/98KLv/3bTs/f/aqsSEZK+2/fThv/2Encva/DZrVx5gKn12QzKxrTtjwgqVW1OMwijX/e+Yr QpPxvWvjw14TYP3Mqk1KATd2Ma6GI2WZTxJauvo+m+L7EnEPvWb3iT+TxdiUjFX3v6QdLeb/3f1v K9w9f73AlvP/V7yFGKRJ4td7GlvDc67hKyVC45zhjNBGndn893We4vzJ8dLfA55tQP/Z/H/7xiz/ ch5//h/VS+XNhIMHEJup8avTk+bh7OxN1/M89gntNU2pINkpUxC+ndiiz5TX1DaVllPPu1aSiWnB QRVcflXO+x7wZzP2G5Kxyv/HnXjO/8dhEjr/vw1Qs/zYSEyMUTq1mqkemOFnqSiqbLw/Bk8uxbiQ Fny6NaNpKQRbk7vdehGjYoTeNMZlvLayCxhyuvtFgd0y2etHpJ8VxILTofYxzBBDM5O5f5OUNX7K mhNwj7o+9mWbzvVDW47D4XA4HA6Hw+FwOBwOh8PhcDgcDofD4XA4HA6Hw+FwOBwPx39608HTAFAA AA== ------=_Part_5_5686568.1219150476998--

1 0

Trans.: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ali.pouya＠free.fr 19 Aug '08

19 Aug '08

----- Message transféré de ali.pouya(a)free.fr ----- Date : Tue, 19 Aug 2008 14:48:53 +0200 De : ali.pouya(a)free.fr Adresse de retour :ali.pouya@free.fr Sujet : Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror À : ghenry(a)OpenLDAP.org Hi Gavin; Below you find the answers to your questions : > Can we get your bdb version, your config and the logs of an empty mirrormode > node B pulling in the data loaded in mirrormode A (posted/hosted online > somewhere). The BDB version is 4.6.21. You find here attached the file conf.tar.gz containing the configuration of B. The file syncrepl.conf.simple works well, but the file syncrepl.conf.double garbles the contextCSN (I write more than 1000 entries per minute). Do you want a log for the 10 million entries ? Which loglevel ? The problem only happens if there are write operations on A, not if the server A is stationary. > > Also, has this always happened on the same machine? What are the specs of the > servers? The problem happens on the stand by server : If I write on B the contextCSN of A gets corrupted (I have already tested this). My servers are quadri-processor Xeon 2.2 GHz. I think this is not related to the hardware but the "year" part of contextCSN is not well protected against concurrent operations (?). > > Is this a fresh install? Yes for 2.4.11, but I use OpenLdap since 5 years for my different projects. Best Regards Ali > ----- Fin du message transféré -----

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ghenry＠OpenLDAP.org 19 Aug '08

19 Aug '08

> I think there is a documentation issue for OpenLdap 2.4.11 : > The chapter 17.4.4 of the Admin Guide recommends configuring TWO > sycrepl > directives for each mirror side. If I do so, the contextCSN of the > stand by > mirror gets corrupted very easily. But if I confugure the mirrors > with only ONE > syncrepl directive it's OK. The documentation is correct. > The test environment : > I have a test directory with two mirrors A (sid=1) and B (sid=2) > configured as > recommended in the Admin's Guide, and a replica C connected to A. > The directory contains 10 million objects, and I use the server A for > writing > 500 000 new ones. > > Very often and without any apparent reason the contextCSN in the > memory of B > gets suddenly corrupted while those of A and C are OK. > In this situation the contextCSN of B gets stuck but B continues to > receive data > from A. > > The value of contextCSN in base 64 is : > > contextCSN: 20080727021429.070493Z#000000#000#000000 > contextCSN:: +HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA== perl -MMIME::Base64 -e 'print decode_base64("+HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA=="), "\n";' does look very funny :-( Can we get your bdb version, your config and the logs of an empty mirrormode node B pulling in the data loaded in mirrormode A (posted/hosted online somewhere). Also, has this always happened on the same machine? What are the specs of the servers? Is this a fresh install? -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

(ITS#5661) contextCSN gets corrupted on the stand by mirror
by ali.pouya＠free.fr 19 Aug '08

19 Aug '08

Full_Name: Ali Pouya Version: 2.4.11 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) I think there is a documentation issue for OpenLdap 2.4.11 : The chapter 17.4.4 of the Admin Guide recommends configuring TWO sycrepl directives for each mirror side. If I do so, the contextCSN of the stand by mirror gets corrupted very easily. But if I confugure the mirrors with only ONE syncrepl directive it's OK. The test environment : I have a test directory with two mirrors A (sid=1) and B (sid=2) configured as recommended in the Admin's Guide, and a replica C connected to A. The directory contains 10 million objects, and I use the server A for writing 500 000 new ones. Very often and without any apparent reason the contextCSN in the memory of B gets suddenly corrupted while those of A and C are OK. In this situation the contextCSN of B gets stuck but B continues to receive data from A. The value of contextCSN in base 64 is : contextCSN: 20080727021429.070493Z#000000#000#000000 contextCSN:: +HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA== I note that only the part indicating the year (2008) is garbled. May be this part is handled differently ? At service shutdown B writes the corrupt contextCSN to the disk. At service startup B reads the corrupt contextCSN from the disk and begins to scan ALL of the data base. Also it sends a sync request to A (a persitent search containing the corrupt contextCSN in the control field) causing A to scan the WHOLE data base. The replica C remains safe. If I reverse the roles of A and B the corruption occurs on A (always on the stand by mirror). I have already encountered the contextCSN corruption problem in OpenLdap 2.3 and this was one of my reasons to migrate to 2.4.11. Thanks for your HELP Best Regards Ali Pouya

1 0

(ITS#5660) SHA-2 hash support
by jeff＠atlassian.com 18 Aug '08

18 Aug '08

Full_Name: Jeff Turner Version: 2.3.30 OS: Linux URL: http://confluence.atlassian.com/download/attachments/162431971/openldap-sha… Submission from: (NULL) (203.63.130.33) OpenLDAP currently supports MD5, CRYPT and SHA1 hash formats. I needed support for SHA-512, so I have created a module to support SHA512, and the other SHA-2 formats (SHA256 and SHA384). I'd be happy for it to be included in OpenLDAP's contrib/slapd-modules/passwd/ directory. Code suitable for inclusion is linked in the ticket URL, and there is a fuller description of its use in the included README, or at http://confluence.atlassian.com/display/JIRAEXT/OpenLDAP+support+for+SHA-2+… As for the code, it is a thin module wrapper on an unmodified version of the BSD-licenced sha2.{c,h} by Aaron Gifford: http://www.aarongifford.com/computers/sha.html This also appears to be the SHA2 implementation used by OpenBSD. Please let me know if you have any questions.

1 0

(ITS#5659) patch for collect overlay
by brett.maxfield＠gmail.com 17 Aug '08

17 Aug '08

Full_Name: Brett Maxfield Version: HEAD OS: Linux suse 2.6.22.18-0.2-xen #1 SMP 2008-06-09 13:53:20 +0200 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/brett-maxfield-080817.tgz Submission from: (NULL) (220.245.180.135) Fixes bug with overlay system where it would inherit/collect attributes to the entry that was supplying those attributes, causing duplicate attributes in that node. Also add a alternate config format for easy entry, eg old format: overlay collect collectinfo <dn> <attribute> and now in addition to above also supports : overlay collect collectinfo <dn> <attribute1>,<attribute2>,<attributeN>

1 0

Re: (ITS#5658) slapo-perl symbol updates
by rra＠stanford.edu 16 Aug '08

16 Aug '08

rra(a)stanford.edu writes: > It's a general change to the libperl API and may not only affect HPPA. > You're apparently now required to call those macros, and in the future > they may have more effects. Here is a patch, untested alas because I don't have time at the moment to set up something with back-perl. It compiles. I'm not fully sure that the handling of embedded and argc is correct. Perl 5.10 (and some earlier versions) require calling some additional macros around Perl interpreter setup and shutdown. Not doing these calls causes problems on HPPA at least, and may affect other platforms in the future. This patch adds the additional code modelled on the perlembed man page and a working patch for INN. Debian Bug#495069 ITS #5658 --- openldap.orig/servers/slapd/back-perl/close.c +++ openldap/servers/slapd/back-perl/close.c @@ -30,6 +30,9 @@ { perl_destruct(PERL_INTERPRETER); perl_free(PERL_INTERPRETER); +#ifdef PERL_SYS_TERM + PERL_SYS_TERM(); +#endif PERL_INTERPRETER = NULL; ldap_pvt_thread_mutex_destroy( &perl_interpreter_mutex ); --- openldap.orig/servers/slapd/back-perl/init.c +++ openldap/servers/slapd/back-perl/init.c @@ -37,6 +37,7 @@ ) { char *embedding[] = { "", "-e", "0" }; + int argc = 3; bi->bi_open = NULL; bi->bi_config = 0; @@ -77,9 +78,15 @@ ldap_pvt_thread_mutex_init( &perl_interpreter_mutex ); +#ifdef PERL_SYS_INIT3 + PERL_SYS_INIT3(&argc, &embedding, (char **)NULL); +#endif PERL_INTERPRETER = perl_alloc(); perl_construct(PERL_INTERPRETER); - perl_parse(PERL_INTERPRETER, perl_back_xs_init, 3, embedding, (char **)NULL); +#ifdef PERL_EXIT_DESTRUCT_END + PL_exit_flags |= PERL_EXIT_DESTRUCT_END; +#endif + perl_parse(PERL_INTERPRETER, perl_back_xs_init, argc, embedding, (char **)NULL); perl_run(PERL_INTERPRETER); return 0; } -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5658) slapo-perl symbol updates
by rra＠stanford.edu 16 Aug '08

16 Aug '08

quanah(a)OpenLDAP.org writes: > Full_Name: Quanah Gibson-Mount > Version: 2.4.11 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.109.79.65) > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495069 > > Not sure how much we care about hppa architecture. It's a general change to the libperl API and may not only affect HPPA. You're apparently now required to call those macros, and in the future they may have more effects. What we did for INN was add: #ifdef PERL_SYS_INIT3 PERL_SYS_INIT3(&argc, &argv, &env); #endif before perl_alloc, #ifdef PERL_EXIT_DESTRUCT_END PL_exit_flags |= PERL_EXIT_DESTRUCT_END; #endif after perl_construct, and: #ifdef PERL_SYS_TERM PERL_SYS_TERM(); #endif after perl_free. See man perlembed; with Perl 5.10, its example now reads: int main(int argc, char **argv, char **env) { PERL_SYS_INIT3(&argc,&argv,&env); my_perl = perl_alloc(); perl_construct(my_perl); PL_exit_flags |= PERL_EXIT_DESTRUCT_END; perl_parse(my_perl, NULL, argc, argv, (char **)NULL); perl_run(my_perl); perl_destruct(my_perl); perl_free(my_perl); PERL_SYS_TERM(); } Notice that we don't use the "env" pointer. Normally handed to "perl_parse" as its final argument, "env" here is replaced by "NULL", which means that the current environment will be used. The macros PERL_SYS_INIT3() and PERL_SYS_TERM() provide system-specific tune up of the C runtime environment necessary to run Perl interpreters; since PERL_SYS_INIT3() may change "env", it may be more appropriate to provide "env" as an argument to perl_parse(). -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

(ITS#5658) slapo-perl symbol updates
by quanah＠OpenLDAP.org 15 Aug '08

15 Aug '08

Full_Name: Quanah Gibson-Mount Version: 2.4.11 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.109.79.65) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495069 Not sure how much we care about hppa architecture. As described in the 'perlembed' document, programs embedding Perl must use the PERL_SYS_INIT3() and PERL_SYS_TERM() macros to provide system-specific tune up of the C runtime environment necessary to run Perl interpreters. Your package has been identified as failing this: - at least one of the binary packages built from the source depends on libperl5.10 - the unpacked source matches 'perl_parse' but not 'PERL_SYS_INIT3' As a consequence, the embedded Perl interpreter is most probably broken on the hppa architecture, where PERL_SYS_INIT3() is needed for initializing lock structures. Without this, calling perl_parse() will hang inside pthread_mutex_lock(). See #486069 for more information.

1 0

(ITS#5657) Broken symlinks in /etc/ssl/certs prevent ssl connection
by Martin.vGagern＠gmx.net 15 Aug '08

15 Aug '08

Full_Name: Martin von Gagern Version: 2.3.43 OS: Gentoo Linux URL: https://bugs.gentoo.org/show_bug.cgi?id=234816 Submission from: (NULL) (84.188.31.84) On systems with broken symlinks in the default certificate directory of openssl, I found it impossible to establish an ldaps connection with openldap. I originally reported this issue as https://bugs.gentoo.org/show_bug.cgi?id=234816 I first encountered this when I got informed by luma that I could not connect to a server. I then reproduced this on the command line: $ ldapsearch -H ldaps://ldap.domain.tld ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ ldapsearch -d 15 -H ldaps://ldap.domain.tld ... ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS: could not load client CA list (file:`',dir:`/etc/ssl/certs/'). TLS: error:0906D06C:PEM routines:PEM_read_bio:no start line pem_lib.c:647 ... previous line repeated 13 times ... TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:356 TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:358 ldap_perror ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Sadly it does not say what file can't be opened. The "no start line" errors seem to be non-fatal. The fopen error in bss_file.c from dev-libs/openssl on the other hand seems to cause the connection to fail. Root of the cause seemed to be several broken symlinks in /etc/ssl/certs. Steps to solve the issue by removing those links: # find /etc/ssl/certs -type l ! -xtype f ! -xtype d -ok rm -f {} \; Steps to reproduce the issue, provided you have an SSL-Enabled LDAP server: # ln -s bar.pem /etc/ssl/certs/foo.pem $ ldapsearch -d 15 -H ldaps://ldap.domain.tld Ideally openldap should trat these errors as non-fatal, the way s_client does, so that such a broken symlink won't prevent all connections. If that path towards solution proves infeasible (as the openssl function SSL_add_dir_cert_subjects_to_stack seems to behave this way and adding all files manually might be a pain), at least there should be some error message telling the user that the problem lies in the local SSL certificates setup, not really in the network connection or remote configuration. By the way, I'm using openssl version 0.9.8h.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs