openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#7435) telexNumber
by Roy.Luckow＠swmh.de 08 Nov '12

08 Nov '12

Full_Name: Roy Luckow Version: 2.4.30 OS: Win Server 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.4.225.4) LDAP Search for attribute "telexNumber" doesn't work. If I do a search filter "(telexNumber=*)" --> Then I get my results (total of 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the Message "No entries matched"

1 0

Re: (ITS#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 08 Nov '12

08 Nov '12

--On Friday, November 09, 2012 2:10 AM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 09, 2012 1:55 AM +0000 blance3459(a)hotmail.com wrote: > >> Full_Name: Barry Lance >> Version: 2.4.28 >> OS: Ubuntu 12.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (70.226.37.226) >> > > Hi Barry, Hi Barry, Are you sure you aren't hitting: Fixed slapd-ldap idassert bind handling (ITS#7403) Fixed in OpenLDAP 2.4.33? --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#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 08 Nov '12

08 Nov '12

--On Friday, November 09, 2012 1:55 AM +0000 blance3459(a)hotmail.com wrote: > Full_Name: Barry Lance > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (70.226.37.226) > Hi Barry, Thanks for the report. I would note that OpenLDAP 2.4.28 is 5 releases old at this point. I don't see anything specific in the CHANGES file between 2.4.28 and 2.4.33 for this issue, but it may be fixed and not logged in there. Confirming that the behavior persists with 2.4.33 would be helpful. Also, don't confuse encoding with encryption. ;) It is standard in LDIF for data to be base64 encoded if the attribute value requires it based on the characters in the data. You can use various tools to decode the attribute value back out. Regards, 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#7434) idassert-bind fails after restarting slapd
by blance3459＠hotmail.com 08 Nov '12

08 Nov '12

