- openldap-bugs - openldap.org

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 2:35 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully > patched. > > The interesting fact is that HEAD currently hangs all the time in > test008. RE24 with your recent changes now fails as described in > test039. Before these changes RE24 just worked fine. > > I think this is related to modifications in connection.c because trouble > started after HEAD contained these changes. All tests pass for me with current RE24 and HEAD. What Linux kernel are you using? The RE24 changes to the connection code are the same as what are in HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5900) Problem to populate LDAP 2.4.12 with an Ldiff file on SUNBLADE
by fethi.tekitek＠alcatel-lucent.com 21 Jan '09

21 Jan '09

Full_Name: Fathy Tekitek Version: 2.4.12 OS: Solaris 10 (rev 8) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.23.212.109) Hi, I try to populate the openldap 2.4.12 running with BerkeleyDB 4.7.25 using an ldiff file The first two entry are populate but It remains blocked This problem is reproducible on SunBlade 100 servers but not in T5000, SunBlade2500 and Ultra45 where it works OK. I can enter the content of this file one bye one but all in the ldiff file "/export/home/build26/openldap/bin/ldapadd -d 1 -H "ldaps://sunval233 " -x -D "cn=root,dc=alu,dc=com" -f /export/home/build26/CSA/data/installation/ngsecPopulate.ldif -w newuser1" here the ldap traces ldap_url_parse_ext(ldaps://sunval233) ldap_create ldap_url_parse_ext(ldaps://sunval233:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP sunval233:636 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 10.0.0.233:636 ldap_pvt_connect: fd: 4 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 0, subject: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC, issuer: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC TLS certificate verification: depth: 0, err: 0, subject: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC/CN=sunval233, issuer: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 43 bytes to sd 4 ldap_result ld 90c48 msgid 1 wait4msg ld 90c48 msgid 1 (infinite timeout) wait4msg continue ld 90c48 msgid 1 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 1 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select read1msg: ld 90c48 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 90c48 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 90c48 0 new referrals read1msg: mark request completed, ld 90c48 msgid 1 request done: ld 90c48 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree adding new entry "dc=alu,dc=com" ldap_add_ext ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 101 bytes to sd 4 ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ^C #

1 0

Re: (ITS#5899) make fails on AIX5.3
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 5:12 PM +0000 masterson.andrew(a)gmail.com wrote: > Full_Name: Andrew > Version: 2.4.11 > OS: AIX5.3 64 bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.98.237.232) > > > configure runs > > CPPFLAGS=-I/usr/local/BerkeleyDB.4.7/include > LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib ./configure --enable-ipv6 OpenLDAP 2.4.11 does not support BDB 4.7. Use OpenLDAP 2.4.12 or later for BDB 4.7 support. And make sure you have all 3 patches for BDB 4.7. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5899) make fails on AIX5.3
by masterson.andrew＠gmail.com 21 Jan '09

21 Jan '09

Full_Name: Andrew Version: 2.4.11 OS: AIX5.3 64 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.98.237.232) configure runs CPPFLAGS=-I/usr/local/BerkeleyDB.4.7/include LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib ./configure --enable-ipv6 (and gives warnings about openssl and Cyrus SASL not being installed - otherwise fine) make fails with the following error: cd back-bdb; make all rm -f version.c ../../../build/mkversion -v "2.4.11" back_bdb > version.c /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc_r -g -I../../../include -I../../../include -I.. -I./.. -I/usr/local/BerkeleyDB.4.7/include -c init.c cc_r -g -I../../../include -I../../../include -I.. -I./.. -I/usr/local/BerkeleyDB.4.7/include -c init.c -o init.o "init.c", line 509.49: 1506-022 (S) "lk_handle" is not a member of "struct __db_env". "init.c", line 752.32: 1506-280 (W) Function argument assignment between types "int(*)(unsigned long,unsigned long)" and "int(*)(void)" is not allowed. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop.

1 0

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by michael＠stroeder.com 21 Jan '09

