openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by openldap＠bromberger.com 12 Apr '11

12 Apr '11

Full_Name: Seth Version: 2.4.25 OS: Linux (Ubuntu) 2.6.35.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.13.140.242) Using Apache Directory Studio to interface with hdb-based openldap server via TLS. Moving a DN from one ou to another crashes slapd. The move (the first one if there are multiples) appears to work before slapd segfaults. An example in the logfile: Apr 12 17:17:52 ldap slapd[11278]: conn=1000 op=13 MODRDN dn="uid=someuserid,ou=Organizations,dc=example,dc=org" Apr 12 17:17:52 ldap kernel: [974579.184525] slapd[11281]: segfault at 7f0bdfab7ff8 ip 000000000049af05 sp 00007f0bdfab8000 error 6 in slapd[400000+19e000] This is 100% reproducible. Also affects 2.4.23-0ubuntu3.5 (ubuntu package) - I upgraded from source to try to work around this bug.

1 0

(ITS#6906) fix Admin guide cachesize calculations to remove refence to Hash-format
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/TimMooney-110412-04.patch Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) As I mentioned here: http://www.openldap.org/lists/openldap-technical/201104/msg00088.html and Quanah clarified here: http://www.openldap.org/lists/openldap-technical/201104/msg00123.html The admin guide chapter on tuning still mentions that indexes are in Hash format, though that's no longer true. I've uploaded patch TimMooney-110412-04.patch against HEAD that clarifies that indexes are now also in B-tree format and so the same calculations for cache on dn2id can be used with each index. I also corrected one other typo, changing To avoid thrashing the, your cache to To avoid thrashing, your cache

1 0

(ITS#6904) correct the recommended backend verbiage in slapd.backends(5)
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

I've uploaded an additional patch, TimMooney-110412-03.patch, for slapd-bdb.5/slapd-hdb.5, that switches the "recommended" status from bdb to hdb. This should likely be applied in addition to the patch mentioned in the initial report.

1 0

(ITS#6905) fix up intros to chapters 5 and 6
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/TimMooney-110412-02.patch Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) As I mentioned here http://www.openldap.org/lists/openldap-technical/201104/msg00088.html the LDAP admin guide is very good, but I think that the intros to chapters 5 (configuring slapd via slapd-config) and chapter 6 (configuring slapd via slapd.conf) needed a bit of updating. Specifically - it's not very explicit that slapd-config is now preferred and slapd.conf should only be used as a last resort. - the Note that some backends don't support slapd-config was vague enough that it would prevent many people from choosing that route, because they wouldn't know whether a backend they needed would support the new-style config system. By specifically listing which backends don't support slapd-config, hopefully more people will be willing to begin with (or convert to) slapd-config. I also tried to - make it clear that chapters 5 and 6 were essentially explaining the same thing, but the slapd-config way is preferred. - Although slapd-config stores its configuration in text files, they shouldn't be edited manually. The patch against head has been uploaded. Any and all comments and feedback welcome.

1 0

Re: (ITS#6891)
by tgates81＠gmail.com 12 Apr '11

12 Apr '11

Hi Quanah, slapd does have access to the files because it re-created after I deleted them on start. root@directory-proxy2:/var/lib/ldap# ls -la total 11752 drwxr-x--- 2 openldap openldap 4096 2011-04-12 16:01 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-04-12 16:01 alock -rw------- 1 openldap openldap 24576 2011-04-12 16:01 __db.001 -rw------- 1 openldap openldap 843776 2011-04-12 16:01 __db.002 -rw------- 1 openldap openldap 13115392 2011-04-12 16:01 __db.003 -rw------- 1 openldap openldap 2359296 2011-04-12 16:01 __db.004 -rw------- 1 openldap openldap 540672 2011-04-12 16:01 __db.005 -rw------- 1 openldap openldap 32768 2011-04-12 16:01 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-04-12 14:29 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-04-12 14:29 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-04-12 14:29 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-04-12 16:01 log.0000000001 root@directory-proxy2:/var/lib/ldap# ps aux |grep slapd openldap 5519 0.0 0.6 56244 6316 ? Ssl 16:01 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d I've disabled apparmor as well.. On Tue, Apr 12, 2011 at 3:42 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, April 12, 2011 3:04 PM -0400 Tyler Gates <tgates81(a)gmail.com> > wrote: > >> I can't get a back trace because it doesn't crash under gdb, slapd >> only responds to queries with error: >> >> client: >> result: 80 Other (e.g., implementation specific) error >> text: internal error >> server: >> bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery >> >> Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one >> (type=hdb, suffix="(null)"): bi_db_open failed! (-1) > > These all indicate permissions issues. It sounds like the slapd instance > does not have permissions to access the database. > > --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 >

1 0

Re: (ITS#6891)
by quanah＠zimbra.com 12 Apr '11

12 Apr '11

--On Tuesday, April 12, 2011 3:04 PM -0400 Tyler Gates <tgates81(a)gmail.com> wrote: > I can't get a back trace because it doesn't crash under gdb, slapd > only responds to queries with error: > > client: > result: 80 Other (e.g., implementation specific) error > text: internal error > server: > bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery > > Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one > (type=hdb, suffix="(null)"): bi_db_open failed! (-1) These all indicate permissions issues. It sounds like the slapd instance does not have permissions to access the database. --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

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 12 Apr '11

12 Apr '11

The patch that I submitted above has a memory leak due not freeing "ber" when returning error LDAP_X_CONNECTING from function ldap_send_initial_request(). I have uploaded a new version of the patch with this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode).

1 0

Re: (ITS#6891)
by tgates81＠gmail.com 12 Apr '11

12 Apr '11

I can't get a back trace because it doesn't crash under gdb, slapd only responds to queries with error: client: result: 80 Other (e.g., implementation specific) error text: internal error server: bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery This happens after every restart, even after starting with fresh database directory. I've never had to specify a suffix dn inside of the database backend to pcache before, so I'm a little confused as to why this needed. When I had started slapd fresh from after upgrading 2.4.24 (when it was working fine) to 2.4.25, I got these error messages about it not having one: Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd startup: initiated. Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup: warning, database 0 (hdb) has no suffix Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one: starting "(unknown)" Apr 12 14:25:34 directory-proxy2 slapd[2526]: hdb_db_open: need suffix. Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one (type=hdb, suffix="(null)"): bi_db_open failed! (-1) Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd shutdown: initiated Apr 12 14:25:34 directory-proxy2 slapd[2526]: ====> bdb_cache_release_all Apr 12 14:25:34 directory-proxy2 slapd[2526]: ====> bdb_cache_release_all Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd destroy: freeing system resources. Apr 12 14:25:34 directory-proxy2 slapd[2526]: slapd stopped. I have output from strace and I can provide it if needed but it is very lengthy and doesn't seem to provide any useful information. On Mon, Apr 11, 2011 at 1:43 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, April 11, 2011 3:32 PM +0000 tgates81(a)gmail.com wrote: > >> Can someone confirm whether or not this is a bug or just a >> misconfiguration error on my part? I am at a complete loss. >> > > None of what you provided as output from gdb was output from gdb. Get a > valid backtrace. > > --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 >

1 0

Re: (ITS#6903) BerkeleyDB
by quanah＠zimbra.com 12 Apr '11

12 Apr '11

--On Tuesday, April 12, 2011 9:38 AM +0000 h.b.furuseth(a)usit.uio.no wrote: > matdave(a)yahoo.com writes: >> New to openldap, downloaded latest stable version and tried to configure >> with Berkeley 11g from Oracle. >> Configure message along the lines of 'Berkeley (default) no' >> 'Berkeley not enabld/installed' > > See README, "REQUIRED SOFTWARE": > SLAPD: > BDB and HDB backends require Oracle Berkeley DB 4.4, 4.5, > 4.6, 4.7, or 4.8. It is highly recommended to apply the > patches from Oracle for a given release. > > Closing this ITS. And please use openldap-technical(a)openldap.org > for help requests. ITS is for bug reports and contributions. Probably worth reporting later versions of OpenLDAP support compiling against 5.x with no problem. 2.4.23 can be made to build against 5.x as well with the appropriate patch to configure. --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

1 0

(ITS#6904) correct the recommended backend verbiage in slapd.backends(5)
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/0001-Update-to-reflect-that-hdb-is-now-pref… Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) The slapd.backends(5) man page still indicates that the bdb backend is the recommended database, even though Quanah has confirmed that for 2.4 and later, hdb is now preferred, see http://www.openldap.org/lists/openldap-technical/201104/msg00123.html I've uploaded a patch to ftp://ftp.openldap.org/incoming against HEAD that addresses this issue, you can find it as 0001-Update-to-reflect-that-hdb-is-now-preferred-backend.patch (Sorry for the name, I'll be more careful to follow the recommended naming conventions next time). Note that I used the word "supplanted" rather than "deprecated" in the new verbiage about bdb, since deprecated seems stronger. If you would prefer the term deprecated, let me know and I can upload a new patch with that change.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs