openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#7436) slapo-deref not working
by ralf＠OpenLDAP.org 09 Nov '12

09 Nov '12

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: SLES11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.118.144.197) Submitted by: ralf Independ of whether the slapo-deref beign configured or not it always returns "Critical extension is unavailable" to the client. This is because it doesn't call overlay_register_control anywhere in its code. Fix is underway.

1 0

Re: (ITS#7435) telexNumber
by masarati＠aero.polimi.it 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" This is by design: "telexNumber" has no matching rule. This ITS will be closed. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(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

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