openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#5713) Documentation: olcDbMode incorrect at http://www.openldap.org/doc/admin24/slapdconf2.html
by rtdean＠cytherianage.net 26 Sep '08

26 Sep '08

Full_Name: Ryan T. Dean Version: 2.4.11 OS: FreeBSD 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.124.245.244) The documentation present at http://www.openldap.org/doc/admin24/slapdconf2.html provides an incorrect example for the olcDbMode attribute. The documentation reads: >>> 5.2.6.9. olcDbMode: <integer> This directive specifies the file protection mode that newly created database index files should have. Default: olcDbMode: 0600 <<< However, olcDbMode takes an integer, and slapd will reject a value of 0600. It will accept a value of 600, however, this results in octal permissions 1130, which is -not- what you want. Instead, providing olcDbMode with a value of 384 will result in an octal permission of 0600, which is, I believe, what the documentation is attempting to state.

1 0

Re: ITS#5707 [Fwd: Re: 4.7.25 deadlock]
by quanah＠zimbra.com 26 Sep '08

26 Sep '08

Seriously, what kind of crap is that? They've got a serious flaw in their software, but don't intend to publish the patch? sheesh. --Quanah --On September 26, 2008 6:27:45 AM +0000 hyc(a)symas.com wrote: > So I guess we have to warn people about this one ourselves for a while. > > -------- Original Message -------- > Subject: Re: 4.7.25 deadlock > Date: Thu, 25 Sep 2008 23:15:31 -0700 > From: Michael Ubell <@oracle.com> > To: Howard Chu <hyc(a)symas.com> > > Howard, > > Generally we only post critical patches (data corruption, etc) to the > web site. Since this one only effects those using user defined locks > and does no damage, I don't think it will be posted. > > Mike > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5712) Could not set the connection timeout
by essiambl＠gmail.com 26 Sep '08

26 Sep '08

Full_Name: Luc-André Essiambre Version: 2.4.11 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.95.235.3) I'm using openldap to authenticate users for our subversion repositories hosted on apache httpd. Immediately after a server startup, I get these strange errors saying "LDAP: Could not set the connection timeout" when I try to authenticate myself. The weird thing is, after a couple of attempts at accessing the subversion content (5 or 6 times), I'm eventually authenticated without error. Then it will work for a while, then those same errors will come back. openldap was compiled using the gcc compiler included in solaris (version 3.4.3) without slapd, with cyrus-sasl-2.1.21. Solaris runs as a virtual server on sparc hardware.

1 0

