- openldap-bugs - openldap.org

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 01 Jun '10

01 Jun '10

* alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2010-01-19 07:25:25 +0000]: > * alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2009-11-05 07:43:02 +0000]: > > OpenLDAP 2.4.22, 8.1-PRERELEASE is still crashed. > > > New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed. > I can make a public test server, to let some one check my configs and > see faults. > > Also intresting have any body same failures? > > > > > > Full_Name: Aleksey > > Version: 2.4.19 > > OS: Freebsd7.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.93.136.26) > > > > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 > > Slapd built with the "-g" flag and install with the make install STRIP="" > > > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > In slapd config added using hdb as backend and indexes. > > > > Testing database consist of 1000 users accounts with minimum attributes. > > > > On stress test load slapd Segmentation fault in 10-30 sec. > > > > > > #ldd /usr/local/libexec/slapd > > /usr/local/libexec/slapd: > > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) > > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) > > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) > > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) > > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) > > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) > > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) > > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) > > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) > > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) > > libc.so.7 => /lib/libc.so.7 (0x8015f5000) > > > > > > > > > > #gdb /usr/local/libexec/slapd > > (gdb) run -d 0 > > Starting program: /usr/local/libexec/slapd -d 0 > > [New LWP 100311] > > [New Thread 0x801a020b0 (LWP 100311)] > > [New Thread 0x801a02880 (LWP 100073)] > > [New Thread 0x8034040b0 (LWP 100076)] > > [New Thread 0x803404240 (LWP 100077)] > > [New Thread 0x8034043d0 (LWP 100078)] > > [New Thread 0x803404560 (LWP 100116)] > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > 511 { > > (gdb) > > (gdb) > > (gdb) where > > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > > address 0x7ffffd9f9f38: dress. > > ) at idl.c:511 > > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > > txn=0x80352b040, k=0x8069005 > > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > > ava=0x7ffffda7a4f0, > > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a550, > > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > > filterindex.c:581 > > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a530, > > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > > filterindex.c:581 > > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a570, > > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > > e=0x7ffffda7a71 tx > > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:586 > > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:366 > > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:217 > > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > > arg_v=0x803521000) at connection > > .c:1123 > > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > > at connection.c:125 > > 9 > > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > > /usr/local/lib/libldap_r-2.4.so. > > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > > #16 0x0000000000000000 in ?? () > > Error accessing memory address 0x7ffffdbfb000: Bad address. -- alexs

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 01 Jun '10

01 Jun '10

On Jun 2, 2010, at 1:08 AM, hyc(a)symas.com wrote: > ssalley(a)likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> Submission from: (NULL) (67.51.54.234) >>=20 >>=20 >> Note that a similar issue/contribution was submitted in 2008 = (Contrib/5369) and >> appears to have been 'lost'. >=20 >> The patch = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> makes it possible to use the GSSAPI support in OpenLDAP by: >>=20 >> 1. Defining --with-gssapi in configure which >> a. Checks for appropriate header files >> b. Checks for the appropriate library >> c. Defines HAVE_GSSAPI to 1 in everything is in order >>=20 >> 2. Exposing ldap_gssapi_bind_s in ldap.h >=20 > I am still disinclined to publish any of this. The standard mechanism = for=20 > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more=20= > non-standard one-off ldap_XXX_bind flavors. It's a poor design = approach and it=20 > increases our support workload for no appreciable gain. It increases=20= > application developer's workload as well, if they have to test for the=20= > existence of multiple flavors of ldap_XXX_bind and code for them each=20= > separately in their apps. I concur and add: At one time I thought it might be useful to implement = a few SASL mechanisms directly in libldap for cases where one didn't = want to suck in a SASL library. But for most mechanisms removing the = SASL library is worth it in my eyes, especially any mechanism other than = PLAIN or EXTERNAL. But where this is worth it, it should be done = through existing APIs. Adding mech specific APIs should be avoided. >=20 > If you really want to have "direct" access to other authentication = mechanisms, > the right way to do this is by adding new LDAP_AUTH_xxx definitions = that can=20 > be muxed out from a single ldap_bind API. I could see adding new API to support new authentication frameworks to = which LDAP was extended to support. For instance, if LDAP was extended = to directly support GSS API mechanisms, then adding LDAP_AUTH_GSSAPI = would make sense (here GSS API refers to the GSS API not the SASL = Kerberos mechanism called GSSAPI). But for security reasons, it = unlikely this will ever happen, =20 > Of course, by the time you've=20 > implemented option parsing so that generic client code can be = configured with=20 > arbitrary Bind mechanisms, you would have re-implemented SASL. >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20