21 Jan '09

quanah(a)zimbra.com wrote: > --On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: > >> Howard Chu wrote: >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (84.163.100.169) >>>> >>>> >>>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>>> `!(*(&((lc))->lc_lcflags) >>>> & (((0x00000020U))))' failed. >>> I'm not seeing that here. Ran into a couple other problems though, fixed >>> now in HEAD. Please re-test... >> Now test008 hangs... > > Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 patches, > and HEAD CVS as of 1/20/2009 @ 12:00 PST. > > Did you fully rebuild OpenLDAP after the latest commits? What version of > BDB are you using? Is it fully patched? What backend was it using when it > hung? Did you get a backtrace of where it hung? I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully patched. The interesting fact is that HEAD currently hangs all the time in test008. RE24 with your recent changes now fails as described in test039. Before these changes RE24 just worked fine. I think this is related to modifications in connection.c because trouble started after HEAD contained these changes. Ciao, Michael.

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ando＠sys-net.it 21 Jan '09

21 Jan '09

ghenry(a)suretecsystems.com wrote: > ----- ando(a)sys-net.it wrote: > >> Gavin Henry wrote: >>> Sorry, I presume this was a bug in the code and the docs document >> the >>> right behaviour? >>> >>> I'll revert them when you've confirmed. >> As far as I remember, the bug was in the example in >> slapo-constraint(5) >> man page ("[:digit:]" indicates the collection of values ":", "d", >> "i", >> ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct >> > > OK, it was actually this bit: > > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ > > and in HEAD it still only had one set of []. Both the admin guide and man page > have been updated for this in my last commit. Definitely my fault: apparently, I fixed it in my working copy long ago (maybe while offline) and forgot to commit. I just found it out because of a conflict when updating with your fix. Thanks, 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#5895) Example in constraint manual and documentation
by ghenry＠suretecsystems.com 21 Jan '09

21 Jan '09

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > > Sorry, I presume this was a bug in the code and the docs document > the > > right behaviour? > > > > I'll revert them when you've confirmed. > > As far as I remember, the bug was in the example in > slapo-constraint(5) > man page ("[:digit:]" indicates the collection of values ":", "d", > "i", > ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct > OK, it was actually this bit: constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ and in HEAD it still only had one set of []. Both the admin guide and man page have been updated for this in my last commit. Thanks. -- Kind Regards, Gavin Henry. Managing Director. 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/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5889) [PATCH] Sending dereference field when retrying connection in meta backend
by ando＠sys-net.it 20 Jan '09

20 Jan '09

jorge.perez(a)adaptia.net wrote: > When we have two slapds with a established meta connection between them and the > connection is reset, for example by a router, the next search query will always > be send with never in dereferencing. > > Steps to reproduce: > > - Established a meta connection between 2 slapds > - Reset the connection, for example with cutter > - Send a search dereferencing with something different to never. > - See the results are no dereferenced. > > Patch attached. Thanks, fixed (with minor modifications). 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#5897) trailing characters in olcserverids after conversion
by oliver＠itc.li 20 Jan '09

20 Jan '09

Howard Chu schrieb: > oliver(a)itc.li wrote: >> Full_Name: Oliver Liebel >> Version: 2.4.13 >> OS: opensuse 11 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.144.97.81) >> >> >> using openldap 2.4.13 (compiled from openldap.org source-package) >> i have noticed the following, reproducable behaviour when converting >> a slapd.conf to slapd.d: >> >> if slapd.conf contains serverids with ldap-urls, e.g. in this format: >> >> ServerID 1 "ldap://ldapmaster.local.site:9000" >> ServerID 2 "ldap://ldapslave.local.site:9000" >> >> the olcserverids in cn=config.ldif always contains some trailing >> (garbage) >> characters after the conversion, and are base64 encoded. when i set >> them >> manually in cn=config with ldapmodify, they are displayed "clean". >> >> the serverid-lines in slapd.conf are "clean" (they contain no >> whitespaces / tabs >> at the end of the line or similar, invisible characters). >> >> i have tested it several times, without using \"\ in the string >> and/or without >> portnumber. i have tested the conversion with both slaptest and slapd, >> in virtual and real machines, >> result was always the same. > > Thanks for the report, this is now fixed in HEAD. Note, URLs don't > need to be surrounded with quotes. By definition, they are already > "safe". okay, understood. thanks for your response. greetings oliver

1 0

Re: (ITS#5898) test044 abort with back-ldif
by h.b.furuseth＠usit.uio.no 20 Jan '09

20 Jan '09

> When using the back-ldif backend with test044, it aborts: Probably ITS#5340. -- Hallvard

1 0

(ITS#5898) test044 abort with back-ldif
by quanah＠OpenLDAP.org 20 Jan '09

20 Jan '09

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) When using the back-ldif backend with test044, it aborts: Program terminated with signal 6, Aborted. (gdb) bt #0 0x000000395e030155 in raise () from /lib64/libc.so.6 #1 0x000000395e031bf0 in abort () from /lib64/libc.so.6 #2 0x000000395e0295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000438a3b in entry2str (e=0x1e88, len=0x438a49) at entry.c:452 #4 0x0000000004fe9748 in ?? () #5 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x0000000000438a3b in entry2str (e=0x1e88, len=0x438a49) at entry.c:452 452 tmplen = e->e_name.bv_len; (gdb) l 447 ecur = ebuf; 448 449 /* put the dn */ 450 if ( e->e_dn != NULL ) { 451 /* put "dn: <dn>" */ 452 tmplen = e->e_name.bv_len; 453 MAKE_SPACE( LDIF_SIZE_NEEDED( 2, tmplen )); 454 ldif_sput( &ecur, LDIF_PUT_VALUE, "dn", e->e_dn, tmplen ); 455 } 456

1 0

Re: (ITS#5896) search error on ldap_search_ext_s
by hyc＠symas.com 20 Jan '09

20 Jan '09

eduard.budulea(a)axigen.com wrote: > Full_Name: Eduard Budulea > Version: 2.4.11 > OS: gnu/linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.230.245.6) > > > ldap_search_ext_s does not return all the messages that the server sends. > If the response from the ldap server is compose from 2 messages: > - a LDAP Intermediate Response Message > - a SearchResultDone Message > > the ldap_search_ext_s returns only the intermediate one. > > Step to reporduce: > have a ldap running with some entries. > have a the syncprov overlay deploy. > make a synchronous search with a null cookie and a filter that does not match > all the entries. > now modify an entry that is not in the previous result set. > make another synchronous search with the cookie from the previous search. > you will be able to see only the intermediate and not the done (that holds the > cookie). > > If you do the same but using ldap_search_ext and ldap_result you will get the > result done message also. This behavior is by design, and has been in place since 2000. Whether the design is correct or not may be an open question; since Kurt wrote that code I'd ask him to comment further. -- -- 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#5897) trailing characters in olcserverids after conversion
by hyc＠symas.com 20 Jan '09

20 Jan '09

oliver(a)itc.li wrote: > Full_Name: Oliver Liebel > Version: 2.4.13 > OS: opensuse 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.144.97.81) > > > using openldap 2.4.13 (compiled from openldap.org source-package) > i have noticed the following, reproducable behaviour when converting > a slapd.conf to slapd.d: > > if slapd.conf contains serverids with ldap-urls, e.g. in this format: > > ServerID 1 "ldap://ldapmaster.local.site:9000" > ServerID 2 "ldap://ldapslave.local.site:9000" > > the olcserverids in cn=config.ldif always contains some trailing (garbage) > characters after the conversion, and are base64 encoded. when i set them > manually in cn=config with ldapmodify, they are displayed "clean". > > the serverid-lines in slapd.conf are "clean" (they contain no whitespaces / tabs > at the end of the line or similar, invisible characters). > > i have tested it several times, without using \"\ in the string and/or without > portnumber. i have tested the conversion with both slaptest and slapd, > in virtual and real machines, > result was always the same. Thanks for the report, this is now fixed in HEAD. Note, URLs don't need to be surrounded with quotes. By definition, they are already "safe". -- -- 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#5897) trailing characters in olcserverids after conversion
by quanah＠zimbra.com 20 Jan '09

20 Jan '09

--On Monday, January 19, 2009 5:41 PM +0000 oliver(a)itc.li wrote: > Full_Name: Oliver Liebel > Version: 2.4.13 > OS: opensuse 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.144.97.81) > > > using openldap 2.4.13 (compiled from openldap.org source-package) > i have noticed the following, reproducable behaviour when converting > a slapd.conf to slapd.d: > i have tested it several times, without using \"\ in the string and/or > without portnumber. i have tested the conversion with both slaptest and > slapd, in virtual and real machines, > result was always the same. Can you test with current CVS of HEAD? back-ldif has been largely reworked. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ando＠sys-net.it 20 Jan '09

20 Jan '09

Gavin Henry wrote: > Sorry, I presume this was a bug in the code and the docs document the > right behaviour? > > I'll revert them when you've confirmed. As far as I remember, the bug was in the example in slapo-constraint(5) man page ("[:digit:]" indicates the collection of values ":", "d", "i", ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct in HEAD, but the correction is not in re24. The code has always been correct with respect to this issue both in HEAD and re24. 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#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 20 Jan '09

20 Jan '09

--On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.100.169) >>> >>> >>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>> `!(*(&((lc))->lc_lcflags) >>> & (((0x00000020U))))' failed. >> >> I'm not seeing that here. Ran into a couple other problems though, fixed >> now in HEAD. Please re-test... > > Now test008 hangs... Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 patches, and HEAD CVS as of 1/20/2009 @ 12:00 PST. Did you fully rebuild OpenLDAP after the latest commits? What version of BDB are you using? Is it fully patched? What backend was it using when it hung? Did you get a backtrace of where it hung? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#5789 using IP address in CN with GnuTLS
by hyc＠symas.com 20 Jan '09