Re: (ITS#5711) Password Modify Exop don't return ppolicy control in case of error
by ando＠sys-net.it 26 Sep '08

26 Sep '08

ando(a)sys-net.it wrote: > Guillaume.Rousse(a)inria.fr wrote: > >> When Password Modify ExOp fails, due to ppolicy restrictions, it doesn't return >> any ppolicy control. > > Right: the control is created and attached to SlapReply, but the > callback is slap_cb_null(), and the control is removed from SlapReply > and destroyed before ppolicy_modify() returns. This is because extended > ops do not directly send response, but rather delegate it to the > frontend. I don't see an easy solution, other than taking response into > the exop handlers. An alternative approach would be to use a specific callback response other that slap_cb_null() within passwd_extop() that duplicates and brings back any controls set within the internal modify, so that they can be placed in the SlapReply that is bassed back to send_ldap_extended(). Or, sr_ctrls could become "MUSTBEFREED" much like other SlapReply fields... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5707 [Fwd: Re: 4.7.25 deadlock]
by michael＠stroeder.com 26 Sep '08

26 Sep '08

Sigh! I find their release versioning and patch publication somewhat hard to follow anyway. So the best advice to users is to simply avoid 4.7.25 at this time. Ciao, Michael. hyc(a)symas.com wrote: > So I guess we have to warn people about this one ourselves for a while. > > -------- Original Message -------- > Subject: Re: 4.7.25 deadlock > Date: Thu, 25 Sep 2008 23:15:31 -0700 > From: Michael Ubell <@oracle.com> > To: Howard Chu <hyc(a)symas.com> > > Howard, > > Generally we only post critical patches (data corruption, etc) to the > web site. Since this one only effects those using user defined locks > and does no damage, I don't think it will be posted. > > Mike > >

1 0

ITS#5707 [Fwd: Re: 4.7.25 deadlock]
by hyc＠symas.com 25 Sep '08

25 Sep '08

So I guess we have to warn people about this one ourselves for a while. -------- Original Message -------- Subject: Re: 4.7.25 deadlock Date: Thu, 25 Sep 2008 23:15:31 -0700 From: Michael Ubell <@oracle.com> To: Howard Chu <hyc(a)symas.com> Howard, Generally we only post critical patches (data corruption, etc) to the web site. Since this one only effects those using user defined locks and does no damage, I don't think it will be posted. Mike -- -- 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

ITS#5707 [Fwd: Re: 4.7.25 deadlock]
by hyc＠symas.com 25 Sep '08

25 Sep '08

This is a multi-part message in MIME format. --------------020600040008080504030403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A patch from Oracle... -------- Original Message -------- Subject: Re: 4.7.25 deadlock Date: Thu, 25 Sep 2008 21:48:20 -0700 From: Howard Chu <hyc(a)symas.com> To: Michael Ubell <@oracle.com> References: <54E45A7F-A1BF-4FE1-A9F3-1DA7F320B81C(a)oracle.com> Michael Ubell wrote: > Howard, > > You are the second one to report this problem with user defined locks > when there is a single lock partition. You can work around this on a > single cpu system by just setting the number of lock partitions to be > greater than 1. This might have a slight performance impact. Or you > can apply the attached patch. Thanks. That patch looks a lot like what I was using here... ;) Will this be posted on the oracle web site soon? And yes, the workaround works ok in the interim. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------020600040008080504030403 Content-Type: application/octet-stream; name="patch.16415" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch.16415" SW5kZXg6IGxvY2svbG9jay5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9hL0NWU1JPT1Qv ZGIvbG9jay9sb2NrLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEyLjYxCmRpZmYgLWMgLXIx Mi42MSBsb2NrLmMKKioqIGxvY2svbG9jay5jCTIyIEp1bCAyMDA4IDEyOjA4OjUzIC0wMDAw CTEyLjYxCi0tLSBsb2NrL2xvY2suYwkxOSBBdWcgMjAwOCAxNzoyODoyNCAtMDAwMAoqKioq KioqKioqKioqKioKKioqIDEyNzgsMTI4NyAqKioqCiAgCQlTSF9UQUlMUV9SRU1PVkUoCiAg CQkgICAgJmx0LT5vYmpfdGFiW29ial9uZHhdLCBzaF9vYmosIGxpbmtzLCBfX2RiX2xvY2tv YmopOwogIAkJaWYgKHNoX29iai0+bG9ja29iai5zaXplID4gc2l6ZW9mKHNoX29iai0+b2Jq ZGF0YSkpIHsKISAJCQlMT0NLX1JFR0lPTl9MT0NLKGVudik7CiAgCQkJX19lbnZfYWxsb2Nf ZnJlZSgmbHQtPnJlZ2luZm8sCiAgCQkJICAgIFNIX0RCVF9QVFIoJnNoX29iai0+bG9ja29i aikpOwohIAkJCUxPQ0tfUkVHSU9OX1VOTE9DSyhlbnYpOwogIAkJfQogIAkJU0hfVEFJTFFf SU5TRVJUX0hFQUQoCiAgCQkgICAgJkZSRUVfT0JKUyhsdCwgcGFydF9pZCksIHNoX29iaiwg bGlua3MsIF9fZGJfbG9ja29iaik7Ci0tLSAxMjc4LDEyODkgLS0tLQogIAkJU0hfVEFJTFFf UkVNT1ZFKAogIAkJICAgICZsdC0+b2JqX3RhYltvYmpfbmR4XSwgc2hfb2JqLCBsaW5rcywg X19kYl9sb2Nrb2JqKTsKICAJCWlmIChzaF9vYmotPmxvY2tvYmouc2l6ZSA+IHNpemVvZihz aF9vYmotPm9iamRhdGEpKSB7CiEgCQkJaWYgKHJlZ2lvbi0+cGFydF90X3NpemUgIT0gMSkK ISAJCQkJTE9DS19SRUdJT05fTE9DSyhlbnYpOwogIAkJCV9fZW52X2FsbG9jX2ZyZWUoJmx0 LT5yZWdpbmZvLAogIAkJCSAgICBTSF9EQlRfUFRSKCZzaF9vYmotPmxvY2tvYmopKTsKISAJ CQlpZiAocmVnaW9uLT5wYXJ0X3Rfc2l6ZSAhPSAxKQohIAkJCQlMT0NLX1JFR0lPTl9VTkxP Q0soZW52KTsKICAJCX0KICAJCVNIX1RBSUxRX0lOU0VSVF9IRUFEKAogIAkJICAgICZGUkVF X09CSlMobHQsIHBhcnRfaWQpLCBzaF9vYmosIGxpbmtzLCBfX2RiX2xvY2tvYmopOwoqKioq KioqKioqKioqKioKKioqIDE0NzAsMTQ4NCAqKioqCiAgCQlpZiAob2JqLT5zaXplIDw9IHNp emVvZihzaF9vYmotPm9iamRhdGEpKQogIAkJCXAgPSBzaF9vYmotPm9iamRhdGE7CiAgCQll bHNlIHsKISAJCQlMT0NLX1JFR0lPTl9MT0NLKGVudik7CiAgCQkJaWYgKChyZXQgPQogIAkJ CSAgICBfX2Vudl9hbGxvYygmbHQtPnJlZ2luZm8sIG9iai0+c2l6ZSwgJnApKSAhPSAwKSB7 CiAgCQkJCV9fZGJfZXJyeChlbnYsCiAgCQkJCSAgICAiTm8gc3BhY2UgZm9yIGxvY2sgb2Jq ZWN0IHN0b3JhZ2UiKTsKISAJCQkJTE9DS19SRUdJT05fVU5MT0NLKGVudik7CiAgCQkJCWdv dG8gZXJyOwogIAkJCX0KISAJCQlMT0NLX1JFR0lPTl9VTkxPQ0soZW52KTsKICAJCX0KICAK ICAJCW1lbWNweShwLCBvYmotPmRhdGEsIG9iai0+c2l6ZSk7Ci0tLSAxNDcyLDE0OTIgLS0t LQogIAkJaWYgKG9iai0+c2l6ZSA8PSBzaXplb2Yoc2hfb2JqLT5vYmpkYXRhKSkKICAJCQlw ID0gc2hfb2JqLT5vYmpkYXRhOwogIAkJZWxzZSB7CiEgCQkJLyoKISAJCQkgKiBJZiB3ZSBo YXZlIG9ubHkgb25lIHBhcnRpdGlvbiwgdGhlIHJlZ2lvbiBpcyBsb2NrZWQuCiEgCQkJICov CiEgCQkJaWYgKHJlZ2lvbi0+cGFydF90X3NpemUgIT0gMSkKISAJCQkJTE9DS19SRUdJT05f TE9DSyhlbnYpOwogIAkJCWlmICgocmV0ID0KICAJCQkgICAgX19lbnZfYWxsb2MoJmx0LT5y ZWdpbmZvLCBvYmotPnNpemUsICZwKSkgIT0gMCkgewogIAkJCQlfX2RiX2VycngoZW52LAog IAkJCQkgICAgIk5vIHNwYWNlIGZvciBsb2NrIG9iamVjdCBzdG9yYWdlIik7CiEgCQkJCWlm IChyZWdpb24tPnBhcnRfdF9zaXplICE9IDEpCiEgCQkJCQlMT0NLX1JFR0lPTl9VTkxPQ0so ZW52KTsKICAJCQkJZ290byBlcnI7CiAgCQkJfQohIAkJCWlmIChyZWdpb24tPnBhcnRfdF9z aXplICE9IDEpCiEgCQkJCUxPQ0tfUkVHSU9OX1VOTE9DSyhlbnYpOwogIAkJfQogIAogIAkJ bWVtY3B5KHAsIG9iai0+ZGF0YSwgb2JqLT5zaXplKTsK --------------020600040008080504030403--