Full_Name: Barry Lance Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.226.37.226) Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running slap 2.4.28 and ubuntu 12.04. Replica is a replication partner of Master using syncrepl. Replication is working fine. When I attempt to add a chain overlay to Replica to send all writes over to the master, it works exactly as expected allowing both normal users and the rootdn to make appropriate changes. However, once I either reboot the replica server or restart slapd, the chain overlay fails to allow any changes on the master. Looking at syslog shows that before the reboot/restart the requesting users' dn is proxied over as expected. After the restarting slapd or rebooting Replica, all changes are proxied anonymously (dn=""). I am using simple binds at this point in the project, but it doesn't seems to matter if I proxy in the clear, ldaps, or TLS the result is the same. All three methods can successfully negotiate a connection. I've even tried switching between using the rootdn and a different user as the binddn in my overlay, but the result is still the same no matter what I use for the binddn. When I look at my config, I notice that "chain-idassert-bind" appears to be hashed or encrypted in thew config. Is that normal? Just seems really odd that my config would work immediately when added, but fail after the the daemon has been restarted. Am I missing something really silly? Hopefully, someone can assist me on this. I've been driving myself crazy trying to figure out why this behavior is occurring. Disclaimer: I am using openldap as part of my capstone project for graduation. I'm not asking for anyone to do my "homework" for me, I'm just stuck on this one issue that I would love to resolve so I can move on to the Kerberos phase of my project (and maybe even study for an exam coming up in my algorithms class next week). Here is my overlay config using the rootDN and TLS (on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self starttls=critical tls_cacert=/etc/ssl/certs/cacert.pem tls_reqcert=demand And without TLS (also on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 08 Nov '12

08 Nov '12

Jan Synacek wrote: > On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: >> FYI: I sent output of bt full to Jan with some data stripped because of >> privacy concerns. >> >> Note that the entry for which constraint checking is done is added to the >> database. So something might be wrong *after* the check. > > Can you please try the attached patch? It seems to work. But I will test it during the next days more thoroughly. Ciao, Michael.

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by jsynacek＠redhat.com 08 Nov '12

08 Nov '12

This is a multi-part message in MIME format. --------------000604070905040801090708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: > FYI: I sent output of bt full to Jan with some data stripped because of > privacy concerns. > > Note that the entry for which constraint checking is done is added to the > database. So something might be wrong *after* the check. > > Ciao, Michael. > > Can you please try the attached patch? If it doesn't fix the issue (or breaks something else that I'm not aware of) I will need a reproducer config and data. Thank you, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat --------------000604070905040801090708 Content-Type: text/x-patch; name="tmp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tmp.patch" diff --git a/servers/slapd/overlays/constraint.c b/servers/slapd/overlays/constraint.c index ee8911b..f2c645c 100644 --- a/servers/slapd/overlays/constraint.c +++ b/servers/slapd/overlays/constraint.c @@ -935,10 +935,6 @@ constraint_update( Operation *op, SlapReply *rs ) /* Do we need to count attributes? */ for(cp = c; cp; cp = cp->ap_next) { - if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { - continue; - } - if (cp->count != 0) { if (rc != 0 || target_entry == NULL) { Debug(LDAP_DEBUG_TRACE, @@ -950,6 +946,10 @@ constraint_update( Operation *op, SlapReply *rs ) goto mod_violation; } + if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { + continue; + } + is_v = constraint_check_count_violation(m, target_entry, cp); Debug(LDAP_DEBUG_TRACE, --------------000604070905040801090708--

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 07 Nov '12

07 Nov '12

FYI: I sent output of bt full to Jan with some data stripped because of privacy concerns. Note that the entry for which constraint checking is done is added to the database. So something might be wrong *after* the check. Ciao, Michael.

1 0

Re: (ITS#7433) OpenLDAP 2.4.32 - possible memory leak at high load
by quanah＠zimbra.com 06 Nov '12

06 Nov '12

--On Tuesday, November 06, 2012 5:36 PM +0000 vb4607(a)att.com wrote: > Full_Name: Venkatesh Baglodi > Version: 2.4.32 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (139.76.64.65) > > > We have been facing frequent memory utilization issues with OpenLDAP > 2.4.32 in our production environment (multi-master mode, 6 servers), > which requires OpenLDAP server instances to be restarted almost every > week. Utilization starts at a lower percentage to start with (2-3%), but > then gradually moves up and never comes down. We have been using OpenLDAP > 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux > Server release 5.5 (Tikanga). Are there any known issues with this > version? Are you using the default glibc malloc, instead of tcmalloc? That would be a common mistake that results in this sort of behavior. --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#7433) OpenLDAP 2.4.32 - possible memory leak at high load
by vb4607＠att.com 06 Nov '12

06 Nov '12

Full_Name: Venkatesh Baglodi Version: 2.4.32 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.76.64.65) We have been facing frequent memory utilization issues with OpenLDAP 2.4.32 in our production environment (multi-master mode, 6 servers), which requires OpenLDAP server instances to be restarted almost every week. Utilization starts at a lower percentage to start with (2-3%), but then gradually moves up and never comes down. We have been using OpenLDAP 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). Are there any known issues with this version?

1 0

Re: (ITS#7432) slapd crashes when removing members from a large group
by hyc＠symas.com 05 Nov '12

05 Nov '12

marvin.mundry(a)uni-hamburg.de wrote: > Full_Name: Marvin Mundry > Version: 2.4.33 > OS: Ubuntu 12.10 > URL: https://idmswiki.rrz.uni-hamburg.de:8005/debug.tar.bz > Submission from: (NULL) (134.100.2.183) > Thanks for the report. The crash has been fixed in git, but your test runs into another (known) issue in MDB. You're working with a very large entry, which libmdb stores in overflow pages. In the current version of libmdb, freespace management for overflow pages is not fully implemented, so every time you update the entry libmdb will always use new pages (instead of reusing old pages). Thus, after a few hundred operations, your 1GB map will be exhausted. It looks like you won't be able to use back-mdb until this feature is fully implemented in libmdb. > i have slapcat'ed my production environment and slapadded it into an back_mdb > database. > > when deleting members one by one from a large group (48428 Members), after some > transactions slapd crashes. > when i slapadd my dit to an mdb without having an eq index configured for > "member" the removal of members works fine. > > when doing the same thing (member indexed, slapadding members, starting slapd, > removing group members one by one) on a hdb, slapd does not crash. > > sortvals is set for members as otherwise deletion operations would take a very > long time > > i failed to reproduce the problem without initially slapadding the data from my > production environment into the mdb. > > i have removed all configuration settings not neccessary to reproduce the bug > > the debug.tar.bz should contain everything that is neccessary (including a > description) to reproduce the problem. additionally the file contains a coredump > and the full trace output > > slapd.conf: > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/rfc2307bis.schema > pidfile /usr/local/var/run/slapd.pid > argsfile /usr/local/var/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_mdb.la > sortvals member > database mdb > suffix "dc=test,dc=com" > rootdn "cn=admin,dc=test,dc=com" > rootpw secret > directory /usr/local/etc/openldap/test123db/AL > index member eq > maxsize 1000000000 > > > last lines of slapd -d Trace: > 5096b5ae oc_check_allowed type "modifyTimestamp" > 5096b5ae sl_malloc 8: ch_malloc #this line repeats 28450 times > 5096b5ae => mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com > 5096b5ae <= mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com > > build options: > CFLAGS=-O0 -d > ./configure --enable-dynamic=yes --enable-syslog=yes --enable-slapd=yes > --enable-dynacl=yes --enable-crypt=yes --enable-modules=yes --enable-rewrite=ye > s --enable-bdb=mod --enable-hdb=mod --enable-ldap=mod --enable-mdb=mod > --enable-meta=mod --enable-monitor=mod --enable-overlays=mod --with-tls=openssl > > --enable-debug > > (gdb) bt: > #0 0x000002fc000002fa in ?? () > #1 0x000002ff000002fd in ?? () > #2 0x0000030200000300 in ?? () > #3 0x0000030500000303 in ?? () > #4 0x0000030800000306 in ?? () > #5 0x0000030b00000309 in ?? () > #6 0x00007f1400000312 in ?? () > #7 0x0000009cffffffbf in ?? () > #8 0x00007f1400000011 in ?? () > #9 0x00000000000102a3 in ?? () > #10 0x00007f140c101880 in ?? () > #11 0x00007f140883c200 in ?? () > #12 0x0000000000000891 in ?? () > #13 0x00007f14155ef060 in ?? () > #14 0x00007f14523dd5a6 in ?? () > #15 0x00007f1451fa1010 in ?? () > #16 0x00000000523dd2a7 in ?? () > #17 0x00007f14155ef390 in ?? () > #18 0x0000000000000000 in ?? () > > -- -- 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

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