20 Jan '09

Upon further re-reading of RFC4513 and RFC2818, I think the original behavior was correct. An IP address is only allowed to match an IP Address subjectAltName, it is not allowed to match the certificate CN. -- -- 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#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 19 Jan '09

19 Jan '09

Pierangelo, Executing some test I'm not sure anymore if this is really a memory leakage or if some cache issue. I decided to install CentOS5.2 where I could have OpenLdap 2.3.27 compiled by the distribution and then execute more tests to check if some library in RHEL4 would be causing some problem. I then use a similar slapd.conf as in my original e-mail just without explicitly define an size for cache and idlcache there. My DB_CONFIG file has a cache defined as 50MB what is respected. Looking at some other ITS I found the ITS#3938 what I believe is very similar to my problem. I still have a DB with 3882998 entrances and where the DB files at disk is around 15GB. My machine has 12GB of memory where for sure all the DB cannot be cached into memory. In any case what is happening is that every time a transaction is done with OpenLdap, even a distribution formal compilation, the cache continues to grow until consumes all memory. If the DB is bigger than machine memory then soon or later a memory out of range will happen. The cache is never release by OpenLdap and then if a sequential search is done and since DB is bigger than memory we can speed up the problem. I also used Valgrind where I obtained : ==4963== LEAK SUMMARY: ==4963== definitely lost: 0 bytes in 0 blocks. ==4963== possibly lost: 0 bytes in 0 blocks. ==4963== still reachable: 336,091 bytes in 12,547 blocks. ==4963== suppressed: 0 bytes in 0 blocks. ==4963== Reachable blocks (those to which a pointer was found) are not shown. ==4963== To see them, rerun with: --show-reachable=yes [root@brtldp12 bdbBackupContent]# ==4964== Conditional jump or move depends on uninitialised value(s) ... Valgrind's memory management: out of memory: newSuperblock's request for 1048576 bytes failed. 2952183808 bytes have already been allocated. Valgrind cannot continue. Sorry. See it consume all the available memory and then could not allocate more memory. I also have an old version of OpenLdap in other machine with the same HW where the same DB has even more entrances. I'm trying to upgrade the OpenLdap to improve other itens but this appears to not be possible. At this old version I do not have this infinite cache problem and the only memory consumed is the Berkeley DB cache defined as 50MB. I could ldapsearch all the DB but once cache is allocated it never release it. At top I can see the memory continues associated with slapd process even the ldapsearch ends. Then if we start other ldapsearch then memory continues to be allocated. For information the old version informations is : openldap 2.1.30 and BerkeleyDB 4.2.52 With this version above I have a DB bigger than the available memory and I do not have this cache problem. I also do not have entrances like idelcache or anything else at slapd.conf file. At this way at new versions if for some reason you have a file DB bigger than your available memory with time you will have problems with OpenLdap. I will try again to force the idlcache and openldap cache but the last time tried this did not work. In this way I would identify better this problem and ask if you see this is as a bug or if some configuration would "force" openldap to cache(clean it) only using certain maximum size? Regards, Rodrigo. --- On Tue, 12/30/08, Pierangelo Masarati <ando(a)sys-net.it> wrote: > From: Pierangelo Masarati <ando(a)sys-net.it> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)openldap.org > Date: Tuesday, December 30, 2008, 2:06 PM > rlvcosta(a)yahoo.com wrote: > > --0-1358063323-1230648878=:64021 > > Content-Type: text/plain; charset=iso-8859-1 > > Content-Transfer-Encoding: quoted-printable > > > > Pierangelo, > > > > I could run the valgrind but at this time I do not > have the DB with the aro= > > und 4 million subscribers. In this condition, with a > small number of users,= > > I already could see some "definitive" > memory leaks and I believe they are = > > associated with OpenLdap. > > > > Just for a history I already compiled the openldap > 2.4.11 souce code withou= > > t modules and TLS since many lists make reference to > some possible issues i= > > n RHEL with TLS. Even so I could not have a load > without the possible memor= > > y leak. > > > > So I do not believe the problems are in the RHEL > libtool or glibc. > > > > In any case the result for the valgrind is (short > number of entrances at th= > > is time): > > You probably need to use an unstripped binary in order to > find out where mallocs/frees occur. Most of the occurrences > you notice are either one-time leaks. Moreover, 2.4.13 is > out, and it might have fixed some. I suggest you further > investigate using the latest code, using an unstripped > binary. > > 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#5895) Example in constraint manual and documentation
by gavin.henry＠gmail.com 19 Jan '09

19 Jan '09

Sorry, I presume this was a bug in the code and the docs document the right behaviour? I'll revert them when you've confirmed. On 19/01/2009, ando(a)sys-net.it <ando(a)sys-net.it> wrote: > marjan.blatnik(a)gov.si wrote: >> Full_Name: Marjan Blatnik >> Version: 2.4.13 >> OS: Debian GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.2.236.13) >> >> >> Example in slapo-constraint manual is not precise. >> The line >> constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ >> should be >> constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ >> >> And similar in >> http://www.openldap.org/doc/admin24/overlays.html#Constraints > > This is already fixed in HEAD, but apparently has not been ported to > 2.4. Thanks for noticing it. > > 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 > ----------------------------------- > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ghenry＠OpenLDAP.org 19 Jan '09

19 Jan '09

----- "marjan blatnik" <marjan.blatnik(a)gov.si> wrote: > Full_Name: Marjan Blatnik > Version: 2.4.13 > OS: Debian GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.2.236.13) > > > Example in slapo-constraint manual is not precise. > The line > constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ > should be > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ > > And similar in > http://www.openldap.org/doc/admin24/overlays.html#Constraints Thanks, updated. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5897) trailing characters in olcserverids after conversion
by oliver＠itc.li 19 Jan '09

19 Jan '09