1 0

Re: (ITS#5711) Password Modify Exop don't return ppolicy control in case of error
by ando＠sys-net.it 25 Sep '08

25 Sep '08

Guillaume.Rousse(a)inria.fr wrote: > When Password Modify ExOp fails, due to ppolicy restrictions, it doesn't return > any ppolicy control. Right: the control is created and attached to SlapReply, but the callback is slap_cb_null(), and the control is removed from SlapReply and destroyed before ppolicy_modify() returns. This is because extended ops do not directly send response, but rather delegate it to the frontend. I don't see an easy solution, other than taking response into the exop handlers. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5711) Password Modify Exop don't return ppolicy control in case of error
by Guillaume.Rousse＠inria.fr 25 Sep '08

25 Sep '08

Full_Name: Guillaume Rousse Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) When Password Modify ExOp fails, due to ppolicy restrictions, it doesn't return any ppolicy control. The following test case is enough to demonstrate it with any policy defining minimum password length to 2: #!/usr/bin/perl use Net::LDAP; use Net::LDAP::Extension::SetPassword; use Net::LDAP::Control::PasswordPolicy; use Data::Dumper; my $ldap = Net::LDAP->new('ldap.domain.com') or die "impossible to connect: $@"; my $result = $ldap->bind('cn=foo,dc=domain,dc=com', password => 'bar'); die 'impossible to bind: ' . $result->error() if $result->code(); my $pp = Net::LDAP::Control::PasswordPolicy->new(); $result = $ldap->set_password( newpasswd => 'a', control => [ $pp ] ); my $control = $result->control(LDAP_CONTROL_PASSWORDPOLICY); print Dumper($control);

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by quanah＠zimbra.com 24 Sep '08

24 Sep '08

--On September 23, 2008 8:32:20 PM +0000 mgwin(a)escp-eap.net wrote: > On Tue, 23 Sep 2008 15:33:47 +0200 > Michael Str??der <michael(a)stroeder.com> wrote: > >> Which version 2.3? It is definitely more stable than slurpd in recent >> versions of 2.3 (2.3.43 is most recent release). > > 2.3.30, the debian etch package - unfortunately upgrading isn't really > an option here. Even the Debian package maintainers recommend people not use the Debian version for production services. See <http://www.openldap.org/faq/data/cache/1456.html>. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, 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