1 0

Re: (ITS#6536) Autogroup overlay enhancement
by hyc＠symas.com 01 Jun '10

01 Jun '10

raphael.ouazana(a)linagora.com wrote: > Full_Name: Raphael Ouazana > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-autogroup-100427.patch > Submission from: (NULL) (213.41.232.151) > > > Hi, > > The attached patch allow the autogroup overlay to handle correctly the attr part > of the URL ldap://dc=example,dc=com?attr?sub?(filter). Before this patch, the > attr part was simply ignored. Now the group entry is populated by the values of > the attribute attr in the resulting entries. > > Implementation details: > Some cases (modify, delete) are harder to handle when you store values instead > of dn. In this cases the overlay try to detect if groups have been modified and > then simply refresh them. This can cause performance hits if the search > specified by the URL deals with an important number of entries. > > Legal notice: > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in this following patch were developed by Raphael > Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to > any > license of Linagora. > > The attached modifications to OpenLDAP Software are subject to the following > notice: > Copyright 2010 Raphael Ouazana, Linagora > Redistribution and use in source and binary forms, with or without > modification, > are permitted only as authorized by the OpenLDAP Public License. The code patch looks OK to me, but could you also provide a patch for the README file summarizing this new behavior? I'm not too keen on supporting groups of anything other than DNs in general, but I see the usefulness of it. However the potential performance hit can be quite a concern. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6569) patch: Set ld_errno on error.
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Ubuntu > URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… > Submission from: (NULL) (67.51.54.234) > > > The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… > ensures ld_errno is set to an error when there is no valid result. > Thanks for the report. Actually the Notice of Disconnect comes with an error code from the server, and that's actually what should be returned to the client here. Fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6568) patch: Memory leak in connectionless
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Ubuntu > URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… > Submission from: (NULL) (67.51.54.234) > > > The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… > closes memory leaks associated with using connectionless mode. > Thanks for the patch, applied to HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Linux > URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… > Submission from: (NULL) (67.51.54.234) > > > Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and > appears to have been 'lost'. > The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… > makes it possible to use the GSSAPI support in OpenLDAP by: > > 1. Defining --with-gssapi in configure which > a. Checks for appropriate header files > b. Checks for the appropriate library > c. Defines HAVE_GSSAPI to 1 in everything is in order > > 2. Exposing ldap_gssapi_bind_s in ldap.h I am still disinclined to publish any of this. The standard mechanism for using GSSAPI in LDAP is via SASL. I see no benefit to propagating more non-standard one-off ldap_XXX_bind flavors. It's a poor design approach and it increases our support workload for no appreciable gain. It increases application developer's workload as well, if they have to test for the existence of multiple flavors of ldap_XXX_bind and code for them each separately in their apps. If you really want to have "direct" access to other authentication mechanisms, the right way to do this is by adding new LDAP_AUTH_xxx definitions that can be muxed out from a single ldap_bind API. Of course, by the time you've implemented option parsing so that generic client code can be configured with arbitrary Bind mechanisms, you would have re-implemented SASL. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6569) patch: Set ld_errno on error.
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Ubuntu URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… Submission from: (NULL) (67.51.54.234) The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… ensures ld_errno is set to an error when there is no valid result.

1 0

(ITS#6568) patch: Memory leak in connectionless
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Ubuntu URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… Submission from: (NULL) (67.51.54.234) The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… closes memory leaks associated with using connectionless mode.

1 0

(ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Linux URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… Submission from: (NULL) (67.51.54.234) Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and appears to have been 'lost'. The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… makes it possible to use the GSSAPI support in OpenLDAP by: 1. Defining --with-gssapi in configure which a. Checks for appropriate header files b. Checks for the appropriate library c. Defines HAVE_GSSAPI to 1 in everything is in order 2. Exposing ldap_gssapi_bind_s in ldap.h

1 0

(ITS#6566) rwm, ppolicy, sssvlv, and valsort display warnings on STDERR
by mhardin＠symas.com 01 Jun '10

01 Jun '10

Full_Name: Matt Hardin Version: 2.4.22 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.117.141) rwm, ppolicy, sssvlv, and valsort display warnings on STDERR, not syslog. It seems these warnings should go into syslog instead.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 01 Jun '10

01 Jun '10

> Hi, > this is a partly duplicate of ITS 6463: I think it's better to split > these 2 > items into 2 separate ITS. > > This ITS only describes the behaviour of OpenLDAP using referrals > generated by > DNSSRV; just ldap (no ldaps) is used. > > You stated that not returning DNs in DNSSRV "conforms to RFC4511". This > seems to > be OK. Nevertheless these returned URLs are used in the chaining code. > > This means that the chained search always searches with base "" (root). I > don't > think that this the right behavior. > > I debugged the code several hours but couldn't find a solution. What I > could > see: > - dnssrv_back_referrals just puts server names into the referral structure > ("ref") > - the functions called afterwards - esp. ldap_chain_op - parse this > structure > "ref" for server names AND DNs (search bases) > > I'm sorry, my knowledge of the OpenLDAP code is not deep enough to propose > a > solution. But I think that this should be fixed: Chained Searches with "" > as > search base in a distributed environment can't really work: problems like > - some servers don't support this kind of search > - loop detection > - access control > are there. Hi. I don't have time to work at this right now, but I think the solution would be to modify slapo-chain(5) so that when a referral's DN is "" and the DN in the original request is not "", to use that DN instead. The original request DN can be found in op->o_req_dn. p.

1 0

(ITS#6565) DNSSRV referrals: chaining without search base
by jochen＠keutel.de 01 Jun '10

01 Jun '10

Full_Name: Jochen Keutel Version: 2.4.22 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.200.236) Hi, this is a partly duplicate of ITS 6463: I think it's better to split these 2 items into 2 separate ITS. This ITS only describes the behaviour of OpenLDAP using referrals generated by DNSSRV; just ldap (no ldaps) is used. You stated that not returning DNs in DNSSRV "conforms to RFC4511". This seems to be OK. Nevertheless these returned URLs are used in the chaining code. This means that the chained search always searches with base "" (root). I don't think that this the right behavior. I debugged the code several hours but couldn't find a solution. What I could see: - dnssrv_back_referrals just puts server names into the referral structure ("ref") - the functions called afterwards - esp. ldap_chain_op - parse this structure "ref" for server names AND DNs (search bases) I'm sorry, my knowledge of the OpenLDAP code is not deep enough to propose a solution. But I think that this should be fixed: Chained Searches with "" as search base in a distributed environment can't really work: problems like - some servers don't support this kind of search - loop detection - access control are there. Regards, Jochen.

1 0

ITS#6564
by masarati＠aero.polimi.it 28 May '10

28 May '10

Is this a joke or what? Version 2.2.23 was released about 2005 (as stated by the log message you report). The current release is 2.4.22. The LDIF you're reporting dn: dc=HVRNG1,dc=com objectclass: dcObject objectclass: comanization o: Domain Server dc: HVRNG1 dn: cn=root,dc=HVRNG1,dc=com objectclass: comanizationalRole cn: root clearly contains a typo (twice), assuming by "comanization" you mean "organization". You need to leave one blank like between entries. In any case, the ITS is intended to report software bugs; usage questions should be directed to openldap-technical(a)openldap.org (you need to subscribe first). This ITS will be closed. p.

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 28 May '10

28 May '10

I now have a fully patched (with the stuff on the oracle/sleepycat) build with db-4.6.21, and it seems to be working correctly with the patches. You can close the its, sorry for the noise and thanks for the help.

1 0

(ITS#6564) Problem of parsing
by herve.gouyet＠free.fr 28 May '10

28 May '10

Full_Name: herve gouyet Version: vendredi 21 octobre 2005, 16:04:16 OS: Windows XP PRO URL: Submission from: (NULL) (82.241.150.119) I don't know the version but its probably the last (i try to install openLdap this week). slapd.exe : $OpenLDAP: slapd 2.2.29 (Oct 21 2005 16:01:14) $ My problem is that i receive the message slapadd : could not parse entry when i run "slapadd -f slapd.conf -l init.ldif". I try to had or remove blanks everywhere. Everytime it's the same error, line number = the last line +1 I search on google, but all propositions found give the same result. My last try of init.ldif --------------------------- dn: dc=HVRNG1,dc=com objectclass: dcObject objectclass: comanization o: Domain Server dc: HVRNG1 dn: cn=root,dc=HVRNG1,dc=com objectclass: comanizationalRole cn: root my ldap.conf ------------------- # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # ucdata-path ./ucdata include ./schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:/root.openldap.org pidfile ./run/slapd.pid argsfile ./run/slapd.args # Load dynamic backend modules: # modulepath ./libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=HVRNG1,dc=com" rootdn "cn=Manager,dc=HVRNG1,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory ./data # Indices to maintain index objectClass eq Thanks Hervé GOUYET

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 27 May '10

27 May '10

On Thu, May 27, 2010 at 8:43 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wr= ote: > Is that BDB 4.6.21 with or without the patches from Sleepycat/Oracle? =C2= =A0IIRC > they are required to be in place to have a functioning BDB build. > This is straight 4.6.21 without the oracle patches. I am working on building a new package with the patches. I will report back if a patched BDB fixes the problems.

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by quanah＠zimbra.com 27 May '10

27 May '10

--On Wednesday, May 26, 2010 10:54 PM -0700 Aravind Gottipati=20 <aravind(a)freeshell.org> wrote: > On Wed, May 26, 2010 at 8:38 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> > wrote: >> You should use db_recover from the appropriate bdb release to clean them >> up. =C2=A0Not ipcrm. =C2=A0You also fail to note which version of BDB = you are >> linked against. =C2=A0I've certainly never seen this issue. > > I am using Berkeley DB 4.6.21. > > I didn't think to use a db_recover right after slapadd was done since > I assumed that it would be a clean database. When slapd didn't start, > I did try a db_recover, but it didn't help. Is that BDB 4.6.21 with or without the patches from Sleepycat/Oracle? IIRC = they are required to be in place to have a functioning BDB build. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de 27 May '10

27 May '10

Hi, I have run slapd in valgrind now. The full log kan be found here: http://pastebin.de/6914 In short, valgrind reported following error: =20 =3D15353=3D=3D 1 errors in context 1 of 5: =3D=3D15353=3D=3D Invalid write of size 4 =3D=3D15353=3D=3D at 0x80E64B5: slap_sl_free (sl_malloc.c:492) =3D=3D15353=3D=3D by 0x80A0EEA: ch_free (ch_malloc.c:137) =3D=3D15353=3D=3D by 0x80E3DC9: mra_free (mra.c:43) =3D=3D15353=3D=3D by 0x80855B0: filter_free_x (filter.c:556) =3D=3D15353=3D=3D by 0x80836CD: do_search (search.c:230) =3D=3D15353=3D=3D by 0x8080588: connection_operation (connection.c:1109) =3D=3D15353=3D=3D by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:68= 5) =3D=3D15353=3D=3D by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.= so) =3D=3D15353=3D=3D by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so) =3D=3D15353=3D=3D Address 0x843692b1 is not stack'd, malloc'd or (recently= ) free'd -Dieter --=20 Dieter Kl=C3=BCnter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 26 May '10

26 May '10

On Wed, May 26, 2010 at 8:38 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wr= ote: > You should use db_recover from the appropriate bdb release to clean them = up. > =C2=A0Not ipcrm. =C2=A0You also fail to note which version of BDB you are= linked > against. =C2=A0I've certainly never seen this issue. I am using Berkeley DB 4.6.21. I didn't think to use a db_recover right after slapadd was done since I assumed that it would be a clean database. When slapd didn't start, I did try a db_recover, but it didn't help. Aravind.

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by quanah＠zimbra.com 26 May '10

26 May '10

--On Wednesday, May 26, 2010 10:45 PM +0000 aravind(a)freeshell.org wrote: > Full_Name: Aravind Gottipati > Version: 2.4.21 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.245.220.240) > > > I have enabled shared memory in my slapd.conf file. With this setup, it > appears that slapadd does not release the shared memory segments once its > done. This prevents the ldap server from starting up after, because it > complains that these shared memory segments are in use. > > To reproduce: > With shm_key enabled in the slapd.conf file, slapdd a (hdb) database. > Try to then start up slapd. > > Work around: > When you slapadd the database, turn off shared memory settings in the > slapd.conf file. Re-enable it after slapadd is done. > > I have tried cleaning up those segments with ipcrm, but ipcrm simply says > that the memory segments are already removed. Its lying to you, those > segments are still there (ipcs lists them). > > Please let me know if I can get any you any more information to help with > the troubleshooting. I am not sure if you'd see the same issues with a > bdb backend (I use hdb, but afaik they are pretty similar). You should use db_recover from the appropriate bdb release to clean them up. Not ipcrm. You also fail to note which version of BDB you are linked against. I've certainly never seen this issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 26 May '10

26 May '10

A new patch is available here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-05-26-add-if-not-p…> It includes support for SLAP_MOD_SOFTDEL (see discussion here <http://www.openldap.org/lists/openldap-devel/201005/msg00003.html>). p.

1 0

(ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 26 May '10

26 May '10

Full_Name: Aravind Gottipati Version: 2.4.21 OS: RHEL 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.245.220.240) I have enabled shared memory in my slapd.conf file. With this setup, it appears that slapadd does not release the shared memory segments once its done. This prevents the ldap server from starting up after, because it complains that these shared memory segments are in use. To reproduce: With shm_key enabled in the slapd.conf file, slapdd a (hdb) database. Try to then start up slapd. Work around: When you slapadd the database, turn off shared memory settings in the slapd.conf file. Re-enable it after slapadd is done. I have tried cleaning up those segments with ipcrm, but ipcrm simply says that the memory segments are already removed. Its lying to you, those segments are still there (ipcs lists them). Please let me know if I can get any you any more information to help with the troubleshooting. I am not sure if you'd see the same issues with a bdb backend (I use hdb, but afaik they are pretty similar).

1 0

(ITS#6562) nssov in OpenLDAP 2.4.22 doesn't build
by fahadsadah＠gmail.com 26 May '10

26 May '10

Full_Name: Fahad Sadah Version: 2.4.22 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.31.135.30) Chris Breneman recently filed a bug (#6488, http://www.openldap.org/its/index.cgi?findid=6488) about nssov, and submitted a patch. The patch was correctly applied in CVS. In release 2.4.22, most of the code has Chris' patch applied, but one file, network.c, isn't patched. This is stopping nssov from building.

1 0

Re: (ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 25 May '10

25 May '10

A patch is available here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-05-25-add-if-not-p…> p.

1 0

(ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 25 May '10

25 May '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando I need to implement a modify operation whose semantics is "add if not present", an add that only takes place if that attribute is not yet present in the entry. I need it as an internal operation, so right now I wouldn't bother formalizing it as an extension of the semantics of the modify operation. Something like the SLAP_MOD_SOFTADD, which in turn consists in adding an attribute value only if that value is not already present. See <http://www.openldap.org/lists/openldap-devel/201005/msg00000.html> for discussion. I have introduced a SLAP_MOD_ADD_IF_NOT_PRESENT flag and added code to support it in back-bdb/hdb. It works as intended. I plan to extend its support to all backends and overlays. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs