April 2013 - openldap-bugs

Re: (ITS#7573) back-perl not working with cn=config

by quanah＠zimbra.com

--On Thursday, April 11, 2013 6:20 PM +0000 benintechnologies(a)yahoo.fr wrote: > Like I said, if I set back-perl up in slapd.conf mode and then convert it > to cn=config, everything works fine. So how does the ldif generated by slaptest differ from what you are loading? If you slapcat your config that doesn't work, and compare it to the slapcat of what was generated from slaptest, what are the differences? Can you provide a gdb backtrace of the segmentation fault? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

10 years, 8 months

1
0
0 / 0

(ITS#7573) back-perl not working with cn=config

by benintechnologies＠yahoo.fr

Full_Name: Ben Version: 2.4.34 OS: Debian 6.0.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (41.79.217.116) Hi, I'm unable to set up a back-perl backend directly in cn=config mode. However, if I set it up in slapd.conf mode, and then convert it to cn=config mode, it works fine. It's not convenient, because I have to set all my perl backends up before converting to cn=config. Here's the ldif file I'm using to set up a back-perl backend in cn=config mode (it's inspired from the files I get by converting slapd.conf into cn=config with slaptest) # Load dynamic backend modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/local/libexec/openldap olcModuleload: back_perl.la # Database settings dn: olcDatabase=perl,cn=config objectClass: olcDatabaseConfig objectClass: olcDbPerlConfig olcDatabase: perl olcSuffix: dc=mydomain,dc=org olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=mydomain,dc=org olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcPerlModulePath: /usr/local/etc/openldap/perl olcPerlModule: SampleLDAP olcPerlFilterSearchResults: FALSE And here's what I get when I try to load the file: ldapadd -Y EXTERNAL -H ldapi:/// -f perl-backend.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" adding new entry "olcDatabase=perl,cn=config" ldap_result: Can't contact LDAP server (-1) After that, if I start OpenLDAP I get a segmentation fault: root@ldap:/tmp# /usr/local/libexec/slapd -u openldap -g openldap -h "ldap:/// ldapi:///" -d 16383 . 51585496 perl backend db init Segmentation fault Like I said, if I set back-perl up in slapd.conf mode and then convert it to cn=config, everything works fine. Ben

10 years, 8 months

1
0
0 / 0

ITS#6365 Fwd: RE: truncated slapcat output

by hyc＠symas.com

Fix verified. -------- Original Message -------- Subject: RE: truncated slapcat output Date: Thu, 11 Apr 2013 07:15:17 +0000 From: Hummel, Wolfgang <wolfgang.hummel(a)hp.com> To: Howard Chu <hyc(a)symas.com> Hello Howard, we tested your fix for truncated slapcat and it works fine. Please see test report below. As I am not familiar with your processes in commenting on bugfixes could you use the attached test report and commit the fix so it will become part of next release ? Thanks a lot for your support Regards Wolfgang Hummel Test execution timeframe: April 9th and 10th 2013 Test platform: Hardware HP DL380 G5, 32 GB Memory, 2 Quadcore CPUs OS RedHat 5.1 OpenLDAP 2.4.32 without / with slapcat truncate bugfix bdb backend Test setup: - Subscriber profile DB with 1 Mio. entries, each with 10 attributes Test execution: - ldapbenchmark.pl executing ~ 5 ldapmodifies and ~ 2 ldapsearches / second - slapcat_vfhu_vm_profiles.sh running slapcat in a cycle and counting entries Test result without slapcat truncate bugfix: - 1826 measurements of entry number - 23 events with truncated slapcat output - slapcat return code was always 0 ! Test result with slapcat truncate bugfix: - 1647 measurements of entry number - 0 events with truncated slapcat output script to measure it: #!/bin/bash # run slapcat forever and always count number of entries # they should always be the same while : do slapcat -b ou=vm,ou=profiles,ou=xxxx,c=hu,o=yyyy|grep "^dn:"|wc -l >>vfhu_vm_entries.txt echo "Slapcat Return Code: $?; `date`">>vfhu_vm_entries.txt sleep 1 done log snippet with bug fix: Slapcat Return Code: 0; Wed Apr 10 22:12:42 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:05 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:28 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:52 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:14:16 CEST 2013 1000001 log snippet without bugfix: 1000001 Slapcat Return Code: 0; Wed Apr 10 01:01:45 CEST 2013 319284 Slapcat Return Code: 0; Wed Apr 10 01:02:07 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:03:15 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:03:42 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:04:09 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:04:37 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:05:04 CEST 2013 437990 Slapcat Return Code: 0; Wed Apr 10 01:05:16 CEST 2013 146790 Slapcat Return Code: 0; Wed Apr 10 01:05:21 CEST 2013 72688 Slapcat Return Code: 0; Wed Apr 10 01:05:25 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:05:50 CEST 2013 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Dienstag, 26. März 2013 18:09 To: Hummel, Wolfgang Subject: Re: truncated slapcat output Hummel, Wolfgang wrote: > Hello Howard, > > we are facing in production of our major customer VF the same problems as > described in > > http://www.openldap.org/lists/openldap-technical/201301/msg00232.html > > We are using back-bdb and slapcat to create nightly ldif backups of all DBs > > where 2 of them each contains ~ 40 Mio. entries. > > Even though write traffic is low when the slapcat job runs, every 1 - 2 weeks > > output is truncated without error msg or error return code which creates problems > > for subsequent batch jobs. > > Therefore a slapcat that retries like slapd if a page is locked would be > > really important for us. > > 2 Questions: > > - Is the slapcat retry mechanism the fix you described in > http://www.openldap.org/lists/openldap-technical/201301/msg00232.html ? The patch for ITS#6365 was committed to master commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 Author: Howard Chu <hyc(a)openldap.org> Date: Thu Feb 7 18:23:25 2013 +0000 ITS#6365 wait for read locks in tool mode > - When will it be available in OpenLDAP ? When somebody follows up to the ITS and confirms that the patch fixes the issue. So far nobody has followed up. You're welcome to test and followup. > > Regards > > Wolfgang Hummel > > ---------------------------------------------------------- > > Postal Address: Hewlett-Packard GmbH > > Wolfgang Hummel > > Enterprise Services > > _/ Communication & Media Solutions > > _/ Herrenberger Str. 140 > > _/_/_/ _/_/_/ 71034 Böblingen > > _/ _/ _/ _/ Phone: +49 7031 14-7375 > > _/ _/ _/_/_/ Fax: +49 711 18562024 > > _/ mobile: +49 151 14751791 > > _/ E-Mail: wolfgang.hummel(a)hp.com > <mailto:wolfgang.hummel@hp.com> > > ---------------------------------------------------------- > > http://www.hp.com/de > > Hewlett-Packard GmbH, Herrenberger Str. 140, 71034 Böblingen > > Geschäftsführer: Volker Smid (Vorsitzender), Martin Kinne, Heiko Meyer, Ernst > Reichart, Rainer Sterk Vorsitzender des Aufsichtsrates: Jörg Menno Harms Sitz > der Gesellschaft: Böblingen, Amtsgericht Stuttgart HRB 244081, WEEE-Reg.-Nr. > DE 30409072 > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

10 years, 8 months

1
0
0 / 0

(ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour

by claude.brisson＠gmail.com

Full_Name: Claude Brisson Version: HEAD OS: linux 64 URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MU... Submission from: (NULL) (84.103.74.130) In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, F_DUPDATA is not set for this key, and there is no sub-cursor. In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is broken because they make the assumption that there is always a sub-cursor for DUP data, which is only true for keys with more than one DUP data. This patch address this specific issue. Notice: I, Claude Brisson, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

10 years, 8 months

1
0
0 / 0

Re: (ITS#7568) [Patch] Minor documentation fixes

by hyc＠symas.com

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.132.186.34) > > > I'm attaching two patches that fix minor documentation issues in ldap.conf.5 and > slaptest's usage output. Thanks, added to master. > http://jsynacek.fedorapeople.org/openldap/jsynacek-20130409-0001-Fix-typo... > http://jsynacek.fedorapeople.org/openldap/jsynacek-20130409-0002-Add-Q-to... Personally I don't see much point to -Q here; the purpose of slaptest is to tell you what errors are there. With -Q you get no useful information when an error occurs. Judging from the fact that no one has noticed this omission in the 6 years since -Q was added, I don't believe this particular feature has been of any importance one way or the other. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

10 years, 8 months

1
0
0 / 0

(ITS#7569) Patch: fixed a group enumeration bug in nssov

by tedcheng＠symas.com

Full_Name: Ted C. Cheng Version: HEAD OS: Solaris 8, 10, Linux URL: https://dl.dropbox.com/u/94235048/symas2255.patch Submission from: (NULL) (76.174.250.179) Importing a patch from Symas #2255 that fixed a group enumeration bug in nssov. The "rc" variable was not initialized in nssov write_group function. Theoretically, this bug should affect all platforms. Solaris 8 (64-bit) caught the bug because rc got a non-zero value when not initialized.

10 years, 8 months

1
0
0 / 0

Re: (ITS#7565) unacceptable growth on delete with back-mdb

by quanah＠zimbra.com

--On Friday, April 05, 2013 7:46 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.35 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.39.181) Fixed in current RE24. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

10 years, 8 months

1
0
0 / 0

(ITS#7568) [Patch] Minor documentation fixes

by jsynacek＠redhat.com

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 18 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) I'm attaching two patches that fix minor documentation issues in ldap.conf.5 and slaptest's usage output. http://jsynacek.fedorapeople.org/openldap/jsynacek-20130409-0001-Fix-typo... http://jsynacek.fedorapeople.org/openldap/jsynacek-20130409-0002-Add-Q-to...

10 years, 8 months

1
0
0 / 0

Re: (ITS#7566) ldapadd slower on Linux than BSD

by quanah＠zimbra.com

--On Monday, April 08, 2013 8:31 PM -0600 Leo Mocofan <lm5(a)ualberta.ca> wrote: > > > > > > > I noticed something similar on ubuntu10 as well. I upgraded my server to > ubuntu12, and I also set /proc/sys/vm/dirty_ratio to 90 and > /proc/sys/vm/dirty_expire_centisecs to 60000, and that helped > significantly > with back-mdb using current OpenLDAP master. An ldapadd of almost 3.5 > million users takes approximately 4 hours now for my dataset vs 16. so > 4x > faster. > > > > > Thank you for your suggestions. I tried these two settings and ldapadd > wrote 3 GB in 8 hours (out of 4.3 GB). How big is your database ? My DB is 5.6GB in size after load is complete. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

10 years, 8 months

1
0
0 / 0

Re: (ITS#7566) ldapadd slower on Linux than BSD

by lm5＠ualberta.ca

--bcaec548a14bc68c7904d9e4584b Content-Type: text/plain; charset=ISO-8859-1 > > I noticed something similar on ubuntu10 as well. I upgraded my server to > ubuntu12, and I also set /proc/sys/vm/dirty_ratio to 90 and > /proc/sys/vm/dirty_expire_centisecs to 60000, and that helped significantly > with back-mdb using current OpenLDAP master. An ldapadd of almost 3.5 > million users takes approximately 4 hours now for my dataset vs 16. so 4x > faster. > Thank you for your suggestions. I tried these two settings and ldapadd wrote 3 GB in 8 hours (out of 4.3 GB). How big is your database ? Have you considered running the database from a ramdisk ? Using ramfs in Linux, I got the fastest times on all the tests I tried. Leo Mocofan --bcaec548a14bc68c7904d9e4584b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"><div><div>I noticed something similar on ubuntu1= 0 as well. =A0I upgraded my server to<br> ubuntu12, and I also set /proc/sys/vm/dirty_ratio to 90 and<br> /proc/sys/vm/dirty_expire_centisecs to 60000, and that helped significantly= <br> with back-mdb using current OpenLDAP master. =A0An ldapadd of almost 3.5<br= > million users takes approximately 4 hours now for my dataset vs 16. =A0so 4= x<br> faster.<br></div></div></blockquote><div><br></div><div>Thank you for your = suggestions. I tried these two settings and ldapadd wrote 3 GB in 8 hours (= out of 4.3 GB). How big is your database ?<br><br></div><div>Have you consi= dered running the database from a ramdisk ? Using ramfs in Linux, I got the= fastest times on all the tests I tried.<br> <br></div><div>Leo Mocofan<br></div><div><br></div></div></div></div> --bcaec548a14bc68c7904d9e4584b--

10 years, 8 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2013