Full_Name: Oliver Liebel Version: 2.4.13 OS: opensuse 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.144.97.81) using openldap 2.4.13 (compiled from openldap.org source-package) i have noticed the following, reproducable behaviour when converting a slapd.conf to slapd.d: if slapd.conf contains serverids with ldap-urls, e.g. in this format: ServerID 1 "ldap://ldapmaster.local.site:9000" ServerID 2 "ldap://ldapslave.local.site:9000" the olcserverids in cn=config.ldif always contains some trailing (garbage) characters after the conversion, and are base64 encoded. when i set them manually in cn=config with ldapmodify, they are displayed "clean". the serverid-lines in slapd.conf are "clean" (they contain no whitespaces / tabs at the end of the line or similar, invisible characters). i have tested it several times, without using \"\ in the string and/or without portnumber. i have tested the conversion with both slaptest and slapd, in virtual and real machines, result was always the same. greetings, oliver

1 0

Re: (ITS#5880) back-bdb segfault
by michael＠stroeder.com 19 Jan '09

19 Jan '09

quanah(a)zimbra.com wrote: > --On Saturday, January 17, 2009 2:38 AM +0000 jwm(a)horde.net wrote: > >> On Fri, Jan 16, 2009 at 06:14:01PM -0800, Quanah Gibson-Mount wrote: >>> --On Saturday, January 17, 2009 2:08 AM +0000 jwm(a)horde.net wrote: >>>> RE24 as of 13 January 2009 is still crashing, sometimes due to an >>>> assertion failure and sometimes due to a segfault when manipulating the >>>> back-bdb cache. >>> Well, I'm not sure I'd use RE24 CVS right now. There's a lot of pending >>> fixes that I'll be doing soon to go into it. >> So your recommendation would be... to revert to 2.4.13 and wait for these >> fixes to land in RE24 to see if they fix the back-bdb cache-related >> segfaults I'm reporting in this ITS? > > I'm just warning that current RE24 is not expected to be at all stable. I vaguely remember a discussion about deprecating back-bdb in favor of back-hdb anyway. Ciao, Michael.

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ando＠sys-net.it 19 Jan '09

19 Jan '09

marjan.blatnik(a)gov.si wrote: > Full_Name: Marjan Blatnik > Version: 2.4.13 > OS: Debian GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.2.236.13) > > > Example in slapo-constraint manual is not precise. > The line > constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ > should be > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ > > And similar in http://www.openldap.org/doc/admin24/overlays.html#Constraints This is already fixed in HEAD, but apparently has not been ported to 2.4. Thanks for noticing it. 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

(ITS#5896) search error on ldap_search_ext_s
by eduard.budulea＠axigen.com 19 Jan '09

19 Jan '09

Full_Name: Eduard Budulea Version: 2.4.11 OS: gnu/linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.230.245.6) ldap_search_ext_s does not return all the messages that the server sends. If the response from the ldap server is compose from 2 messages: - a LDAP Intermediate Response Message - a SearchResultDone Message the ldap_search_ext_s returns only the intermediate one. Step to reporduce: have a ldap running with some entries. have a the syncprov overlay deploy. make a synchronous search with a null cookie and a filter that does not match all the entries. now modify an entry that is not in the previous result set. make another synchronous search with the cookie from the previous search. you will be able to see only the intermediate and not the done (that holds the cookie). If you do the same but using ldap_search_ext and ldap_result you will get the result done message also.

1 0

(ITS#5895) Example in constraint manual and documentation
by marjan.blatnik＠gov.si 19 Jan '09

19 Jan '09

Full_Name: Marjan Blatnik Version: 2.4.13 OS: Debian GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.2.236.13) Example in slapo-constraint manual is not precise. The line constraint_attribute mail regex ^[:alnum:]+@mydomain.com$ should be constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ And similar in http://www.openldap.org/doc/admin24/overlays.html#Constraints

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs