- openldap-bugs - openldap.org

Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by ghenry＠suretecsystems.com 22 May '07

22 May '07

<quote who="hyc(a)symas.com"> > ahasenack(a)terra.com.br wrote: >> On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: >>> draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: >>> >>> "A 000001010000Z value means that the account has been locked >>> permanently, and >>> that only a password administrator can unlock the account." >>> >>> But pwdAccountLockedTime doesn't use integerMatch, so an example of the >>> above >>> syntax is needed with anything that has a generalizedTimeMatch. I think >>> pwdAccountLockedTime is the only one? >> >> The slapo-ppolicy(5) manpage is actually misleading. It implies that >> the value is a plain zero, which doesn't work: >> "If pwdAccountLockedTime is set to zero (0), the user's account (...)" > > That text in the manpage came from an earlier revision of the ppolicy > draft; it just wasn't updated when the meaning was clarified in a later > draft version. Looks like Gavin has fixed it in HEAD now. Yes, sorry. I thought silence meant it was ok to go ahead. This is my first ever commit, so I'll be a bit more patient next time ;-) Thanks. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > >

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by ando＠sys-net.it 22 May '07

22 May '07

nvoutsin(a)noc.uoa.gr wrote: > While slapd does not segfault anymore, slapd insists to concatenate > unrelated database suffixes during search operations that look for attrs > such as hasSubordinates. > > I mention this here because it seems to be related somehow As I could see it working as expected (by me, at least), I suggest you cook a very simple example, consisting in two slapd.conf (one for the remote server, and one for the offending mixed local-proxy-relay setup), and as many data in LDIF format and submit it, so that you can show what you consider an incorrect behavior. Otherwise, I don't see any further indication of a bug. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by krause＠biochem.mpg.de 22 May '07

22 May '07

I have downloaded the cvs version (2007-05-21) and built it, but get, as it seems related to something else, a segfault. i reproduced this trice. what i did: (just to be sure i did not make a fatal mistake) * fetched cvs * ran configure with the following command line: env CPPFLAGS=-I/usr/include/db42 ./configure --enable-wrappers --enable-aclgroups --enable-spasswd --enable-modules --enable-shared --enable-dynamic --with-tls --with-cyrus-sasl --enable-crypt --enable-aci --enable-bdb --enable-hdb --enable-ldbm --enable-rewrite --enable-ldap=yes --enable-meta=mod --enable-monitor=yes --enable-perl=mod --enable-slp --enable-overlays=yes --enable-lmpasswd --with-yielding-select --enable-debug=yes i had to install the development package for BDB 4.2 (although the rpm from opensuse has it built with BDB 4.3, also i could not reuse the existing ldap db) * then make depend; make; make test -> all tests succeded (as far is i can tell) * gdb openldap/servers/slapd/.libs/slapd run -h ldap:/// ldaps:/// -g ldap -u ldap -d 65535 as the "local" ldap db on this consumer is empty the replication starts (reproduced after segfault and removal of the direcory contents): [lot of debugging output, and finally:] entry_decode: "cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de" <= entry_decode(cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de) => test_filter PRESENT => access_allowed: search access to "cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 nonpresent_callback: rid=013 got UUID 1f1b0732-9823-102b-8c9e-b3c3d9320a55, dn cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" bdb_modify: dc=biochem,dc=mpg,dc=de bdb_dn2entry("dc=biochem,dc=mpg,dc=de") entry_decode: "dc=biochem,dc=mpg,dc=de" <= entry_decode(dc=biochem,dc=mpg,dc=de) bdb_modify_internal: 0x00000001: dc=biochem,dc=mpg,dc=de <= acl_access_allowed: granted to database root bdb_modify_internal: add contextCSN => entry_encode(0x00000001): dc=biochem,dc=mpg,dc=de bdb_modify: updated id=00000001 dn="dc=biochem,dc=mpg,dc=de" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225942112 (LWP 19016)] slap_dup_sync_cookie (dst=0x8283400, src=0xb6ed8cf0) at ldapsync.c:327 327 new->sids[i] = src->sids[i]; the backtrace says: (gdb) bt #0 slap_dup_sync_cookie (dst=0x8283400, src=0xb6ed8cf0) at ldapsync.c:327 #1 0x080c83fd in syncrepl_updateCookie (si=0x8283310, op=0xb6ed8e7c, pdn=<value optimized out>, syncCookie=0xb6ed8cf0) at syncrepl.c:2615 #2 0x080ced95 in do_syncrep2 (op=0xb6ed8e7c, si=0x8283310) at syncrepl.c:1016 #3 0x080cffbc in do_syncrepl (ctx=0xb6ed92d8, arg=0x8282d60) at syncrepl.c:1161 #4 0x08074c0a in connection_read_thread (ctx=0xb6ed92d8, argv=0x11) at connection.c:1273 #5 0xb7f5f7f2 in ldap_int_thread_pool_wrapper (xpool=0x821ff08) at tpool.c:725 #6 0xb7c4134b in start_thread () from /lib/libpthread.so.0 #7 0xb7bd965e in clone () from /lib/libc.so.6 (gdb) after this it also segfaults if started again : [lot of debugging output, and finally:] do_syncrep2: rid=013 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT ber_scanf fmt (t{) ber: ber_dump: buf=0x08312178 ptr=0x08312178 end=0x083121a8 len=48 0000: a2 2e 04 2c 63 73 6e 3d 32 30 30 37 30 35 31 36 ...,csn=20070516 0010: 31 38 30 30 34 38 5a 23 30 30 30 30 36 35 23 30 180048Z#000065#0 0020: 30 23 30 30 30 30 30 30 2c 72 69 64 3d 30 31 33 0#000000,rid=013 ber_scanf fmt (m) ber: ber_dump: buf=0x08312178 ptr=0x0831217a end=0x083121a8 len=46 0000: 04 2c 63 73 6e 3d 32 30 30 37 30 35 31 36 31 38 .,csn=2007051618 0010: 30 30 34 38 5a 23 30 30 30 30 36 35 23 30 30 23 0048Z#000065#00# 0020: 30 30 30 30 30 30 2c 72 69 64 3d 30 31 33 000000,rid=013 ber_scanf fmt (}) ber: ber_dump: buf=0x08312178 ptr=0x083121a8 end=0x083121a8 len=0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1235027040 (LWP 23928)] compare_csns (sc1=0xb662ecd0, sc2=0xb662ecf0, which=0xb662ede4) at syncrepl.c:647 647 if ( sc1->sids[i] != sc2->sids[j] ) backtrace says this time: (gdb) bt #0 compare_csns (sc1=0xb662ecd0, sc2=0xb662ecf0, which=0xb662ede4) at syncrepl.c:647 #1 0x080ced4c in do_syncrep2 (op=0xb662ee7c, si=0x82832b0) at syncrepl.c:1005 #2 0x080cffbc in do_syncrepl (ctx=0xb662f2d8, arg=0x8282d00) at syncrepl.c:1161 #3 0x08074c0a in connection_read_thread (ctx=0xb662f2d8, argv=0x11) at connection.c:1273 #4 0xb7eb67f2 in ldap_int_thread_pool_wrapper (xpool=0x821ff08) at tpool.c:725 #5 0xb7b9834b in start_thread () from /lib/libpthread.so.0 #6 0xb7b3065e in clone () from /lib/libc.so.6 * the configuration on the provider and the consumer were left untouched (except path corrections) to the until now running without errors rpm-version 2.3.34, the old rpms have been removed (using rpm -e) did i make something wrong or did i hit another bug?? regards markus Zitat von Pierangelo Masarati <ando(a)sys-net.it>: > This is now completely fixed in HEAD; I need to check any issue related > to backporting to re23, for quick release. Please test. Thanks for > reporting, p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > +-----------------------------------------------------------------+ | Markus Krause, Mogli-Soft | | Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL | | by order of the | | Computing Center of the Max-Planck-Institute of Biochemistry | +--------------------------------+--------------------------------+ | E-Mail: krause(a)biochem.mpg.de | Tel.: 089 - 89 40 85 99 | | markus.krause(a)mac.com | Fax.: 089 - 89 40 85 98 | | Skype: markus.krause | iChat: markus.krause(a)mac.com | +--------------------------------+--------------------------------+ ---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux(a)biochem.mpg.de

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr 22 May '07

22 May '07

While slapd does not segfault anymore, slapd insists to concatenate unrelated database suffixes during search operations that look for attrs such as hasSubordinates. I mention this here because it seems to be related somehow Pierangelo Masarati wrote: > nvoutsin(a)noc.uoa.gr wrote: > >> As ando already said: >> .....it tries to lookup a database to relay for when unbinding, >> but unbind has no DN, so a strcmp on NULL is performed. This does not >> happen when using the "relay" directive because relay database selection >> does not occur for each operation.... > > Technically, the bug is now fixed in HEAD/re23 (please test). > Concerning the issue initially raised on the -software list, which seems > to be open yet, see discussion on the list. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > >

1 0

Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by hyc＠symas.com 22 May '07

22 May '07

ahasenack(a)terra.com.br wrote: > On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: >> draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: >> >> "A 000001010000Z value means that the account has been locked permanently, and >> that only a password administrator can unlock the account." >> >> But pwdAccountLockedTime doesn't use integerMatch, so an example of the above >> syntax is needed with anything that has a generalizedTimeMatch. I think >> pwdAccountLockedTime is the only one? > > The slapo-ppolicy(5) manpage is actually misleading. It implies that > the value is a plain zero, which doesn't work: > "If pwdAccountLockedTime is set to zero (0), the user's account (...)" That text in the manpage came from an earlier revision of the ppolicy draft; it just wasn't updated when the meaning was clarified in a later draft version. Looks like Gavin has fixed it in HEAD now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by ahasenack＠terra.com.br 22 May '07

22 May '07

On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: > draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: > > "A 000001010000Z value means that the account has been locked permanently, and > that only a password administrator can unlock the account." > > But pwdAccountLockedTime doesn't use integerMatch, so an example of the above > syntax is needed with anything that has a generalizedTimeMatch. I think > pwdAccountLockedTime is the only one? The slapo-ppolicy(5) manpage is actually misleading. It implies that the value is a plain zero, which doesn't work: "If pwdAccountLockedTime is set to zero (0), the user's account (...)"

1 0

(ITS#4979) Bad response when requesting bad attributes
by elecharny＠apache.org 22 May '07

22 May '07

Full_Name: Emmanuel Lecharny Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.236.207.89) When searching for entries using attributes to filter the result, you get all the entries attributes if you give a wrong attribute : ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b "dc=example,dc=com" -s sub "(objectClass=*)" 9.9.9 will correctly returns only the DNs of all found entries, as if the 9.9.9 attribute was 1.1 but ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b "dc=example,dc=com" -s sub "(objectClass=*)" person will return all entries attributes, as if the 'person' was substituted by "*" Of course, 'person' is not an attribute, but an objectClass, but the user intent was to get only one single attribute value, so I don't think that returning everything is correct. This is obviously not a serious issue.

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it 21 May '07

21 May '07

richton(a)nbcs.rutgers.edu wrote: >>> * config_filename could be passed to rad_config without initialization (when >>> accepting the default). >> rejected: global variables are always zeroed. > > Hmmmm. I agree that a static pointer variable should be NULL, but it's > definitely not what I'm seeing in dbx. I'll try and take it up with the > Sun Studio people... If that's an issue, I have no problem in explicitly setting that pointer to NULL. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 21 May '07

21 May '07

>> * config_filename could be passed to rad_config without initialization (when >> accepting the default). > > rejected: global variables are always zeroed. Hmmmm. I agree that a static pointer variable should be NULL, but it's definitely not what I'm seeing in dbx. I'll try and take it up with the Sun Studio people... The rest looks OK, thanks.

1 0

Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by digant＠stanford.edu 21 May '07

21 May '07

Nothing that useful i could find: $4 = { sml_mod = { sm_op = 1, sm_flags = 0, sm_desc = 0x2aedc50244d0, sm_type = { bv_len = 20, bv_val = 0x2aabae9df741 "suorgcontactstanford" }, sm_values = 0x0, sm_nvalues = 0x0 }, sml_next = 0x2aaaaaaf4ee0 }

1 0

