openldap-bugs May 2010

openldap-bugs@openldap.org

28 participants
84 discussions

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2010