(ITS#4978) slapo-ppolicy.5 and missing Zero value example
by ghenry＠OpenLDAP.org 21 May '07

21 May '07

Full_Name: Gavin Henry Version: 2.3.35 and HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: "A 000001010000Z value means that the account has been locked permanently, and that only a password administrator can unlock the account." But pwdAccountLockedTime doesn't use integerMatch, so an example of the above syntax is needed with anything that has a generalizedTimeMatch. I think pwdAccountLockedTime is the only one? Please correct me if I'm wrong, otherwise I'll update the man page. Thanks, Gavin.

1 0

(ITS#4977) check parse_sync_cookie return in syncprov overlay
by donn＠u.washington.edu 21 May '07

21 May '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: Submission from: (NULL) (128.95.135.150) Control from 2.3.24 syncrepl client fails "sid=" parse in slap_parse_sync_cookie(), but return -1 is ignored, in syncprov_parseCtrl() ca. line 2770. slapd crashes in syncprov_op_search ca. line 2106, because srs->sr_state.sids is null. Reproduce by sending control with invalid "sid=" value. That might be any 2.3 client, or there may be something else whacked here. Client configured refreshAndPersist. I added a check for negative return value to the check for negative rid. Result is "err=2 nentries=0 text=Sync control : cookie parsing error", ... "do_search: get_ctrls failed", which I assume is good. At least, it doesn't crash.

1 0

Re: (ITS#4975) --without-tls is broken
by hyc＠symas.com 21 May '07

21 May '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >>> I haven't kept track of the TLS changes though, so I don't know if just >>> moving #ifdefs around is the right fix. >> As far as I understood it, the rationale of those changes was to be able >> to handle, and significantly parse certificates, independently of any TLS >> capability (including when no TLS is available). If you find a >> combination of #ifdef's that gives this, then it should be the right one. > > Your understanding is correct. I can sort this out if you haven't already. > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 21 May '07

21 May '07

ali.pouya(a)free.fr wrote: > Hi Pierangelo; > I tested with HEAD (checked out on Sunday Mai 20) but the problem is > the same : To configure the Monitor database I have to grant read acces > to *. Can you post your slapd.conf? 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 21 May '07

21 May '07

Hi Pierangelo; I tested with HEAD (checked out on Sunday Mai 20) but the problem is the same : To configure the Monitor database I have to grant read acces to *. I confirm that I do not have a default rootdn for Monitor. Best Regards Ali

1 0

Re: (ITS#4976) memory corruption in test008-concurrency
by hyc＠symas.com 20 May '07

20 May '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Slapd sometimes crashes with memory corruption in test008-concurrency. Try using ElectricFence, with my pthread patches. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4976) memory corruption in test008-concurrency
by h.b.furuseth＠usit.uio.no 20 May '07

20 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Slapd sometimes crashes with memory corruption in test008-concurrency. ./configure LIBS="-lmcheck" (a glibc memory checking library) provokes the bug regularly: it dumps core after reporting "memory clobbered before allocated block" somewhere in the test output. It still happens with no avoidable non-OpenLDAP packages (testing with back-null or back-ldif): bash$ ./configure --disable-backends --enable-null --disable-overlays \ --without-cyrus-sasl --without-tls --quiet LIBS="-lmcheck" "configure --without-threads" seems to prevent the crash, so I presume it's thread-related. So far, Valgrind has prevented it too:-( If someone has Purify, maybe that can find it. Patch needed to test with back-null: --- tests/data/slapd.conf~ 2007-01-06 20:35:00 +0100 +++ tests/data/slapd.conf 2007-05-19 19:45:23 +0200 @@ -40,3 +40,6 @@ suffix "dc=example,dc=com" -directory @TESTDIR@/db.1.a +#bdb#directory @TESTDIR@/db.1.a +#hdb#directory @TESTDIR@/db.1.a +#ldif#directory @TESTDIR@/db.1.a +#null#bind on rootdn "cn=Manager,dc=example,dc=com" --- tests/scripts/acfilter.sh~ 2007-01-06 20:35:00 +0100 +++ tests/scripts/acfilter.sh 2007-05-19 20:01:19 +0200 @@ -15,4 +15,5 @@ # -# Strip comments +# Strip comments, or remove everything with back-null # -grep -v '^#' + +test "$BACKEND" = "null" || grep -v '^#' Test loop: cd tests try() { ulimit -c unlimited echo ./run -b $1 test008 nice ./run -b $1 test008 && test "`echo core*`" = "core*" } (declare -i n=0; while try null && try ldif; do n=$n+1; echo "#$n done"; done) I don't see anything from the backtraces, they report when the problem is noticed instead of when it is created. E.g.: #0 0x0039e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x003df7a5 in raise () from /lib/tls/libc.so.6 #2 0x003e1209 in abort () from /lib/tls/libc.so.6 #3 0x00413a1a in __libc_message () from /lib/tls/libc.so.6 #4 0x00413a54 in __libc_fatal () from /lib/tls/libc.so.6 #5 0x0041fddf in mabort () from /lib/tls/libc.so.6 #6 0x0041f655 in freehook () from /lib/tls/libc.so.6 #7 0x0041a5e5 in free () from /lib/tls/libc.so.6 #8 0x080fea27 in ber_bvarray_free (a=0x0) at memory.c:744 #9 0x0806a34e in attr_clean (a=0x4dfff4) at attr.c:134 #10 0x0806a454 in attrs_free (a=0x8e56204) at attr.c:194 #11 0x0806b0c9 in entry_clean (e=0x8e4bdd4) at entry.c:473 #12 0x0806b142 in entry_free (e=0x8e4bdd4) at entry.c:483 #13 0x0806e898 in be_entry_release_rw (op=0x8e84c78, e=0x8e4bdd4, rw=6) at backend.c:797 #14 0x08069221 in do_add (op=0x8e84c78, rs=0xb59fe154) at add.c:197 #15 0x080626e7 in connection_operation (ctx=0xb59fe228, arg_v=0x8e84c78) at connection.c:1145 #16 0x08062d44 in connection_read_thread (ctx=0xb59fe228, argv=0xa) at connection.c:1271 #17 0x080dc75a in ldap_int_thread_pool_wrapper (xpool=0x8e04fe8) at tpool.c:725 #18 0x006193cc in start_thread () from /lib/tls/libpthread.so.0 #19 0x00480c3e in clone () from /lib/tls/libc.so.6

1 0

Re: (ITS#4975) --without-tls is broken
by h.b.furuseth＠usit.uio.no 20 May '07

20 May '07

Fixed in HEAD. -- Regards, Hallvard

1 0

Re: (ITS#4975) --without-tls is broken
by hyc＠symas.com 20 May '07

20 May '07

ando(a)sys-net.it wrote: >> I haven't kept track of the TLS changes though, so I don't know if just >> moving #ifdefs around is the right fix. > > As far as I understood it, the rationale of those changes was to be able > to handle, and significantly parse certificates, independently of any TLS > capability (including when no TLS is available). If you find a > combination of #ifdef's that gives this, then it should be the right one. Your understanding is correct. I can sort this out if you haven't already. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4975) --without-tls is broken
by ando＠sys-net.it 20 May '07

20 May '07

> I haven't kept track of the TLS changes though, so I don't know if just > moving #ifdefs around is the right fix. As far as I understood it, the rationale of those changes was to be able to handle, and significantly parse certificates, independently of any TLS capability (including when no TLS is available). If you find a combination of #ifdef's that gives this, then it should be the right one. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4975) --without-tls is broken
by h.b.furuseth＠usit.uio.no 20 May '07

20 May '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard slapd/schema_init.c:certificateExactNormalize() (outside HAVE_TLS) needs slapd/dn.c:dnX509normalize() (inside HAVE_TLS). The latter uses libldap/tls.c:ldap_X509dn2bv() (outside HAVE_TLS), which needs oid_name oids[] (inside HAVE_TLS). If those are all moved outside HAVE_TLS, test021-certificate still fails: Running ./scripts/test021-certificate... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing certificate handling... Add certificates... ldapmodify failed (18)! ...because certificateExactNormalize() isn't used (the certificateExactMatch syntax #ifdef HAVE_TLS'es it out). It passes if that #ifdef is removed too. I haven't kept track of the TLS changes though, so I don't know if just moving #ifdefs around is the right fix.

1 0

(ITS#4974) tls calls ldap_pvt_thread_self with wrong prototype
by h.b.furuseth＠usit.uio.no 20 May '07

20 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard libldap/tls.c calls CRYPTO_set_id_callback(ldap_pvt_thread_self), which causes ldap_pvt_thread_self to be called with the wrong prototype. That can cause OpenSSL to use a garbage value, e.g. if the unsigned long it expects takes two words but ldap_pvt_thread_t is an int. I'm fixing it in HEAD now and also inserting a check for whether ldap_pvt_thread_t fits in an unsigned long. Maybe the latter should go in configure, but since OpenSSL presumably breaks anyway if that fails I don't see much point at this time.

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by ando＠sys-net.it 19 May '07

19 May '07

nvoutsin(a)noc.uoa.gr wrote: > As ando already said: > .....it tries to lookup a database to relay for when unbinding, > but unbind has no DN, so a strcmp on NULL is performed. This does not > happen when using the "relay" directive because relay database selection > does not occur for each operation.... Technically, the bug is now fixed in HEAD/re23 (please test). Concerning the issue initially raised on the -software list, which seems to be open yet, see discussion on the list. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by ando＠sys-net.it 19 May '07

19 May '07

This is now completely fixed in HEAD; I need to check any issue related to backporting to re23, for quick release. Please test. Thanks for reporting, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4973) Inconsistent initialization of internal modifications
by ando＠sys-net.it 19 May '07

19 May '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando While fixing slapo-chain(5) handling of passmods, I stumbled into an inconsistent initialization of internal modifications. What happens is that in most cases the Operation structure used for internal operations is either directly the structure passed to the function that performs the internal operation, or a copy of it, something like Operation op2 = *op; The oq_modify.rs_modlist member now contains an orm_no_opattrs field which, if non-zero, inhibits the modification of operational attributes, and thus indirectly breaks replication. I've fixed the occurrence in passwd_extop(), but the code is full of internal modifications that might need care. p.

1 0

Re: (ITS#4078) test001 fails on sparcv9
by h.b.furuseth＠usit.uio.no 18 May '07

18 May '07

I've updated and applied a patch I had lying around for this one: Give OperationBuffer struct members instead of using LBER_ALIGNED_BUFFER. -- Regards, Hallvard

1 0

Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by ando＠sys-net.it 18 May '07

18 May '07

digant(a)stanford.edu wrote: > When modding an entry, valsort seems to have crashed the server. I've uploaded > the stack trace and informaiton I was able to gather out of the core dump. In your upload: > #0 valsort_modify (op=0x2aabaeac0058, rs=0x417fef10) at valsort.c:455 > 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { can you detail what operation caused this? Can you print: ml, i, ml->sml_mod.sm_values, ml->sml_mod.sm_values[i] ? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 18 May '07

18 May '07

ali.pouya(a)free.fr wrote: > The HEAD misses the definition of 'oids' 'oid_name', etc. So I get the following > error at build time : You probably caught HEAD in some inconsistent state during the addition of GNUTLS support; it's working just fine for me. Can you 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4961) If database suffix is ""
by ando＠sys-net.it 18 May '07

18 May '07

ali.pouya(a)free.fr wrote: > Unfortunately the problem has not been completely fixed in the HEAD. > With the fix in the head the error message disappears but the contextCSN ins NOT > ACTUALLY written to the disk. So at the next slapd startup the ContextCSN is > missing. An the servers hav to resynchronize. > > Below you find the log extract. Makes sense: the empty entry "" is not persistent... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4971) patch for OpenLDAP 2-3-32
by ando＠sys-net.it 18 May '07

18 May '07

jemeterisan(a)mail.ru wrote: > I had noticed, that the patch, used for 'schema-map.c' doesn't work > correct. I hope, You also had checked it up. So what had I found in > the function 'backsql_ad2at': > The attribute name is stored in 'struct berval' structure, so if > You change '.bv_val' from 'userCertificate;binary' to > 'userCertificate', You should change '.bv_len' in accordance to > strlen(aaa.bv_val) without strlen(";binary"). I assume you refer to a patch that was submitted along with ITS#4868; that patch is absolutely incorrect and in fact it has been rejected. A consistent fix has been applied to hEAD code. It has never been backported to OpenLDAP 2.3 because nobody fed back about it. If you wish to test HEAD code and report success, I'll be happy to backport it to OpenLDAP 2.3 so that it gets released with the next release. > And by the way I want to store 'userCertificate' attribute type in PostrgreSQL. > > What type of the field in the table should I use? Any blob-like format would be fine (although I haven't tested it with PostgreSQL yet). > Just another question to the developers: > I've heared that OpenLDAP is sensible to DOS attacks, so, how can I avoid this > trouble? And I want to know more about this problem, if possible. Please direct software use related questions to the openldap-software mailing list. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4972) thr_debug problems
by h.b.furuseth＠usit.uio.no 18 May '07

18 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard $LDAP_THREAD_DEBUG parsing is bogus, code in the inner loop should be outside it. Detached threads can validly exit after ldap_debug_thread_destroy() (fixed in HEAD). Valgrind carries the 'uninialized' state out of debug_already_initialized(). RE23/thr_debug.c has some other problems that are fixed in HEAD, but take a bit more work to fix and test. I'll align it with HEAD if anyone is interested.

1 0

Re: (ITS#4961) If database suffix is ""
by ali.pouya＠free.fr 18 May '07

18 May '07

Unfortunately the problem has not been completely fixed in the HEAD. With the fix in the head the error message disappears but the contextCSN ins NOT ACTUALLY written to the disk. So at the next slapd startup the ContextCSN is missing. An the servers hav to resynchronize. Below you find the log extract. Thanks Best regards Ali ============================ Log extract : daemon: shutdown requested and initiated. daemon: closing 7 connection_closing: readying conn=0 sd=11 for close connection_close: conn=0 sd=11 daemon: removing 11 conn=0 fd=11 closed (slapd shutdown) =>do_syncrepl rid=123 connection_get(12) connection_get(12): got connid=0 daemon: removing 12r slapd shutdown: waiting for 1 threads to terminate ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed slapd shutdown: initiated bdb_modify: bdb_dn2entry("") bdb_modify_internal: 0x00000000: <= acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN is_entry_objectclass("", "2.5.17.0") no objectClass attribute => entry_encode(0x00000000): bdb_modify: updated id=00000000 dn="" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" ====> bdb_cache_release_all slapd destroy: freeing system resources. slapd stopped.

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 18 May '07

18 May '07

Hi Pierangelo; The HEAD misses some new definitions (see followup 5 in ITS 4959) so I reproduced the problem with OPENLDAP_REL_ENG_2_4. I feel that the problem has not been fixed in this release. Thanks and best regards Ali

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr 18 May '07

18 May '07

Hi Pierangelo; The HEAD misses some new definitions (see below) so I reproduced the problem with OPENLDAP_REL_ENG_2_4. The backtrace is the same as before : #0 0x00179d5a in strcmp () from /lib/tls/libc.so.6 #1 0x08068ede in select_backend (dn=0xb78bef5c, manageDSAit=0, noSubs=0) at backend.c:684 #2 0x0806a8ac in fe_aux_operational (op=0xb78bef40, rs=0xb78bee80) at backend.c:1779 #3 0x0806a01b in backend_operational (op=0xb78bef40, rs=0xb78bee80) at backend.c:1801 #4 0x080a7d06 in do_syncrepl (ctx=0xb78bf2a0, arg=0x88ab2e0) at syncrepl.c:547 #5 0x081281c3 in ldap_int_thread_pool_wrapper (xpool=0x886fd78) at tpool.c:704 #6 0x00907371 in start_thread () from /lib/tls/libpthread.so.0 #7 0x001d8ffe in clone () from /lib/tls/libc.so.6 =============== N.B. The HEAD misses the definition of 'oids' 'oid_name', etc. So I get the following error at build time : tls.c:2908: error: syntax error before '*' token tls.c: In function `find_oid': tls.c:2913: error: `oids' undeclared (first use in this function) tls.c:2913: error: (Each undeclared identifier is reported only once tls.c:2913: error: for each function it appears in.) tls.c: In function `ldap_X509dn2bv': tls.c:2946: error: `oid_name' undeclared (first use in this function) tls.c:2946: error: `oidname' undeclared (first use in this function) make[2]: *** [tls.lo] Erreur 1 make[2]: Leaving directory `/var/ali/openldap-2.4/head-170507/libraries/libldap' make[1]: *** [all-common] Erreur 1 make[1]: Leaving directory `/var/ali/openldap-2.4/head-170507/libraries' make: *** [all-common] Erreur 1 Thanks Best Regards Ali

1 0

(ITS#4971) patch for OpenLDAP 2-3-32
by jemeterisan＠mail.ru 18 May '07

18 May '07

Full_Name: Petrov Dmitry Version: 2-3-32 OS: Red Hat 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.195.208.66) Hi, guys! I had noticed, that the patch, used for 'schema-map.c' doesn't work correct. I hope, You also had checked it up. So what had I found in the function 'backsql_ad2at': The attribute name is stored in 'struct berval' structure, so if You change '.bv_val' from 'userCertificate;binary' to 'userCertificate', You should change '.bv_len' in accordance to strlen(aaa.bv_val) without strlen(";binary"). And by the way I want to store 'userCertificate' attribute type in PostrgreSQL. What type of the field in the table should I use? Just another question to the developers: I've heared that OpenLDAP is sensible to DOS attacks, so, how can I avoid this trouble? And I want to know more about this problem, if possible. With best wishes, Dmitry...

1 0

(ITS#4970) Problem between pwdReset and pwdMinAge
by py.bonnetain＠ba-consultants.fr 17 May '07

17 May '07

Full_Name: Pierre-Yves Bonnetain Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.162.162) There is something "forgotten" in ppolicy overlay code. When pwdReset is set to TRUE, the user is properly asked to change his password. BUT if the (admin-made) previous password change is newer than pwdMinAge, the requested password change will be rejected with a "password too young" message : ----------- $ ssh somehost -l someuser Password: You are required to change your LDAP password immediately. Enter login(LDAP) password: New UNIX password: Retype new UNIX password: LDAP password information update failed: Constraint violation Password is too young to change ----------- The pwdMinAge parameter should be ignored when pwdReset is set, otherwise the user will effectively be locked out of his account while waiting for the minimum delay to expire. Here is a patch to correct this behavior. Proposed patch may not adhere to coding standards and such, so feel free to enhance it as needed . *** ppolicy.old 2007-02-08 13:31:24.000000000 +0100 --- ppolicy.c 2007-05-17 17:10:39.000000000 +0200 *************** *** 1696,1710 **** time_t pwtime = (time_t)-1, now; int age; ! if ((pa = attr_find( e->e_attrs, ad_pwdChangedTime )) != NULL) ! pwtime = parse_time( pa->a_nvals[0].bv_val ); ! now = slap_get_time(); ! age = (int)(now - pwtime); ! if ((pwtime != (time_t)-1) && (age < pp.pwdMinAge)) { ! rs->sr_err = LDAP_CONSTRAINT_VIOLATION; ! rs->sr_text = "Password is too young to change"; ! pErr = PP_passwordTooYoung; ! goto return_results; } } --- 1696,1716 ---- time_t pwtime = (time_t)-1, now; int age; ! /* Py Bonnetain, B&A Consultants : We DON'T CARE for minAge if pwdReset ! is set. */ ! if ((pa = attr_find( e->e_attrs, ad_pwdReset )) == NULL || ! ! bvmatch( &pa->a_nvals[0], &slap_true_bv) ) { ! ! if ((pa = attr_find( e->e_attrs, ad_pwdChangedTime )) != NULL) ! pwtime = parse_time( pa->a_nvals[0].bv_val ); ! now = slap_get_time(); ! age = (int)(now - pwtime); ! if ((pwtime != (time_t)-1) && (age < pp.pwdMinAge)) { ! rs->sr_err = LDAP_CONSTRAINT_VIOLATION; ! rs->sr_text = "Password is too young to change"; ! pErr = PP_passwordTooYoung; ! goto return_results; ! } } }

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 17 May '07

17 May '07

ali.pouya(a)free.fr wrote: > If I include the monitor back-end in my configuration I have to add the > following access rule as well : > > access to dn.sub="cn=monitor" by * read > > Otherwise slapd stops with the log reproduced below (my access rules include > "access to * by * none"). The problem is already fixed in HEAD: slapd starts, although it cannot register back-bdb monitor stuff unless a roodn is defined in the monitor backend. FFT: maybe the monitor database could have a default rootdn "cn=Monitor", much like the config database? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4968) acl problem
by ando＠sys-net.it 17 May '07

17 May '07

zeaal_3(a)yahoo.com wrote: > Full_Name: dhiren > Version: 2.2 > OS: fedora4 > URL: > Submission from: (NULL) (203.88.149.100) > > > when i enable following acl , user not able to login client side:- > > access to attrs=userPassword > by self write > by anonymous auth > by * none > > whts problem? when disable this acl user can login. Please direct software usage questions to the openldap-software list; or, just read the first few lines of slapd.conf(5) and find the answer yourself. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4969) globalization missing is com.novell.ldap.resources package
by viral_barot＠persistent.co.in 17 May '07

17 May '07

Full_Name: viral barot Version: 2.3 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.225.70.2) It is found that package com.novell.ldap.resources does not include many language files for globalization support. This package contains only english and spanish (ResultCodeMessages.java and ResultCodeMessages_es.java) and other language files are missing. It would be fine if following files are included. ResultCodeMessages_ja.java ResultCodeMessages_ko.java ResultCodeMessages_it.java ResultCodeMessages_fr.java ResultCodeMessages_de.java ResultCodeMessages_pt_BR.java ResultCodeMessages_zh_CN.java ResultCodeMessages_zh_TW.java Thanks.

1 0

(ITS#4968) acl problem
by zeaal_3＠yahoo.com 17 May '07

17 May '07

Full_Name: dhiren Version: 2.2 OS: fedora4 URL: Submission from: (NULL) (203.88.149.100) when i enable following acl , user not able to login client side:- access to attrs=userPassword by self write by anonymous auth by * none whts problem? when disable this acl user can login.

1 0

(ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by digant＠stanford.edu 16 May '07

16 May '07

Full_Name: Digant C Kasundra Version: 2.3.35 OS: Debian 3.1 URL: ftp://ftp.openldap.org/incoming/digant-kasundra-20070516.txt Submission from: (NULL) (171.64.18.9) When modding an entry, valsort seems to have crashed the server. I've uploaded the stack trace and informaiton I was able to gather out of the core dump.

1 0

(ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 16 May '07

16 May '07

Full_Name: Ali Pouya Version: 2.2.4alpha OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) If I include the monitor back-end in my configuration I have to add the following access rule as well : access to dn.sub="cn=monitor" by * read Otherwise slapd stops with the log reproduced below (my access rules include "access to * by * none"). I can send more information if required. Thanks and best regards Ali ============================================= Log extract : >>> dnPretty: <c=fr> => ldap_bv2dn(c=fr,0) <= ldap_bv2dn(c=fr)=0 => ldap_dn2bv(272) <= ldap_dn2bv(c=fr)=0 <<< dnPretty: <c=fr> >>> dnNormalize: <c=fr> => ldap_bv2dn(c=fr,0) <= ldap_bv2dn(c=fr)=0 => ldap_dn2bv(272) <= ldap_dn2bv(c=fr)=0 <<< dnNormalize: <c=fr> end get_filter 0 => monitor_back_search => access_allowed: search access to "cn=Databases,cn=Monitor" "entry" requested => acl_get: [2] attr entry => acl_mask: access to entry "cn=Databases,cn=Monitor", attr "entry" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: cn=admin,ou=internal,ou=min,o=gouv,c=fr <= check a_dn_pat: cn=connecteur,ou=internal,ou=min,o=gouv,c=fr <= check a_dn_pat: cn=sync,ou=internal,ou=min,o=gouv,c=fr <= check a_dn_pat: ou=applications,ou=external,ou=min,o=gouv,c=fr <= check a_dn_pat: * <= acl_mask: [5] applying none(=0) (stop) <= acl_mask: [5] mask: none(=0) => slap_access_allowed: search access denied by none(=0) => access_allowed: no more rules send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=32 matched="" text="" monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=c=fr)": unable to find entry ====> bdb_cache_release_all backend_startup_one: bi_db_open failed! (-1) slapd shutdown: initiated ====> bdb_cache_release_all bdb_db_close: alock_close failed slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.

1 0

Re: Re: (ITS#4960) the memory increase qu ickly and not can be released sometime.
by hoverwf＠126.com 15 May '07

15 May '07

--Boundary-=_xCXZRVEUxxIpjyEYhiCoTxWoOQsJ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit hi Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> thanks, this is the reason why the memory increase. Pierangelo Masarati ando(a)sys-net.it sorry, next time i will surely discussion it on the OpenLDAP-software mailing list. --Boundary-=_xCXZRVEUxxIpjyEYhiCoTxWoOQsJ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <DIV>      </DIV> <DIV>hi Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no><BR> <DIV>           &n= bsp;    thanks,  this is the reason why the memory in= crease.  </DIV></DIV> <DIV> </DIV> <DIV> </DIV> <DIV>Pierangelo Masarati <A href=3D"mailto:ando@sys-net.it">ando(a)sys-net.= it</A></DIV> <DIV>           &n= bsp;    sorry,  next time i will surely discussi= on it on the OpenLDAP-software mailing list.</DIV> <DIV> </DIV><br><br><hr> <a style=3D"font-size:14px;line-height:15px; color:#000; text-decoration:= none" href=3D"http://event.mail.163.com/chanel/xyq.htm?from=3D126" target= =3D"_blank"><span style=3D"text-decoration:underline; color:blue">=C3=E2=B7= =D1=CA=D4=CD=E62006=D6=D0=B9=FA=D7=EE=BC=D1=CD=F8=C2=E7=D3=CE=CF=B7--=C3=CE= =BB=C3=CE=F7=D3=CE </span> </a> --Boundary-=_xCXZRVEUxxIpjyEYhiCoTxWoOQsJ--

1 0

Re: (ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by ando＠sys-net.it 15 May '07

15 May '07

krause(a)biochem.mpg.de wrote: > changing the the ldap password using "ldappasswd" from the command line using > the following slapd.conf on a consumer (only relevant part) crashes the server > with a "segmentation fault": The crash is now fixed in HEAD (a NULL pointer was parsed out of the referral's DN, since formally no request DN is available in that exop). However, although the password modify now is correctly resent to the producer, the consumer does not get updated. Investigating... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by krause＠biochem.mpg.de 15 May '07

15 May '07

Full_Name: Markus Krause Version: openldap2-2.3.34-5.2 OS: SuSE Llinux Enterprise Server 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.56.13.40) changing the the ldap password using "ldappasswd" from the command line using the following slapd.conf on a consumer (only relevant part) crashes the server with a "segmentation fault": ... modulepath /usr/lib/openldap/modules moduleload smbk5pwd.so sizelimit unlimited acl ... TLSstuff ... #### chain overlay definition overlay chain chain-rebind-as-user FALSE chain-uri "ldaps://ldapprov" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=manager,o=test" credentials="secret" mode="self" database bdb suffix "o=test" directory /var/lib/ldap/ rootdn "cn=manager,o=test" rootpw "secret" index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index entryCSN,entryUUID eq index dhcpHWAddress eq,pres index relativeDomainName eq,pres index ipHostNumber eq,pres index zoneName eq,pres index radiusGroupName eq,pres syncrepl rid=13 provider=ldaps://ldapprov type=refreshAndPersist retry=1,5,5,6,30,+ interval=00:00:00:30 searchbase="o=test" filter="(objectclass=*)" scope=sub attrs="*" schemachecking=off binddn="cn=manager,o=test" bindmethod=simple credentials="secret" sizelimit=unlimited updateref ldaps://ldapprov overlay syncprov --- end of slapd.conf running slapd in debug mode -d 65535 shows: --- slapd -d 65535 conn=0 op=1 PASSMOD id="uid=test,o=test" new >>> dnPrettyNormal: <uid=user,o=test> => ldap_bv2dn(uid=user,o=test,0) <= ldap_bv2dn(uid=user,o=test)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=user,o=test)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=user,o=test)=0 <<< dnPrettyNormal: <uid=user,o=test>, <uid=user,o=test> bdb_dn2entry("uid=user,o=test") => bdb_dn2id("uid=user,o=test") <= bdb_dn2id: got id=0x0000284c => bdb_dn2id("o=test") <= bdb_dn2id: got id=0x00002861 => bdb_dn2id("uid=user,o=test") <= bdb_dn2id: got id=0x0000337f entry_decode: "uid=user,o=test" <= entry_decode(uid=user,o=test) ldap_url_parse_ext(ldaps://ldapprov) send_ldap_extended: err=10 oid= len=0 ldap_url_parse_ext(ldaps://ldapprov) Segmentation fault ----- end of debug output the command used was: ldappasswd -x -h localhost -D "cn=manager,o=test" -W uid=test,o=test -S New password: Re-enter new password: Enter LDAP Password: ldappasswd: ldap_result: Can't contact LDAP server (-1) the last 70 lines of strace where: --- tail -70 slapd-strace.log: time(NULL) = 1179248871 time(NULL) = 1179248871 close(14) = 0 close(15) = 0 close(13) = 0 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 fcntl64(12, F_GETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024, pid=0}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 write(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 3072, SEEK_SET) = 3072 read(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 yHF\0\0\0\0\242q\0\0\0\0"..., 1024) = 1024 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 read(13, "\22\0\0\0\212^i\0\0\0\0\0b1\5\0\t\0\0\0\0@\0\0\0\t\0\0"..., 512) = 512 close(13) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 fstat64(13, {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 time(NULL) = 1179248871 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 read(14, "\22\0\0\0\tEQ\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 512) = 512 close(14) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 fstat64(14, {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 time(NULL) = 1179248871 pread64(13, "\20\0\0\0008\fY\0\1\0\0\0\0\0\0\0\0\0\0\0\2\0\344?\3\3"..., 16384, 16384) = 16384 pread64(13, "\22\0\0\0:^i\0\220\3\0\0\0\0\0\0\0\0\0\0\335\0010\"\2\3"..., 16384, 14942208) = 16384 pread64(13, "\22\0\0\0\235\0m\0W\3\0\0O\3\0\0\0\0\0\0\20\0\270!\1\5"..., 16384, 14008320) = 16384 mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb63c3000 time(NULL) = 1179248871 write(2, "=> bdb_entry_get: ndn: \"o=testh"..., 49) = 49 write(2, "=> bdb_entry_get: oc: \"(null)\", "..., 49) = 49 write(2, "bdb_dn2entry(\"o=test"..., 40) = 40 write(2, "=> bdb_dn2id(\"o=test"..., 40) = 40 pread64(14, "\t\0\0\0D+=\0\1\0\0\0\0\0\0\0\0\0\0\0\20\0\214\r\3\3\364"..., 4096, 4096) = 4096 pread64(14, "\n\0\0\0\212\242P\0_\2\0\0\0\0\0\0G\4\0\0G\0\364\7\2\3"..., 4096, 2486272) = 4096 pread64(14, "\22\0\0\0i\374l\0\n\0\0\0Q\3\0\0\33\4\0\0>\0\230\6\1\5"..., 4096, 40960) = 4096 write(2, "<= bdb_dn2id: got id=0x00000001\n", 32) = 32 pread64(13, "\20\0\0\0\230\313X\0\217\3\0\0\0\0\0\0\0\0\0\0\307\1\224"..., 16384, 14925824) = 16384 pread64(13, "\22\0\0\0O\2m\0\2\0\0\0\0\0\0\0\3\0\0\0(\0|\4\1\5\370?"..., 16384, 32768) = 16384 write(2, "entry_decode: \"o=test"..., 40) = 40 write(2, "<= entry_decode(o=test"..., 41) = 41 write(2, "=> bdb_entry_get: found entry: \""..., 57) = 57 write(2, "bdb_entry_get: rc=0\n", 20) = 20 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5bc2000 mprotect(0xb5bc2000, 4096, PROT_NONE) = 0 clone(child_stack=0xb63c24d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb63c2be8, {entry_number:6, base_addr:0xb63c2ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb63c2be8) = 374 futex(0xb63c2be8, FUTEX_WAIT, 374, NULL) = 0 write(2, "slapd starting\n", 15) = 15 mmap2(NULL, 385024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5363000 clone(child_stack=0xb63c24d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb63c2be8, {entry_number:6, base_addr:0xb63c2ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb63c2be8) = 375 futex(0xb63c2be8, FUTEX_WAIT, 375, NULL) = 0 +++ killed by SIGSEGV +++ ---- end of tail -70 slapd-strace.log using a wrong ldap password at "Enter LDAP Password:" when promped by "ldappasswd" does not crash the server.

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 15 May '07

15 May '07

ando(a)sys-net.it wrote: > this might be pointless. HEAD evolved quite a bit since 2.2.4alpha, so Of course, I meant 2.4.4alpha. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 15 May '07

15 May '07

ali.pouya(a)free.fr wrote: > Hi Pierangelo; > Sorry for the stripped code. > Below you find a backtrace of slapd 2.4.4alpha with the non-stripped code : > > (gdb) bt > #0 0x00889d5a in strcmp () from /lib/tls/libc.so.6 > #1 0x08068ede in select_backend (dn=0xa2f4df5c, manageDSAit=0, noSubs=0) > at backend.c:684 you should print the contents of the "dn" arg to select_backend(), but this might be pointless. HEAD evolved quite a bit since 2.2.4alpha, so I suggested you to check with HEAD code before chasing an already fixed bug. Can you do that? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr 15 May '07

15 May '07

Hi Pierangelo; Sorry for the stripped code. Below you find a backtrace of slapd 2.4.4alpha with the non-stripped code : (gdb) bt #0 0x00889d5a in strcmp () from /lib/tls/libc.so.6 #1 0x08068ede in select_backend (dn=0xa2f4df5c, manageDSAit=0, noSubs=0) at backend.c:684 #2 0x0806a8ac in fe_aux_operational (op=0xa2f4df40, rs=0xa2f4de80) at backend.c:1779 #3 0x0806a01b in backend_operational (op=0xa2f4df40, rs=0xa2f4de80) at backend.c:1801 #4 0x080a7d06 in do_syncrepl (ctx=0xa2f4e2a0, arg=0x8695fb0) at syncrepl.c:547 #5 0x081281cb in ldap_int_thread_pool_wrapper (xpool=0x865ad78) at tpool.c:704 #6 0x00bb6371 in start_thread () from /lib/tls/libpthread.so.0 #7 0x008e8ffe in clone () from /lib/tls/libc.so.6 (gdb) > Likely because you used a stripped binary. Can you reproduce the issue >with a non-stripped build of HEAD? > >p.

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 14 May '07

14 May '07

ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.4alpha > OS: Linux RedHat AS4 (kernel 2.6) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.3.30) > > > I'm testing OpenLdap 2.4.4alpha for future use. > I have a master and a replica. > In the replica's syncrepl configuration has searchbase="" then the replica seg > faults after connecting to the master. > > The core backtrace shows very little information : Likely because you used a stripped binary. Can you reproduce the issue with a non-stripped build of HEAD? p. > (gdb) bt > #0 0x00179d5a in strcmp () from /lib/tls/libc.so.6 > #1 0x08068ede in ?? () > #2 0x098c0d50 in ?? () > #3 0x00000000 in ?? () > (gdb) > > Below I add the end of the slapd detailed log. > I can send any other information required. > Thanks and best regards > Ali Pouya > > Log extract : > > ** ld 0x991dcf8 Outstanding Requests: > * msgid 1, origid 1, status InProgress > outstanding referrals 0, parent count 0 > ld 0x991dcf8 request count 1 (abandoned 0) > ** ld 0x991dcf8 Response Queue: > Empty > ld 0x991dcf8 response count 0 > ldap_chkResponseList ld 0x991dcf8 msgid 1 all 1 > ldap_chkResponseList returns ld 0x991dcf8 NULL > ldap_int_select > read1msg: ld 0x991dcf8 msgid 1 all 1 > ber_get_next > ldap_read: want=8, got=8 > 0000: 30 0c 02 01 01 61 07 0a 0....a.. > ldap_read: want=6, got=6 > 0000: 01 00 04 00 04 00 ...... > ber_get_next: tag 0x30 len 12 contents: > ber_dump: buf=0x099270b8 ptr=0x099270b8 end=0x099270c4 len=12 > 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ > read1msg: ld 0x991dcf8 msgid 1 message type bind > ber_scanf fmt ({eAA) ber: > ber_dump: buf=0x099270b8 ptr=0x099270bb end=0x099270c4 len=9 > 0000: 61 07 0a 01 00 04 00 04 00 a........ > read1msg: ld 0x991dcf8 0 new referrals > read1msg: mark request completed, ld 0x991dcf8 msgid 1 > request done: ld 0x991dcf8 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_dump: buf=0x099270b8 ptr=0x099270bb end=0x099270c4 len=9 > 0000: 61 07 0a 01 00 04 00 04 00 a........ > ber_scanf fmt (}) ber: > ber_dump: buf=0x099270b8 ptr=0x099270c4 end=0x099270c4 len=0 > > ldap_msgfree > Erreur de segmentation (core dumped) > > > > > > > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4960) the memory increase quickly and not can be released sometime.
by ando＠sys-net.it 14 May '07

14 May '07

h.b.furuseth(a)usit.uio.no wrote: > hoverwf(a)126.com writes: >> when i disable the code which get the attribute value of entry, >> in other word, both the for loop. this problem seems disappeared, > > Yes. Add ldap_memfree(a); to your inner loop, like > 'man ldap_first_attribute' says: > > NOTES > The ldap_first_attribute() and ldap_next_attribute() > return dynamically allocated memory that must be > freed by the caller via ldap_memfree(3). > > This ITS will be closed. This ITS shouldn't have been opened. Bugs appearing from custom code are 99.9% of the times related to bugs in custom code. Discussion about libldap use does not belong to OpenLDAP, unless it addresses something specific to OpenLDAP's implementation. In any case, this discussion should at most take place on the OpenLDAP-software mailing list. An ITS shouldn't be opened until there is a clear evidence of a bug or an issue with OpenLDAP software. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4960) the memory increase quickly and not can be released sometime.
by h.b.furuseth＠usit.uio.no 14 May '07

14 May '07

hoverwf(a)126.com writes: > when i disable the code which get the attribute value of entry, > in other word, both the for loop. this problem seems disappeared, Yes. Add ldap_memfree(a); to your inner loop, like 'man ldap_first_attribute' says: NOTES The ldap_first_attribute() and ldap_next_attribute() return dynamically allocated memory that must be freed by the caller via ldap_memfree(3). This ITS will be closed. -- Regards, Hallvard

1 0

Re: Re: (ITS#4960) the memory increase qu ickly and not can be released sometime.
by hoverwf＠126.com 14 May '07

14 May '07

--Boundary-=_xtKUzFltSgmOFoknxqwrawgJMmQz Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit NOTE 1: i comment the code in the inner for loop of attribute. NOTE 2: the output of valgrind shows: 62,130 bytes in 6,013 blocks are definitely lost in loss record 10 of 10 at 0x401B704: malloc (vg_replace_malloc.c:149) by 0x4441987: ber_memalloc_x (in /usr/lib/liblber-2.3.so.0.2.9) by 0x443ECA6: ber_get_stringbv (in /usr/lib/liblber-2.3.so.0.2.9) by 0x443ED1E: ber_get_stringa (in /usr/lib/liblber-2.3.so.0.2.9) by 0x443F3EE: ber_scanf (in /usr/lib/liblber-2.3.so.0.2.9) by 0x4161C67: ldap_next_attribute (in /usr/lib/libldap-2.3.so.0.2.9) by 0x80AC0E0: search_node_bydn (myprogram.c:1744) --Boundary-=_xtKUzFltSgmOFoknxqwrawgJMmQz Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <DIV> </DIV> <DIV>NOTE 1:  i comment the code in the inner for loop of attribute.= </DIV> <DIV>NOTE 2: the output of valgrind shows:</DIV> <DIV> </DIV> <DIV> 62,130 bytes in 6,013 blocks are definitely lost in loss recor= d 10 of 10<BR>         &nbsp= ; at 0x401B704: malloc (vg_replace_malloc.c:149)<BR>   &nb= sp;      by 0x4441987: ber_memalloc_x (in /usr/l= ib/liblber-2.3.so.0.2.9)<BR>       &nb= sp;  by 0x443ECA6: ber_get_stringbv (in /usr/lib/liblber-2.3.so.0.2.= 9)<BR>          by 0x443ED1E= : ber_get_stringa (in /usr/lib/liblber-2.3.so.0.2.9)<BR>  &nbsp= ;       by 0x443F3EE: ber_scanf (in /usr/li= b/liblber-2.3.so.0.2.9)<BR>       &nbs= p;  by 0x4161C67: ldap_next_attribute (in /usr/lib/libldap-2.3.so.0.= 2.9)<BR>          by 0x80AC0= E0: search_node_bydn (myprogram.c:1744)</DIV><br><br><hr> <a style=3D"font-size:14px;line-height:15px; color:#000; text-decoration:= none" href=3D"http://event.mail.163.com/chanel/xyq.htm?from=3D126" target= =3D"_blank"><span style=3D"text-decoration:underline; color:blue">=C3=E2=B7= =D1=CA=D4=CD=E62006=D6=D0=B9=FA=D7=EE=BC=D1=CD=F8=C2=E7=D3=CE=CF=B7--=C3=CE= =BB=C3=CE=F7=D3=CE </span> </a> --Boundary-=_xtKUzFltSgmOFoknxqwrawgJMmQz--

1 0

Re: Re: (ITS#4960) the memory increase qu ickly and not can be released sometime.
by hoverwf＠126.com 14 May '07

14 May '07

--Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable more infomation: =20 =20 NOTE 1: i comment the code in the inner for loop of attribute. =20 NOTE 2: the output of valgrind shows: =3D=3D879=3D=3D=20 =3D=3D879=3D=3D 62,130 bytes in 6,013 blocks are definitely lost in loss = record 10 of 10 =3D=3D879=3D=3D at 0x401B704: malloc (vg_replace_malloc.c:149) =3D=3D879=3D=3D by 0x4441987: ber_memalloc_x (in /usr/lib/liblber-2.3.= so.0.2.9) =3D=3D879=3D=3D by 0x443ECA6: ber_get_stringbv (in /usr/lib/liblber-2.= 3.so.0.2.9) =3D=3D879=3D=3D by 0x443ED1E: ber_get_stringa (in /usr/lib/liblber-2.3= =2Eso.0.2.9) =3D=3D879=3D=3D by 0x443F3EE: ber_scanf (in /usr/lib/liblber-2.3.so.0.= 2.9) =3D=3D879=3D=3D by 0x4161C67: ldap_next_attribute (in /usr/lib/libldap= -2.3.so.0.2.9) =3D=3D879=3D=3D by 0x80AC0E0: search_node_bydn (myprogram.c:1744) =20 =20 =20 =20 =D4=DA2007-05-14=A3=ACopenldap-its(a)openldap.org =D0=B4=B5=C0=A3=BA *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#4960. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#4960) in the subject will automatically be attached to the issue report. =09mailto:openldap-its@openldap.org?subject=3D(ITS#4960) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D4960 Please remember to retain your issue tracking number (ITS#4960) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. --Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <DIV>more infomation:</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>NOTE 1:  i comment the code in the inner for loop of attribute.= </DIV> <DIV> </DIV> <DIV>NOTE 2: the output of valgrind shows:</DIV> <DIV>=3D=3D879=3D=3D <BR>=3D=3D879=3D=3D 62,130 bytes in 6,013 blocks are= definitely lost in loss record 10 of 10<BR>=3D=3D879=3D=3D  &n= bsp; at 0x401B704: malloc (vg_replace_malloc.c:149)<BR>=3D=3D879=3D=3D&nb= sp;   by 0x4441987: ber_memalloc_x (in /usr/lib/liblber-2.3.so.= 0.2.9)<BR>=3D=3D879=3D=3D    by 0x443ECA6: ber_get_stringb= v (in /usr/lib/liblber-2.3.so.0.2.9)<BR>=3D=3D879=3D=3D   = by 0x443ED1E: ber_get_stringa (in /usr/lib/liblber-2.3.so.0.2.9)<BR>=3D=3D= 879=3D=3D    by 0x443F3EE: ber_scanf (in /usr/lib/liblber-= 2.3.so.0.2.9)<BR>=3D=3D879=3D=3D    by 0x4161C67: ldap_nex= t_attribute (in /usr/lib/libldap-2.3.so.0.2.9)<BR>=3D=3D879=3D=3D &n= bsp;  by 0x80AC0E0: search_node_bydn (myprogram.c:1744)</DIV> <DIV><BR> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV ></DIV><BR>=D4=DA2007-05-14=A3=ACopenldap-its(a)openldap.org =D0=B4=B5= =C0=A3=BA<BR> <BLOCKQUOTE style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER= -LEFT: #ccc 1px solid"><PRE style=3D"WORD-WRAP: break-word">*** THIS IS A= N AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#4960. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#4960) in the subject will automatically be attached to the issue report. =09<A href=3D"mailto:openldap-its@openldap.org?subject=3D" target=3D_new>= mailto:openldap-its@openldap.org?subject=3D</A>(ITS#4960) You may follow the progress of this report by loading the following URL in a web browser: <A href=3D"http://www.openldap.org/its/index.cgi?findid=3D4960" targe= t=3D_new>http://www.OpenLDAP.org/its/index.cgi?findid=3D4960</A> Please remember to retain your issue tracking number (ITS#4960) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09<A href=3D"http://www.openldap.org/support/" target=3D_new>http://www.= OpenLDAP.org/support/</A> -------------- Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. </PRE></BLOCKQUOTE><br><br><hr> <a style=3D"font-size:14px;line-height:15px; color:#000; text-decoration:= none" href=3D"http://event.mail.163.com/chanel/xyq.htm?from=3D126" target= =3D"_blank"><span style=3D"text-decoration:underline; color:blue">=C3=E2=B7= =D1=CA=D4=CD=E62006=D6=D0=B9=FA=D7=EE=BC=D1=CD=F8=C2=E7=D3=CE=CF=B7--=C3=CE= =BB=C3=CE=F7=D3=CE </span> </a> --Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg--

1 0

(ITS#4963) Sub-second ldap_search timeout accuracy
by cs＠unc.edu 14 May '07

14 May '07

Full_Name: Christian Schlatter Version: CVS HEAD (Mon May 14 15:21:36 EDT 2007) OS: ubuntu dapper URL: http://www.unc.edu/~cschlatt/openldap/result.patch Submission from: (NULL) (152.2.199.72) I'm developing an LDAP module for the OpenSER SIP server using OpenLDAP libldap. Since this is a real-time application I need to be able to set LDAP timeouts to a value less than a second. This isn't possible with the existing libldap ldap_result(...timeout...) implementation. In particular, the timeout check at the end of function wait4msg(..) in result.c only has an accuracy of one second. This lead to unexpected behavior for timeout values that are less than a second. I've added a patch for your consideration that adds sub-second accuracy to wait4msg. The code works for me but I don't have experience with the OpenLDAP source code and any coding guidelines. Nevertheless, I'd be very glad if this functionality could be incorporated in a future OpenLDAP release. Christian

1 0

(ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no 14 May '07

14 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Backends are quite inconsistent about how Bind treats rootdn/rootpw. After a quick browse of the HEAD code, it looks like this - I'll investigate closer if needed: rootpw supported: Yes: config, bdb, meta, monitor, ldif, HEAD:null, sql, overlay retcode. No: dnssrv, ldap?, RE23:null, perl, relay, shell. (Bind not supported: passwd). Rootpw vs. normal Bind as rootdn (typically when rootdn names an entry): config, bdb, null, sql, overlay retcode (I think): Try rootpw first, then if failure try normal Bind (even if rootpw exists but the Bind password does not match it). ldif: Do not try rootpw if rootdn names an existing entry. meta: Fail if rootpw is missing or does not match, more complicated otherwise. monitor: Fine - there are no entries with passwords. The manpage is (fortunately:-) unclear on what happens in this case. Check if op->orb_method == LDAP_AUTH_SIMPLE: Yes: config, bdb, meta, monitor. No: ldif, null, sql, overlay retcode. Set op->orb_edn (op->oq_bind.rb_edn) from be_root_dn() on success: config, bdb, monitor, sql. Set op->orb_edn on failure: bdb: Sometimes, from &e->e_name. sql: Always, from op->o_req_ndn. Set rs->sr_err = LDAP_SUCCESS on success: ldif, meta Reset rs->sr_text: meta Which behavior is right? I'm wondering if Bind should fail if rootpw exists but the Bind password does not match it. In any case, methinks we need a be_rootpw_bind(op, rs) function which takes care of this consistently, so bi_op_bind in most cases can just do if (be_rootpw_bind(op, rs)) return rs->sr_err; If needed it could accept rs==NULL to just check the password - like be_isroot_pw() but with more return codes to distinguish different cases.

1 0

(ITS#4961) If database suffix is "" slapd cannot update ContextCSN
by ali.pouya＠free.fr 14 May '07

14 May '07

Full_Name: Ali Pouya Version: 2.4.4alpha OS: Linux RedHat AS4 (kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) I'm esting OpenLdap 2.4.4alpha with syncrepl for future use. If the BDB data base suffix is "" then slapd cannot update the ContextCSN attribute (while with OpenLdap 2.3.35 it's OK). This makes impossible replica syncronization. When I stop slapd I see the following lines in the log. I can submit more information if required. Thanks Best Regards Ali ============================ Log Extract : daemon: shutdown requested and initiated. daemon: closing 7 slapd shutdown: waiting for 0 threads to terminate slapd shutdown: initiated bdb_modify: bdb_dn2entry("") bdb_modify_internal: 0x00000000: <= acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN is_entry_objectclass("", "2.5.17.0") no objectClass attribute No objectClass for entry () entry failed schema check: no objectClass attribute bdb_modify: modify failed (65) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=65 matched="" text="no objectClass attribute" ====> bdb_cache_release_all slapd destroy: freeing system resources. slapd stopped.

1 0

(ITS#4960) the memory increase quickly and not can be released sometime.
by hoverwf＠126.com 14 May '07

14 May '07

Full_Name: wang fei Version: OpenLDAP 2.3.21 OS: slackware URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.167.25.214) descirption: i use the following code to get the info of the entry whose DN matches "search dn". the problem: when i call this function many times(eg: more then 1000 times), the result will be correct, but for about one or two times, after i call ldap_search_ext_s(). the memory will increase dramitically (usually 128K, i use system("ps aux | grep /myprogram") to find the memory it is used). and when i ldap_msgfree(res). it only 4K memory is released. but the other 998 times does not has this problem(the memory will not increase). All these nodes have similar attribute except dn and cn. when i disable the code of the inner for loop. this problem appear less frequently. when i disable the code which get the attribute value of entry, in other word, both the for loop. this problem seems disappeared, but it maybe it will appear again if it is runed more times. // portion code of the program static int search_node_bydn(char *search_dn) { int ret; char *a = NULL, *attrs[10], *dn; char filter[1024]; LDAPMessage *e=NULL, *res = NULL; LDAP *ld = NULL; struct timeval timeout; // open the connection... // bind ... // then search the node.... attrs[0] = "objectGUID"; attrs[1] = "modifyTimeStamp"; attrs[2] = "cn"; attrs[3] = "sAMAccountName"; attrs[4] = "objectClass"; attrs[5] = "name"; attrs[6] = NULL; snprintf(filter, 1024, "(objectClass=*)"); timeout.tv_sec = 1000; system("ps aux | grep /myprogram"); ret = ldap_search_ext_s(ld, search_dn, LDAP_SCOPE_BASEOBJECT,filter, attrs, 0, NULL, NULL, &timeout, 0, &res); if (ret != LDAP_SUCCESS) { printf("search node %s error: %s\n", search_dn, ldap_err2string(ret)); ldap_msgfree(res); ldap_unbind_ext(ld, NULL, NULL); return (-1); } system("ps aux | grep /myprogram"); #if 1 // get the attribute value of entry. for (e = ldap_first_entry(ld, res); e != NULL; e = ldap_next_entry(ld, e)) { #if 1 BerElement *ptr = NULL; for (a = ldap_first_attribute(ld, e, &ptr); a != NULL; a = ldap_next_attribute(ld, e, ptr)) { // do sth with the attribute. }// inner for loop if(ptr != NULL) { ber_free(ptr,0); } #endif }// outer for loop #endif system("ps aux | grep /myprogram"); ldap_msgfree(res); res = NULL; system("ps aux | grep /myprogram"); ldap_unbind_ext(ld, NULL, NULL); return OK; }

1 0

(ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr 14 May '07

14 May '07

Full_Name: Ali Pouya Version: 2.4.4alpha OS: Linux RedHat AS4 (kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) I'm testing OpenLdap 2.4.4alpha for future use. I have a master and a replica. In the replica's syncrepl configuration has searchbase="" then the replica seg faults after connecting to the master. The core backtrace shows very little information : (gdb) bt #0 0x00179d5a in strcmp () from /lib/tls/libc.so.6 #1 0x08068ede in ?? () #2 0x098c0d50 in ?? () #3 0x00000000 in ?? () (gdb) Below I add the end of the slapd detailed log. I can send any other information required. Thanks and best regards Ali Pouya Log extract : ** ld 0x991dcf8 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x991dcf8 request count 1 (abandoned 0) ** ld 0x991dcf8 Response Queue: Empty ld 0x991dcf8 response count 0 ldap_chkResponseList ld 0x991dcf8 msgid 1 all 1 ldap_chkResponseList returns ld 0x991dcf8 NULL ldap_int_select read1msg: ld 0x991dcf8 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x099270b8 ptr=0x099270b8 end=0x099270c4 len=12 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ read1msg: ld 0x991dcf8 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x099270b8 ptr=0x099270bb end=0x099270c4 len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ read1msg: ld 0x991dcf8 0 new referrals read1msg: mark request completed, ld 0x991dcf8 msgid 1 request done: ld 0x991dcf8 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_dump: buf=0x099270b8 ptr=0x099270bb end=0x099270c4 len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ ber_scanf fmt (}) ber: ber_dump: buf=0x099270b8 ptr=0x099270c4 end=0x099270c4 len=0 ldap_msgfree Erreur de segmentation (core dumped)

1 0

(ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr 14 May '07

14 May '07

Full_Name: Nikos Voutsinas Version: 2.3.35 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.134.100.39) As ando already said: .....it tries to lookup a database to relay for when unbinding, but unbind has no DN, so a strcmp on NULL is performed. This does not happen when using the "relay" directive because relay database selection does not occur for each operation.... configuration example: database bdb suffix "dc=real,dc=naming,dc=context" .... .... .... database relay suffix "" overlay rwm suffixmassage "dc=real,dc=naming,dc=context"

1 0

Re: (ITS#4930) slaptest should be quiet on success
by jsafrane＠redhat.com 14 May '07

14 May '07

On Fri, 2007-05-11 at 22:07 +0200, Pierangelo Masarati wrote: > jsafranek(a)redhat.com wrote: > > > The 'slaptest' tool is a bit verbose, it sends 'config file testing succeeded' > > to stderr. IMHO it should do not output anything, especially to stderr, if > > everything is all right. > > > > Here is a small patch, causing the slaptest to display the aforementioned > > message only if -v switch is used: > > Your issue may make sense in some cases, but I'd rather reverse its > logic and avoid printing any message only when explicitly requested to > be "quiet" (e.g. adding a -Q switch?) Why not, I have basically nothing against -Q switch, but it would require a bit more changes in the current sources. I just needed something quick-and-not-so-dirty. Jan

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it 13 May '07

13 May '07

richton(a)nbcs.rutgers.edu wrote: > * libradius makes use of MT-Unsafe calls, so a protecting mutex is added. applied to HEAD > * config_filename could be passed to rad_config without initialization (when > accepting the default). rejected: global variables are always zeroed. Please test. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4957) destroying uninitialized mutexed after failed startup
by ando＠sys-net.it 13 May '07

13 May '07

h.b.furuseth(a)usit.uio.no wrote: > (I haven't committed to non-HEAD for ages, I don't rememer if I > just commit it or if there are more formalities involved?) Commit; if appropriate, note in CHANGES. Someone else (the Chief Architect) will move tags. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4957) destroying uninitialized mutexed after failed startup
by h.b.furuseth＠usit.uio.no 13 May '07

13 May '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: URL: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/schema_init.c.diff?r… Submission from: (NULL) (129.240.202.105) Submitted by: hallvard If RE23 startup fails, ad_undef_mutex and oc_undef_mutex can be destroyed without having been initialized. Thus slapd can crash. Fix: schema_init.c rev 1.388. (I haven't committed to non-HEAD for ages, I don't rememer if I just commit it or if there are more formalities involved?)

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 12 May '07

12 May '07

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: >> - TID_HASH() fails if several ldap_pvt_thread_t bit patterns can >> represent the same thread ID, e.g. if it is a struct/integer type with >> padding bytes/bits. >> > That doesn't matter, since the table will use linear probing to compare > thread IDs. Ah, it works when creating new threads. But not in pool_context(), which stops searching when it hits an unused slot (thread ID tid_zero). -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 12 May '07

12 May '07

h.b.furuseth(a)usit.uio.no wrote: > h.b.furuseth(a)usit.uio.no writes: >> Howard Chu writes: >>> Since there is only one thread pool in use, it is impossible for another >>> thread to be active. >> No. Though it's true that my concern above was wrong. >> >> It is "ltp_active_count--" which triggers the start of a pause. (...) > > Sorry again, I was confusing 3 problems after two long days. It's the > active (unpaused) thread which would be calling _context() of course. > > In any case, thank you for the reply. I know what to test now... > > > Another problem, which I think I'm repeating from an earlier discussion: > > - TID_HASH() fails if several ldap_pvt_thread_t bit patterns can > represent the same thread ID, e.g. if it is a struct/integer type with > padding bytes/bits. > That doesn't matter, since the table will use linear probing to compare thread IDs. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 12 May '07

12 May '07

h.b.furuseth(a)usit.uio.no writes: >Howard Chu writes: >> Since there is only one thread pool in use, it is impossible for another >> thread to be active. > > No. Though it's true that my concern above was wrong. > > It is "ltp_active_count--" which triggers the start of a pause. (...) Sorry again, I was confusing 3 problems after two long days. It's the active (unpaused) thread which would be calling _context() of course. In any case, thank you for the reply. I know what to test now... Another problem, which I think I'm repeating from an earlier discussion: - TID_HASH() fails if several ldap_pvt_thread_t bit patterns can represent the same thread ID, e.g. if it is a struct/integer type with padding bytes/bits. It might be better to let TID_HASH cast the ID to an unsigned integer type and hash that. Then it won't compile if ldap_pvt_thread_t is a struct, so we get a warning in _some_ cases when it can break. -- Regards, Hallvard

1 0

slapd + TLS + verify client is not working as expected
by Andreas Roth 12 May '07

12 May '07

Hello, i'm using slapd 2.3.30 on a Ubuntu 7.04 AMD64 machine and i've have some trouble to get it running with TLS. When the slapd daemon is started during the system start-up i cannot connect to the LDAP server with TLS. After a long search i figured out, that the slapd daemon requests a client certificate, but i haven't configured the server to do so. Here is the TLS configuration of slapd: TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSVerifyClient never TLSCACertificateFile /etc/ldap/certs/root.crt #TLSCACertificatePath /etc/ldap/certs TLSCertificateFile /etc/ldap/certs/ldap.arsoft.homeip.net.crt TLSCertificateKeyFile /etc/ldap/private/ldap.arsoft.homeip.net.pem And here's what the server says when i connect to it using ldapsearch -x -ZZ ... TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A daemon: select: listen=6 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 11r daemon: read activity on 11 connection_get(11) connection_get(11): got connid=187 connection_read(11): checking for input on id=187 tls_read: want=5, got=5 0000: 16 03 01 00 07 ..... tls_read: want=7, got=7 0000: 0b 00 00 03 00 00 00 ....... tls_write: want=7, written=7 0000: 15 03 01 00 02 02 28 ......( TLS trace: SSL3 alert write:fatal:handshake failure TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS: can't accept. TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455 connection_read(11): TLS accept failure error=-1 id=187, closing connection_closing: readying conn=187 sd=11 for close connection_close: conn=187 sd=11 The interesting thing is, that when i restart the slapd daemon manually, the server works fine and TLS is also working. I don't known if this porblem is really a bug or not, but i don't know how to solve this problem by myself. Any help or advise is welcomed. Thanks, A. Roth

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 11 May '07

11 May '07

I wrote: > So if I call setkey and the key already exists and has an ltk_free > function, it's my responsibility to know the old data was there, and > free it or take back ownership? (A clarifying comment would be useful.) Sorry, "yes" of course. Total blindness to what you wrote on my part. -- Regards, Hallvard

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by guenther+ldapdev＠sendmail.com 11 May '07

11 May '07

On Fri, 11 May 2007, Howard Chu wrote: > That sounds like you're seeing a bug in the kernel's TCP stack then. A > TCP close sends a FIN to the other end and is required to wait for the > FIN to be ACK'd before the connection can be torn down. (Subject to 2MSL > timeout.) That is most certainly not our problem. The FIN sent by the client *is* ACKed by the server. The data sent by the client is reliably delivered. The issue is the behavior when data is sent to a endpoint which has already called close(). The data can't be delivered to the application, so the kernel send back a RST to inform the other end of the data loss. That issue---the data loss---is a direct result of the server sending a TLS close_notify and client not reading it before closing the socket. Unless one of those changes, a RST must be generated to report the data loss to the sender. All the UNIX versions that I have tried behave as described. If this is a bug in TCP stacks, it is *very* well entrenched. Philip Guenther

1 0

Re: (ITS#4930) slaptest should be quiet on success
by ando＠sys-net.it 11 May '07

11 May '07

jsafranek(a)redhat.com wrote: > The 'slaptest' tool is a bit verbose, it sends 'config file testing succeeded' > to stderr. IMHO it should do not output anything, especially to stderr, if > everything is all right. > > Here is a small patch, causing the slaptest to display the aforementioned > message only if -v switch is used: > > Index: servers/slapd/slaptest.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/slaptest.c,v > retrieving revision 1.9 > diff -r1.9 slaptest.c > 107c107,108 > < fprintf( stderr, "config file testing succeeded\n"); > --- >> if (verbose) >> fprintf( stderr, "config file testing succeeded\n"); Your issue may make sense in some cases, but I'd rather reverse its logic and avoid printing any message only when explicitly requested to be "quiet" (e.g. adding a -Q switch?) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by hyc＠symas.com 11 May '07

11 May '07

guenther+ldapdev(a)sendmail.com wrote: > Full_Name: Philip Guenther > Version: 2.3.27 > OS: Linux and Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.58.1.252) > > > [I vaguely recall seeing a report of this issue in the archives of one of the > mailing lists, but I can no longer find the original.] > > If you trace the packets sent when you use, for example, ldapsearch against a > server on a different host, using either the -Z option to do TLS or using an > ldaps URI, you'll discover that the TCP connection is actually reset instead of > being closed cleanly: the client sends TCP RSTs in response to the server's > final packets. > > This is because libldap uses the following sequence when unbind a TLS or SSL > connection: > 1) send the unbind request (over the TLS or SSL layer) > 2) call SSL_shutdown(), sending the TLS close_notify alert > 3) call close() > > After receiving the close_notify alert from step (2), the server sends back its > own close_notify alert and then calls close(). However, because the client > didn't wait for the server's response before calling close() on its end, the > client's TCP stack considers the TCP connection to already be gone and responds > with the RST packets. This occurs with Linux and Solaris clients and probably > most other unices: the response to packets after a close() doesn't vary in my > experience. That sounds like you're seeing a bug in the kernel's TCP stack then. A TCP close sends a FIN to the other end and is required to wait for the FIN to be ACK'd before the connection can be torn down. (Subject to 2MSL timeout.) That is most certainly not our problem. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4956) slapd cores with a SEGFAULT after a failed proxy authorization
by hyc＠symas.com 11 May '07

11 May '07

pturgyan(a)umich.edu wrote: > Full_Name: Paul Turgyan > Version: 2.3.35 > OS: linux - 2.6 kernal > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.213.231.201) > slapd cores with a SEGFAULT after a failed proxy authorization, > with a core file like: This was already reported in ITS#4954 and is fixed in HEAD. Simply NULLing out the pointer will introduce a memory leak. This ITS will be closed as a dup of #4954. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4956) slapd cores with a SEGFAULT after a failed proxy authorization
by pturgyan＠umich.edu 11 May '07

11 May '07

Full_Name: Paul Turgyan Version: 2.3.35 OS: linux - 2.6 kernal URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.213.231.201) slapd cores with a SEGFAULT after a failed proxy authorization, with a core file like: (gdb) bt #0 0xb7c74be5 in *__GI___libc_free (mem=0xab5fc714) at malloc.c:3402 #1 0x0807aa96 in ch_free (ptr=0xab5fc714) at ch_malloc.c:139 #2 0x080a5886 in slap_sasl_authorize (sconn=0xacb03000, context=0xada20428, requested_user=0xacb03910 "pturgyan(a)UMICH.EDU", rlen=18, auth_identity=0xacb03a11 "pturgyan(a)UMICH.EDU", alen=18, def_realm=0xacb049e0 "UMICH.EDU", urlen=9, props=0x0) at sasl.c:673 #3 0xb7ea2ba3 in do_authorization (s_conn=0xacb03000) at server.c:1163 #4 0xb7ea2d18 in sasl_server_step (conn=0xacb03000, clientin=0xacb01dae "`?\006\t*\206H\206?\022\001\002\002\002\001\004", clientinlen=0, serverout=0xad61d114, serveroutlen=0x1) at server.c:1420 #5 0x080a6654 in slap_sasl_bind (op=0x830fad0, rs=0xad61d240) at sasl.c:1395 #6 0x0807cdaa in fe_op_bind (op=0x830fad0, rs=0xad61d240) at bind.c:276 #7 0x0807c5b3 in do_bind (op=0x830fad0, rs=0xad61d240) at bind.c:200 #8 0x0806176f in connection_operation (ctx=0x0, arg_v=0x830fad0) at connection.c:1133 #9 0x08133e28 in ldap_int_thread_pool_wrapper (xpool=0x81ff4e0) at tpool.c:478 #10 0xb7e83c6b in start_thread (arg=0xad61dbb0) at pthread_create.c:261 #11 0xb7cc9d9e in clone () from /lib/libc.so.6 We are using cyrus-sasl-2.1.21 heimdahl-0.6.2 During a proxy auth, c_sasl_dn is set at sasl.c:682. If the proxy auth fails for some reason, then c_sasl_dn is never cleared. Sometime later, when that connection block is reused for another sasl bind, slap_sasl_authorize attempts to free the memory pointed to by c_sasl_dn.bv_val at sasl.c:673 and free SEGFAULTs. This can be duplicated by looping a ldapsearch that does a sasl bind with an invalid proxy authorization. You have to loop long enough to force a reuse of a connection struct. The following patch NULL's out c_sasl_dn at sasl.c:702 when the proxy auth is disallowed. *** sasl.c- Thu Jan 25 07:42:38 2007 --- sasl.c Fri May 11 13:47:19 2007 *************** *** 699,704 **** --- 699,705 ---- "proxy authorization disallowed (%d)\n", (long) (conn ? conn->c_connid : -1), rc, 0 ); + BER_BVZERO( &conn->c_sasl_dn ); sasl_seterror( sconn, 0, "not authorized" ); ch_free( authzDN.bv_val ); return SASL_NOAUTHZ;

1 0

(ITS#4955) v3 referrals problem in libldap/request.c
by steven.rellinger＠hp.com 11 May '07

11 May '07

Full_Name: Steve Version: 2.3.35 OS: Windows 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.227.217.75) There is a potential hang in the libldap/request.c code for chasing v3 referrals. I've narrowed down the scope of this issue to libldap/request.c in the function ldap_chase_v3referrals, specifically the loop after find_connection where it tries to see if the DN was already requested on that connection. (This is all around line 889) >From an outsider's perspective it seems like a really trivial bug was introduced into this loop in how it deals with the 'lp' variable. if ( lp == origreq ) { lp = lp->lr_child; } else { lp = lr->lr_refnext; } ... The variable lr does not change in this loop at all, it seems like a mistake to use it here as a condition on the loops flow. To me, it would seem like they meant to use something more like this which is a traditional linked list tree enumeration. if ( lp == origreq ) { lp = lp->lr_child; } else { lp = lp->lr_refnext; } I've tested this particular situation and it seems to eliviate the issue I was experiencing where it was chasing referrals from AD and never finishing this part of the function. I hope this helps others and or can be applied to the latest source code.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 11 May '07

11 May '07

Howard Chu writes: > Quite a lot of changes, will take some time to evaluate the overall > impact. I hope it helped to make one patch per issue, and that the comments were clear about what each patch was fixing. > The semaphore stuff probably needs to be axed/unifdef'd. It is If it is unusable, do you mean "axed/#if 0'ed"? > unusable, it would only result in deadlocks, and I think I already > removed the slapd code that would have invoked it. slapd/daemon.c does ldap_lazy_sem_init(). No other calls outside tpool.c. >> tpool.c breaks if there are multiple pools. The simplest >> solution seems to be to remove support for multiple pools. >> The problem is thread_keys[]. It is shared between pools, but: > > slapd only uses a single pool, and that's really the only use case we > care about. In fact it makes no sense to support multiple pools, > because we have no mechanism to assert scheduling priorities of one > pool over another. I'm afraid I did not think of scheduling priorities at all, only bugs. But it certainly makes things simpler if we remove multiple pools. Simple documentation of how tpool should be used may remove some of my concerns - or how it _is_ used, since it's only used in slapd. (Several probably only are problems if it is used as a library feature. tpool depends on being used the way slapd is using it. I've wondered what it's doing in libldap_r/ instead of in slapd/.) I wrote: >> - ltp_max_count (max #threads) is pool-specific, but is used to >> protect from array bounds violation on thread_keys[LDAP_MAXTHR]. >> (New simple code from me, previously there was no limit.) sorry, s/array bounds violation/eternal loop looking for free slot/. >> Other thread_keys[] strangeness: >> >> - setkey does not free the old data with ltk_free. Possibly that's >> intentional, but if so that requires weird code elsewhere. > > Yes, that's intentional. ltk_free is only intended for cleanup if a key > is still set by the time a thread exits. All of the keys we set are live > for the entire life of a thread, they don't get re-assigned. So if I call setkey and the key already exists and has an ltk_free function, it's my responsibility to know the old data was there, and free it or take back ownership? (A clarifying comment would be useful.) >> - maybe related to how getkey can return the ltk_free function - which >> seems crazy since a caller who uses it must then explicitly reset the >> key afterwards (or better, before), to be sure purgekey doesn't >> see the data and free it again. > > Nothing actually depends on returning the ltk_free function, that was > just included for completeness' sake. Then I suggest the getkey(,,,kfree) output parameter is removed, to avoid inviting to future duplicate frees. If anyone later needs it, a cleaner mechanism can be included - e.g. a setkey(data=kfree=0) variant which does call ltk_free before removing the key, or maybe a setkey which returns any old data and free function. >> - tpool.c uses LDAP_FREE(), can call ldap_pvt_thread_pool_context(), >> which uses thread_keys[]. If one thread does that when another thread >> has paused the pool, that can break since thread_keys[] is reserved >> for ldap_pvt_thread_pool_purgekey() during pauses. I'm wrong, thread_keys[] is _read-only_ during pauses. pool_context() is safe since it does not write thread_keys, just like pool_purgekey(). > Since there is only one thread pool in use, it is impossible for another > thread to be active. No. Though it's true that my concern above was wrong. It is "ltp_active_count--" which triggers the start of a pause. So "active" here means "included in ltp_active_count". A pool_wrapper() thread is only "active" when handling a context, not when adding itself to or removing itself from thread_keys[]. That's what my new pause waits were for. Also I don't think the main thread is included in the "active" threads - so it's only impossible if the main thread doesn't interfere. (Again, I suppose a comment may be the "fix".) But this reminds me: How much should an ltk_free() function be allowed to do? - pool_context_reset() calls ltk_free(). Should pool_wrapper() go active (wait for !pause, increment ltp_active_count, unlock ltp_mutex) before calling pool_context_reset()? - Should ltk_free() be allowed to change the contents of ltu_key[], so pool_purgekey() and pool_context_reset() should be prepared for that? >> - ltp_pending_count includes threads sleeping in pool_pause() - should >> it? In effect, pool_pause() temporarily reduces ltp_max_pending. > > I don't see why any special consideration is needed here. Nothing else > in the thread pool is going to move while a pause is in effect. That single thread could do ldap_pvt_thread_pool_submit() - which could fail due to the reduced effectinve max_pending. Again, if slapd won't, even with weird overlays and whatnot in effect, a comment will fix that. >> - In ldap_pvt_thread_pool_submit(): >> >> This comment: >> /* there is another open thread, so this >> * context will be handled eventually. >> * continue on and signal that the context >> * is waiting. >> */ >> is wrong if the previous if (pool->ltp_open_count == 0) was >> taken but the no thread was found inside that. > > The comment may be incomplete... "and signal that..." should be "we have signalled that...". Otherwise it's correct if we remove the remove the semaphore and unlock like you say below. With the current code, I think the comment should be /* another open thread took or eventually will * take care of this context. continue on, we * have signalled that the context is waiting. */ >> Also if ctx is invalid (another thread handled it) and a new >> pending request has gotten the now-unused ctx, then the >> 'if (pool->ltp_open_count == 0)' code will free that new >> pending request instead of the old one. > > Most likely this is due to unlocking and relocking the mutex around the > semaphore code. Axe that, remove the gratuitous unlock/relock, and then > that problem goes away. Yes, that should fix it. >> - Note, I haven't looked at the new semaphore stuff yet. >> >> Will get back to this later, but could use review so far. In particular >> I'd like to know if we'll keep or kill multi-pool support. > > Thus far we've only had to worry about a single pool. If anyone can come > up with a reason to need multiple pools, I guess we need to hear it. > Given the lack of scheduling control, I don't see how it would be of any > benefit. At the same time, I don't see a compelling reason to perturb > the code at the moment. Well, there are still bugs left. And can't say I like to have a feature (multiple pools) which only a not-bug because it isn't used. -- Regards, Hallvard

1 0

(ITS#4954) must clear c_sasl_dn after error
by donn＠u.washington.edu 10 May '07

10 May '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) After SASL bind failure, c_sasl_dn is not cleared, and eventually causes a crash when it is encountered in a subsequent bind attempt, in ch_free, slap_sasl_authorize ca. line 676. (Depending on platform malloc - NetBSD complains here but doesn't crash, Linux/glibc may or may not complain but does corrupt heap and eventually crashes.) Duplicate: Attempt SASL PLAIN bind as "" with password "" (for example) to get SASL "User not found" error. Then make one or more SASL EXTERNAL binds, until server crashes - shouldn't take but one or two. I make a supportSASLMechanisms search before the PLAIN bind, because that's what our user did when he crashed our service, but this is probably irrelevant. I do not specify a bind name in the EXTERNAL bind. Fix: in slap_sasl_bind, ca. line 1713, BER_BVZERO(&op->o_conn->c_sasl_dn) after bind fails (sc neither SASL_OK nor SASL_CONTINUE) Problem initially encountered in 2.3.24, also observed in 2.3.21 and 2.4.4. Fix tested on 2.3.21 and 2.3.24.

1 0

(ITS#4953) test043-delta-syncrepl failed (exit 1): producer and consumer databases differ
by michael＠stroeder.com 10 May '07

10 May '07

Full_Name: Michael Ströder Version: HEAD OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.125.59) michael@nb2:/usr/src/openldap-HEAD/ldap/tests> ./run -b bdb test043 Cleaning up test run directory leftover from previous run. Running ./scripts/test043-delta-syncrepl... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entries in the producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... test failed - producer and consumer databases differ

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 09 May '07

09 May '07

h.b.furuseth(a)usit.uio.no wrote: > OK, I've fixed some of it in HEAD. See comments in the commits for > tpool.c 1.63 and outwards. Quite a lot of changes, will take some time to evaluate the overall impact. > > RE23 has the same problems. Nearly identical code sans the new > semaphore stuff and a few variable names, so fixes should be easy > to import when they've been tested a bit. The semaphore stuff probably needs to be axed/unifdef'd. It is unusable, it would only result in deadlocks, and I think I already removed the slapd code that would have invoked it. > Remaining problems: > > tpool.c breaks if there are multiple pools. The simplest > solution seems to be to remove support for multiple pools. > The problem is thread_keys[]. It is shared between pools, but: slapd only uses a single pool, and that's really the only use case we care about. In fact it makes no sense to support multiple pools, because we have no mechanism to assert scheduling priorities of one pool over another. > Other thread_keys[] strangeness: > > - setkey does not free the old data with ltk_free. Possibly that's > intentional, but if so that requires weird code elsewhere. Yes, that's intentional. ltk_free is only intended for cleanup if a key is still set by the time a thread exits. All of the keys we set are live for the entire life of a thread, they don't get re-assigned. > - maybe related to how getkey can return the ltk_free function - which > seems crazy since a caller who uses it must then explicitly reset the > key afterwards (or better, before), to be sure purgekey doesn't > see the data and free it again. Nothing actually depends on returning the ltk_free function, that was just included for completeness' sake. > Other notes: > > - I've inserted new, possibly too aggressive, waits for ltp_pause in > pool_wrapper. See the tpool.c 1.65 comment. Yet another alternative > than splitting the ltp_pause state might be to remove the requirement > that purgekey() can only be used by a paused thread. (Could loop > until the key is _really_ gone instead, or something.) Will look at this later. > > - tpool.c uses LDAP_FREE(), can call ldap_pvt_thread_pool_context(), > which uses thread_keys[]. If one thread does that when another thread > has paused the pool, that can break since thread_keys[] is reserved > for ldap_pvt_thread_pool_purgekey() during pauses. Since there is only one thread pool in use, it is impossible for another thread to be active. > - ltp_pending_count includes threads sleeping in pool_pause() - should > it? In effect, pool_pause() temporarily reduces ltp_max_pending. I don't see why any special consideration is needed here. Nothing else in the thread pool is going to move while a pause is in effect. > - In ldap_pvt_thread_pool_submit(): > > This comment: > /* there is another open thread, so this > * context will be handled eventually. > * continue on and signal that the context > * is waiting. > */ > is wrong if the previous if (pool->ltp_open_count == 0) was > taken but the no thread was found inside that. The comment may be incomplete... > Also if ctx is invalid (another thread handled it) and a new > pending request has gotten the now-unused ctx, then the > 'if (pool->ltp_open_count == 0)' code will free that new > pending request instead of the old one. Most likely this is due to unlocking and relocking the mutex around the semaphore code. Axe that, remove the gratuitous unlock/relock, and then that problem goes away. > - Note, I haven't looked at the new semaphore stuff yet. > > Will get back to this later, but could use review so far. In particular > I'd like to know if we'll keep or kill multi-pool support. Thus far we've only had to worry about a single pool. If anyone can come up with a reason to need multiple pools, I guess we need to hear it. Given the lack of scheduling control, I don't see how it would be of any benefit. At the same time, I don't see a compelling reason to perturb the code at the moment. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

OK, I've fixed some of it in HEAD. See comments in the commits for tpool.c 1.63 and outwards. RE23 has the same problems. Nearly identical code sans the new semaphore stuff and a few variable names, so fixes should be easy to import when they've been tested a bit. Remaining problems: tpool.c breaks if there are multiple pools. The simplest solution seems to be to remove support for multiple pools. The problem is thread_keys[]. It is shared between pools, but: - ldap_pvt_thread_pool_purgekey() needs _all_ pools to be paused, but ldap_pvt_thread_pool_pause() only pauses one pool. If we keep multi-pool support, maybe it only should destroy keys from the current pool? - ltp_max_count (max #threads) is pool-specific, but is used to protect from array bounds violation on thread_keys[LDAP_MAXTHR]. (New simple code from me, previously there was no limit.) - This '#if 0'ed comment is also wrong with multiple pools: /* start up one thread, just so there is one. no need to * lock the mutex right now, since no threads are running. */ Time to remove the whole #if 0? Other thread_keys[] strangeness: - setkey does not free the old data with ltk_free. Possibly that's intentional, but if so that requires weird code elsewhere. - maybe related to how getkey can return the ltk_free function - which seems crazy since a caller who uses it must then explicitly reset the key afterwards (or better, before), to be sure purgekey doesn't see the data and free it again. Other notes: - I've inserted new, possibly too aggressive, waits for ltp_pause in pool_wrapper. See the tpool.c 1.65 comment. Yet another alternative than splitting the ltp_pause state might be to remove the requirement that purgekey() can only be used by a paused thread. (Could loop until the key is _really_ gone instead, or something.) - tpool.c uses LDAP_FREE(), can call ldap_pvt_thread_pool_context(), which uses thread_keys[]. If one thread does that when another thread has paused the pool, that can break since thread_keys[] is reserved for ldap_pvt_thread_pool_purgekey() during pauses. Not sure if that can happen, haven't checked. If LDAP_MALLOC/LDAP_CALLOC also can do call pool_context(), we do have problem in pool_submit(). One fix is to use malloc/calloc/free instead. Another, in the case of LDAP_FREE(ctx) in pool_submit, is to put the ctx on the free list instead. - ltp_pending_count includes threads sleeping in pool_pause() - should it? In effect, pool_pause() temporarily reduces ltp_max_pending. - In ldap_pvt_thread_pool_submit(): This comment: /* there is another open thread, so this * context will be handled eventually. * continue on and signal that the context * is waiting. */ is wrong if the previous if (pool->ltp_open_count == 0) was taken but the no thread was found inside that. Also if ctx is invalid (another thread handled it) and a new pending request has gotten the now-unused ctx, then the 'if (pool->ltp_open_count == 0)' code will free that new pending request instead of the old one. One fix is to add an is_pending flag=1 in submit() and int *ltc_pendingp; in ldap_int_thread_ctx_t. In submit, if need_thread, set ltc_pendingp = &is_pending. In if(pool->ltp_open_count == 0) check is_pending instead of searching for ctx. Elsewhere set *ltc_pendingp = 0 and/or ltc_pendingp = NULL when appropriate. - Note, I haven't looked at the new semaphore stuff yet. Will get back to this later, but could use review so far. In particular I'd like to know if we'll keep or kill multi-pool support. -- Regards, Hallvard

1 0

(ITS#4952) null CSN due to CSN length mismatch in updateCookie
by donn＠u.washington.edu 09 May '07

09 May '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) syncrepl_updateCookie finds CSN values in syncCookie and si->si_cookieState. Numerically, the syncCookie CSN is lesser, but it compares greater because it's longer: syncCookie->ctxcsn: 20070508130333Z#000000#00#000000 si->si_cookieState->cs_vals[0]: 20070507215402.502403Z#000000#000#000000 Eventually slap_queue_csn() gets a null CSN, and slapd aborts. I am pretty sure the former explains the latter. The only thing that doesn't fit is that gdb reports "j" == 20936000, where I expect 0, but I think everything else adds up - numcsns is 1, cs_num is 1, the two sids are the same (0). Evidently this format difference is entryCSN vs. contextCSN. The unusual order may be due to entries modified in the master with explicit entryCSN values. I guess that's not supported, but it seems to have exposed a bug here - I assume you want a comparison between dates, not format lengths. To reproduce (I'm guessing): modify master directory with explicit entryCSN values that are later than its contextCSN.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

Actually, tpool.c is quite buggy. I'm fixing some of them, and will summarize the rest later. -- Regards, Hallvard

1 0

Re: (ITS#4948) #if/#elif argument in .../include/ac/time.h
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

I wrote: > That said, it's indeed a reasonable cleanup. I'll do that and some > others shortly. Fixed in the cvs HEAD version. There are a few cases left though - in particular, do anyone know if #if DOS/MACOS/HAVE_WINSOCK can be replaced with #ifdef? I'm not touching them without word from someone who knows OpenLDAP on these platforms. Besides, I still don't know if the "issues" you refer to are just compiler warnings, or errors - or if the one macro you reported was a special case. So while allowing -Wundef to catch macro typos is worthwhile, I likely won't do anything more unless I hear a reason to. And I'd like to know what Plan 9 C says about this program: > BTW, will 9 C accept this (when you do not define FOO/BAR)? What > error/warning messages, if any? > > #if defined(FOO) && FOO /* Guard #if FOO with defined(FOO) */ > int main() { return 2; } > #elif BAR > int main() { return 1; } > #else > int main() { return 0; } > #endif -- Regards, Hallvard

1 0

Re: (ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

hyc(a)symas.com writes: > This seems to be a known limitation, see the FIXME in slapd/compare.c, > near SLAP_COMPARE_IN_FRONTEND. At least, that explains the problem > for back-ldif, which does not provide its own compare entry point. Looks like a bug to me, and that the correct fix is be to delete that code and let the current back-ldif return an error. Maybe it could be split out to a separate function which backends can set be_compare to if they have a be_attribute(), or something like that? > As for back-ldbm, there is a missing referral_rewrite call in > back-ldbm/referral.c. I don't consider it worthwhile to fix back-ldbm, > but you're welcome to fix it if you wish. I might, though actually I'm more concerned with failed tests than fixing ldbm at the moment:-) Will look later. However: > Just have a look at back-bdb/referral.c for the correct code. There is no correct code as yet, note the bogus logging I mentioned. -- Regards, Hallvard

1 0

(ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 08 May '07

08 May '07

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: https://www.nbcs.rutgers.edu/~richton/richton-20070508-radius.patch Submission from: (NULL) (68.196.250.105) Please find at this address a patch against the RADIUS contrib module. This patch addresses two issues: * libradius makes use of MT-Unsafe calls, so a protecting mutex is added. * config_filename could be passed to rad_config without initialization (when accepting the default). I, Aaron Richton, hereby place these modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 08 May '07

08 May '07

On Tue, May 08, 2007 at 08:42:24PM +0200, Pierangelo Masarati wrote: > ahasenack(a)terra.com.br wrote: > > > The monitor backend attributes and object classes, when loaded, should also be > > exported in the subschema entries at the server. > > > > I know of one ldap client that breaks because of this: luma. It says it can't > > display the cn=monitor entries because it doesn't know the object classes or > > attributes. I guess it uses this info to determine how to show each entry. > > The schema is not exposed since it's considered experimental. To expose > it, you need to #define LDAP_DEVEL. It doesn't see a good idea for me to define LDAP_DEVEL just to get this schema published: probably many other things in openldap would change.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by ando＠sys-net.it 08 May '07

08 May '07

ahasenack(a)terra.com.br wrote: > The monitor backend attributes and object classes, when loaded, should also be > exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it can't > display the cn=monitor entries because it doesn't know the object classes or > attributes. I guess it uses this info to determine how to show each entry. The schema is not exposed since it's considered experimental. To expose it, you need to #define LDAP_DEVEL. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 07 May '07

07 May '07

On Fri, 4 May 2007, hyc(a)symas.com wrote: >> Either the conversion should put all of the loglevel masks in the same >> olcLogLevel value or cn=config should AND all of the olcLogLevel values. > > You mean OR of course, not AND. Yes, sorry. OR, +, mask, that's what I mean. It must have been Friday. -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

1 0

Re: (ITS#4950) error LDAP Server
by quanah＠zimbra.com 07 May '07

07 May '07

--On Monday, May 07, 2007 11:03 AM +0000 thuanpvm(a)blitzgrp.com wrote: > Full_Name: Phan Van Minh Thuan > Version: 2.3.35 > OS: Linux Enterprise 4.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (58.186.92.53) > > > Dear Sirs, > > When I submit ldapadd -x -D "cn=Manager, dc=blitzcie,dc=dyndns,dc=org" -W > -f /usr/local/etc/openldap/schema/initial.ldif, the error display: > Enter LDAP password: > ldap_bin: Can't contact LDAP server (-1) > > Looking forward to hearing from you soon The ITS system is for submitting bugs about the software. You appear to be having a configuration/usage problem. Please subscribe to openldap-software(a)openldap.org and describe the problems you are having there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4950) error LDAP Server
by thuanpvm＠blitzgrp.com 07 May '07

07 May '07

Full_Name: Phan Van Minh Thuan Version: 2.3.35 OS: Linux Enterprise 4.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (58.186.92.53) Dear Sirs, When I submit ldapadd -x -D "cn=Manager, dc=blitzcie,dc=dyndns,dc=org" -W -f /usr/local/etc/openldap/schema/initial.ldif, the error display: Enter LDAP password: ldap_bin: Can't contact LDAP server (-1) Looking forward to hearing from you soon Many Thanks. Thuan

1 0

Re: (ITS#4933) syncrepl unlimited timeout vs. .ldaprc
by hyc＠symas.com 04 May '07

04 May '07

donn(a)u.washington.edu wrote: > Full_Name: Donn Cave > Version: 2.4.4 > OS: Red Hat RHEL 3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.95.135.150) > > > Appears to me that unless timelimit value passed to ldap_search_ext() is > positive, the ld_timelimit from .ldaprc overrides, so there's no way for > syncrepl ldap_sync_search() to literally specify "unlimited". > > To duplicate: configure syncrepl timelimit=unlimited; edit /.ldaprc -> > "TIMELIMIT 23"; start replica slapd with a sufficiently large replication > backlog; observe timeout at 23 seconds. > > To kludge: use extravagantly large value instead: if (si->si_tlimit > 0) > timeout.tv_sec = si->tlimit; else timeout.tv_sec = 31536000; > > and pass &timeout unconditionally. Hmmm. I guess this is a consequence of changing the timeout representation in the LDAP handle. I suppose we can just make the syncrepl consumer do an explicit ldap_set_option() on its session handles to override any .ldaprc setting. Will have to play with this a bit to see how we can maintain backward compatibility. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4948) #if/#elif argument in .../include/ac/time.h
by h.b.furuseth＠usit.uio.no 04 May '07

04 May '07

lucio(a)proxima.alt.za writes: > Whether the existing format is legitimate or not is a matter for the C > standards, but I believe that the alternative would be both clearer > and more portable. It's legitimate. In #if/#elif statements, an undefined macro (without arguments) has the value 0 in a correct compiler. That said, it's indeed a reasonable cleanup. I'll do that and some others shortly. Allows us to compile with 'gcc -Wundef' without too much noise too. I'll tests I'm not sure about alone (in particular Windows stuff), in case it's supposed to be OK to compile with '-D<macro name>=0' so a change from #if to #ifdef would change OpenLDAP's behavior. Maybe someone else can have a look at that. > The Plan 9 C pre-processor has a definite issue with it and it seems a > reasonable change to implement. There may be other places where a > similar change would be beneficial, I'll identify them as I > encountered and will provide a comprehensive list on demand. Please be specific: Give the exact error/warning message, and make clear whether it _is_ a warning or an error. BTW, will 9 C accept this (when you do not define FOO/BAR)? What error/warning messages, if any? #if defined(FOO) && FOO /* Guard #if FOO with defined(FOO) */ int main() { return 2; } #elif BAR int main() { return 1; } #else int main() { return 0; } #endif -- Regards, Hallvard

1 0

Re: (ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by hyc＠symas.com 04 May '07

04 May '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.35 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.93.52) > > > When a slapd.conf file is converted to cn=config with -f and -F the loglevel > parameter gets converted into multiple olcLogLevel=keyword attribute/value > pairs. However, only the last one in the configuration seems to apply. > Manually updating > dn: cn=config > changetype: modify > replace: olcLogLevel > olcLogLevel: keyword1 keyword2 ... > - > > gets the intended logging behavior. > > Either the conversion should put all of the loglevel masks in the same > olcLogLevel value or cn=config should AND all of the olcLogLevel values. You mean OR of course, not AND. Yes, the code only does ORs correctly when multiple levels are set at once. Oops. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 04 May '07

04 May '07

Full_Name: Eric Irrgang Version: 2.3.35 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.93.52) When a slapd.conf file is converted to cn=config with -f and -F the loglevel parameter gets converted into multiple olcLogLevel=keyword attribute/value pairs. However, only the last one in the configuration seems to apply. Manually updating dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: keyword1 keyword2 ... - gets the intended logging behavior. Either the conversion should put all of the loglevel masks in the same olcLogLevel value or cn=config should AND all of the olcLogLevel values.

1 0

(ITS#4948) #if/#elif argument in .../include/ac/time.h
by lucio＠proxima.alt.za 04 May '07

04 May '07

Full_Name: Lucio De Re Version: 2.3.35 and earlier OS: Plan 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.255.250) The arguments on lines 20 and 23 (#if and #elif, respectively) in .../include/ac/time.h ought to be surrounded with "defined()". Whether the existing format is legitimate or not is a matter for the C standards, but I believe that the alternative would be both clearer and more portable. The Plan 9 C pre-processor has a definite issue with it and it seems a reasonable change to implement. There may be other places where a similar change would be beneficial, I'll identify them as I encountered and will provide a comprehensive list on demand. Naturally, there are many other issues applicable specific to porting OpenLDAP to Plan 9, but these seem trivial enough to warrant addressing in a broader context.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by quanah＠zimbra.com 04 May '07

04 May '07

--On Friday, May 04, 2007 2:39 PM +0000 ahasenack(a)terra.com.br wrote: > Full_Name: Andreas Hasenack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > (enhancement, or minor) > > The monitor backend attributes and object classes, when loaded, should > also be exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it > can't display the cn=monitor entries because it doesn't know the object > classes or attributes. I guess it uses this info to determine how to show > each entry. Not disagreeing, but making the assumption that cn=subschema is readable is also a broken behavior on the luma side. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 04 May '07

04 May '07

Full_Name: Andreas Hasenack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) (enhancement, or minor) The monitor backend attributes and object classes, when loaded, should also be exported in the subschema entries at the server. I know of one ldap client that breaks because of this: luma. It says it can't display the cn=monitor entries because it doesn't know the object classes or attributes. I guess it uses this info to determine how to show each entry.

1 0

Re: (ITS#4830) test030-relay fails with back-meta
by ghenry＠suretecsystems.com 03 May '07

03 May '07

<quote who="hyc(a)symas.com"> > ahasenack(a)terra.com.br wrote: >> On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: >>> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' >>> ==> rewrite_context_apply [depth=1] res={0,'NULL'} >>> [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" >>> /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: >>> symbol lookup error: >>> +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: >>> ldap_back_proxy_authz_ctrl >> >> Howard debugged this on IRC and it turns out that our (mine and >> _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd >> without the unixodbc lib fixes it. > > Yes, so there are two potential issues - the unixodbc shared library seems > to > be statically linked with an older version of libltdl. I didn't run into > this > problem on my build because I don't have that odbc library. Anyway, due to > the link order of the libraries, the lt_dlopen in this library gets used > before the linker resolves to the system's libltdl.so, and it seems that > this > version of lt_dlopen doesn't automatically export the symbols of modules > that > it loads. > > I'm guessing the reason this is a problem in 2.3.33 and not in 2.3.32 is > because there is a new dependency in 2.3.33 between back-meta and > back-ldap. > > The other part of this is that the slapd binary should not be getting > linked > against -lodbc when back_sql is built as a module. > > Although, if back-sql is built statically, and other backends are dynamic, > this problem may still crop up. It seems that fixing -lodbc would be > required > then. I've hit this same problem tonight (no sql though): ./scripts/test030-relay: line 78: kill: (7779) - No such process >>>>> ./scripts/test030-relay failed (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/home/suretec/src/openldap-2.3.35/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/suretec/src/openldap-2.3.35/tests' make: *** [test] Error 2 slapd.1.log: /home/suretec/src/openldap-2.3.35/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: ldap_back_proxy_authz_ctrl Config options were: env CC=/usr/local/bin/gcc CPPFLAGS="-I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/include/sasl" \ LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/lib/sasl2" \ LIBS="-ldl" \ LD_LIBRARY_PATH="/usr/local/ssl/lib /usr/local/BerkeleyDB.4.2/lib /usr/local/lib/sasl2" ./configure \ --prefix=/usr/local --enable-slapd --enable-syslog \ --enable-dynamic --enable-rewrite --disable-sql --disable-ipv6 --disable-shell \ --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers On Debian Sarge 3.1 with custom compiled: openssl-0.9.8e cyrus-sasl-2.1.22 db-4.2.52 heimdal-0.8.1 I can't get past it. Any debug advice? 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/

1 0

(ITS#4945) slapd drops connections during search results
by mhardin＠symas.com 03 May '07

03 May '07

Full_Name: Matthew Hardin Version: 2.3.35 OS: Windows 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.67.85) If Winsock returns EWOULDBLOCK while sending search results to a client, slapd will stop sending results and close the connection. The problem is in openldap/servers/slapd/result.c at line 173, where it incorrectly checks errno. It should be checking sock_errno(). I note that HEAD already does this.

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by hyc＠symas.com 03 May '07

03 May '07

Looks like your OpenSSL library depends on -ldl. That's an OpenSSL build problem, not OpenLDAP. Can probably get around it by adding -ldl to LIBS on the configure invocation. This ITS will be closed. ghenry(a)suretecsystems.com wrote: > <quote who="Howard Chu"> >> It works for me. Check your config.log to see why it didn't link. > > Here's the main probs: > > configure:19501: /usr/local/bin/gcc -E -I/usr/local/ssl/include > -I/usr/local/BerkeleyDB.4.2/include conftest.c > configure:19507: $? = 0 > configure:19527: result: yes > configure:19562: checking for openssl/ssl.h > configure:19569: result: yes > configure:19584: checking for SSL_library_init in -lssl > configure:19614: /usr/local/bin/gcc -o conftest -g -O2 > -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl > -lcrypto -lresolv >&5 > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ae): In function > `dlfcn_bind_func': > : undefined reference to `dlsym' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x333): In function > `dlfcn_bind_func': > : undefined reference to `dlerror' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x3ae): In function > `dlfcn_bind_var': > : undefined reference to `dlsym' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x431): In function > `dlfcn_bind_var': > : undefined reference to `dlerror' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x497): In function > `dlfcn_unload': > : undefined reference to `dlclose' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x557): In function > `dlfcn_load': > : undefined reference to `dlopen' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5b5): In function > `dlfcn_load': > : undefined reference to `dlclose' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5ec): In function > `dlfcn_load': > : undefined reference to `dlerror' > collect2: ld returned 1 exit status > configure:19620: $? = 1 > configure: failed program was: > | /* confdefs.h. * > > | char SSL_library_init (); > | int > | main () > | { > | SSL_library_init (); > | ; > | return 0; > | } > configure:19646: result: no > configure:19657: checking for ssl3_accept in -lssl > configure:19687: /usr/local/bin/gcc -o conftest -g -O2 > -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl > -lcrypto -lRSAglue -lrsaref -lresolv >&5 > /usr/bin/ld: cannot find -lRSAglue > collect2: ld returned 1 exit status > configure:19693: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > > > Like I said, this didn't happen in 0.9.7, will check my built options with > 0.9.8 > > Gavin. > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by ghenry＠suretecsystems.com 03 May '07

03 May '07

<quote who="Howard Chu"> > It works for me. Check your config.log to see why it didn't link. Here's the main probs: configure:19501: /usr/local/bin/gcc -E -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include conftest.c configure:19507: $? = 0 configure:19527: result: yes configure:19562: checking for openssl/ssl.h configure:19569: result: yes configure:19584: checking for SSL_library_init in -lssl configure:19614: /usr/local/bin/gcc -o conftest -g -O2 -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl -lcrypto -lresolv >&5 /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ae): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x333): In function `dlfcn_bind_func': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x3ae): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x431): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x497): In function `dlfcn_unload': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x557): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5b5): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5ec): In function `dlfcn_load': : undefined reference to `dlerror' collect2: ld returned 1 exit status configure:19620: $? = 1 configure: failed program was: | /* confdefs.h. * | char SSL_library_init (); | int | main () | { | SSL_library_init (); | ; | return 0; | } configure:19646: result: no configure:19657: checking for ssl3_accept in -lssl configure:19687: /usr/local/bin/gcc -o conftest -g -O2 -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl -lcrypto -lRSAglue -lrsaref -lresolv >&5 /usr/bin/ld: cannot find -lRSAglue collect2: ld returned 1 exit status configure:19693: $? = 1 configure: failed program was: | /* confdefs.h. */ Like I said, this didn't happen in 0.9.7, will check my built options with 0.9.8 Gavin.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs