- openldap-bugs - openldap.org

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

27 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 26 Sep '08

26 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 26 Sep '08

26 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 25 Sep '08

25 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

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 24 Sep '08

24 Sep '08

------=_Part_8723_3706532.1222271104834 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline May be this helps to better localize the origin of the problem : After adding log messages in the different functions of the file syncprov.c I find that for an object replicated successfully the following functions are called in order : syncprov_op_mod() syncprov_op_response() syncprov_matchops() syncprov_qresp() syncprov_qstart() syncprov_qtask() syncprov_qplay() syncprov_sendresp() But in the for an object skipped by the sync provider only the first two functions are called (no call is made to syncprov_matchops() etc. Best Regards Sylvain Thomas ------=_Part_8723_3706532.1222271104834 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div dir="ltr"> May be this helps to better localize the origin of the problem : After adding log messages in the different functions of the file syncprov.c I find that for an object replicated successfully the following functions are called in order : syncprov_op_mod() syncprov_op_response() syncprov_matchops() syncprov_qresp() syncprov_qstart() syncprov_qtask() syncprov_qplay() syncprov_sendresp() But in the for an object skipped by the sync provider only the first two functions are called (no call is made to syncprov_matchops() etc. Best Regards Sylvain Thomas </div> ------=_Part_8723_3706532.1222271104834--

1 0

Re: ITS#5581 reopened
by stef＠memberwebs.com 24 Sep '08

24 Sep '08

Sorry for the delay. Yes I can confirm this has been fixed. Thanks for your attention to this problem. Pierangelo Masarati wrote: > I have re-opened this bug. I have a fix, will commit ASAP. I confirm the bug only seems to affect malformed filters in the URI. > > 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#5710) syncrepl event loss with ppolicy and multiple masters
by mbackes＠symas.com 24 Sep '08

24 Sep '08

Full_Name: Matthew Backes Version: 2.4, head OS: all URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.88.99.93) When using multiple masters replicating from each other with ppolicy enabled, bind failure events fail to propagate the pwdFailureTime changes. The pwdFailureTime's appear on the directory receiving the change and contextCSN updates, but the replica-side disregards the event. In syncprov.c:1646: /* Don't do any processing for consumer contextCSN updates */ if ( SLAP_SYNC_SHADOW( op->o_bd ) && op->o_msgid == SLAP_SYNC_UPDATE_MSGID ) { ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock ); return SLAP_CB_CONTINUE; } This seems to be designed so that when the local side applies remote changes, the resulting contextCSN update does not get sent back out to any persistent searchers. Unfortuantely, this path is also taken for the pwdFailureTime as a result of a bad (or good) BIND op on a new connection. This means the change is applied to the directory receving the BIND, but replicas of it in multi-master situations discard the change. This definitely seems to be the MSGID issue because if the BIND is not the first thing being done, then the pwdFailureTime messages propagate correctly; e.g. if using STARTTLS and then BIND, no replication problem exists. So... any consensus on the right way to do this test? We could start looking specifically for changes to contextCSN, but that's sort of ugly. A generic don't-replicate-this flag seems like a better approach but looks somewhat invasive. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

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

23 Sep '08

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 According to CHANGES 2.3.30 was released almost two years ago. There have been so many fixes since then. You shouldn't ignore that fact if OpenLDAP is a critical part of your infrastructure. > unfortunately upgrading isn't really an option here. Why? > I experienced segfaults on the provider server. Although I'm not > entirely sure the provider was initialised properly*, the fact that > slapd would crash seemed a sufficient indication we should bide our time > and wait till 2.4 hit debian stable. You should upgrade to either 2.3.43 or 2.4.11. Whatever Debian thinks of being a stable version isn't necessarily what the upstream developers think is stable. Actually we have this discussion quite often. Ciao, Michael.

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by mgwin＠escp-eap.net 23 Sep '08

23 Sep '08

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. I experienced segfaults on the provider server. Although I'm not entirely sure the provider was initialised properly*, the fact that slapd would crash seemed a sufficient indication we should bide our time and wait till 2.4 hit debian stable. - Michael *The 2.3 admin guide states: The provider slapd (8) is not required to be restarted. contextCSN is automatically generated as needed: it might be originally contained in the LDIF file, generated by slapadd (8), generated upon changes in the context, or generated when the first LDAP Sync search arrives at the provider. If an LDIF file is being loaded which did not previously contain the contextCSN, the -w option should be used with slapadd (8) to cause it to be generated. This will allow the server to startup a little quicker the first time it runs. This doesn't seem very clear to me - should I re-import the database with the -w option, or should adding the overlay and syncprov-* directives to slapd.conf and restarting be sufficient?

1 0

(ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 23 Sep '08

23 Sep '08

Full_Name: Sylvain Thomas Version: 2.4.11 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.3) I have a test platform with one master and one simple replica. I perform rapid write operations on the master through 8 parallel connections, and I find that some objects are missing in the replica. More investigation shows that the sync provider skips the objects if they are processed faster than the preceding ones. Below, I produce a sample log (sync + stats) of the problem. In the sample log the object uid=5030708029E1 is not sent to the replica (no call to syncprov_sendresp() ) but the object uid=50307080309A is sent. ..... Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=331 op=1 ADD dn="uid=50307080309A,ou=A,ou=9,ou=abonnes,ou=test,c=fr" Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_queue_csn: queing 0xa2f6cac0 20080923080903.375249Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=333 op=1 ADD dn="uid=5030708029E1,ou=1,ou=E,ou=abonnes,ou=test,c=fr" Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_queue_csn: queing 0xa14feac0 20080923080903.376369Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=332 op=1 RESULT tag=105 err=0 text= Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_graduate_commit_csn: removing 0x9179420 20080923080903.373805Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: syncprov_sendresp: cookie=rid=003,csn=20080923080903.373805Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=333 op=1 RESULT tag=105 err=0 text= Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_graduate_commit_csn: removing 0x917b428 20080923080903.376369Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=331 op=1 RESULT tag=105 err=0 text= Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_graduate_commit_csn: removing 0xa242aa38 20080923080903.375249Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: syncprov_sendresp: cookie=rid=003,csn=20080923080903.375249Z#000000#001#000000 ...... I think the reason is that the ADD request for uid=5030708029E1 is received after that of uid=50307080309A, so it takes a bigger csn (20080923080903.376369Z#000000#001#000000) but its processing takes less time (slap_graduate_commit_csn() comes first). I can provide a detailed log (loglevel -1) and any other information required. The environment and the configuration files are the same as for ITS 5661, but I do not use the mirror mode. Thanks for your help Best Regards Sylvain Thomas

1 0

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

23 Sep '08

Michael Gwin wrote: > On Fri, 05 Sep 2008 16:21:36 +0200 > Michael Ströder <michael(a)stroeder.com> wrote: > >> That's pretty much the reason why syncrepl was invented/implemented in >> OpenLDAP 2.2 and slurpd is deprecated and abandoned from 2.4. >> >> http://www.openldap.org/doc/admin24/replication.html >> >> Likely everybody here will simply recommend to migrate to syncrepl. > > Thanks for the suggestion. I agree with the design and goals of > syncrepl, and will indeed migrate in the future. However, having tried > it, it didn't seem production-worthy in openldap 2.3. Which version 2.3? It is definitely more stable than slurpd in recent versions of 2.3 (2.3.43 is most recent release). Ciao, Michael.

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by mgwin＠escp-eap.net 23 Sep '08

23 Sep '08

On Fri, 05 Sep 2008 16:21:36 +0200 Michael Ströder <michael(a)stroeder.com> wrote: > That's pretty much the reason why syncrepl was invented/implemented in > OpenLDAP 2.2 and slurpd is deprecated and abandoned from 2.4. > > http://www.openldap.org/doc/admin24/replication.html > > Likely everybody here will simply recommend to migrate to syncrepl. Thanks for the suggestion. I agree with the design and goals of syncrepl, and will indeed migrate in the future. However, having tried it, it didn't seem production-worthy in openldap 2.3. Just in case it can help anyone, I solved my problem by removing the attribute filtering from my replica. No blank lines since. Regards, Michael

1 0

(ITS#5708) nss-ldap not responding properly
by harpreet＠deeproot.co.in 23 Sep '08

23 Sep '08

Full_Name: Harpreet Singh Wadhwa Version: 2.4.11 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.95.198.26) Hi to all, I don't know if this has been posted earlier as I was not able to find it in the list. The issue is I have openldap working with PAM and NSS to do the authentication stuff for courier services. But at times users are unable to log into their accounts, restarting NSCD and SLAPD solves the problem but that too for a short time. These are some details and errors which I have. ##libnss-ldap.conf host 127.0.0.1 base dc=com ldap_version 3 binddn uid=example,dc=com bindpw secret bind_policy soft ##nsswitch.conf passwd: compat ldap group: compat ldap shadow: compat ldap hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis And the errors which I get are --> user.info: Sep 18 11:24:35 nscd: nss_ldap: reconnecting to LDAP server... user.err: Sep 18 11:24:35 nscd: nss_ldap: could not connect to any LDAP server as uid=example,dc=com - Can't contact LDAP server And some time I get --> local4.debug: Sep 23 11:21:40 slapd[8880]: conn=224 fd=20 closed (connection lost) or local4.debug: Sep 23 11:15:21 slapd[8880]: connection_read(20): no connection! Please respond to me. Regards.

1 0

Re: (ITS#5707) HEAD/RE24 and BDB 4.7.25p1 hanging
by hyc＠symas.com 23 Sep '08

23 Sep '08

hyc(a)symas.com wrote: > I was unable to reproduce the problem on my multi-core machines, but I do see > it on a single-core machine. I've sent a backtrace and other debug info to the > Oracle folks, will see what they have to say. I see the problem; it's a bug in BDB's multi-partition lock manager. When using multiple lock table partitions, it obtains a lock on the system-wide lock mutex and a lock on the per-region mutex. On a single core system it defaults to a single lock table. In this case, the macro that obtains the system-wide lock behaves identically to the per-region lock. I.e., both attempt to acquire the exact same mutex. Since it's already held, the process deadlocks. (gdb) bt #0 0xb7f37424 in __kernel_vsyscall () #1 0xb7b36c4e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xb7b32a3c in _L_mutex_lock_88 () from /lib/libpthread.so.0 #3 0xb7b3242d in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0xb7d00819 in __db_pthread_mutex_lock (env=0x8a84550, mutex=104) at ../dist/../mutex/mut_pthread.c:207 #5 0xb7daad19 in __lock_getobj (lt=0x8a84848, obj=0xbfd492ec, ndx=492, create=1, retp=0xbfd491e4) at ../dist/../lock/lock.c:1470 #6 0xb7da7f53 in __lock_get_internal (lt=0x8a84848, sh_locker=0xb776d508, flags=1, obj=0xbfd492ec, lock_mode=DB_LOCK_READ, timeout=0, lock=0xbfd493cc) at ../dist/../lock/lock.c:588 #7 0xb7da77d6 in __lock_get_api (env=0x8a84550, locker=2147483659, flags=1, obj=0xbfd492ec, lock_mode=DB_LOCK_READ, lock=0xbfd493cc) at ../dist/../lock/lock.c:423 #8 0xb7da765b in __lock_get_pp (dbenv=0x8a841c0, locker=2147483659, flags=1, obj=0xbfd492ec, lock_mode=DB_LOCK_READ, lock=0xbfd493cc) at ../dist/../lock/lock.c:395 #9 0x08124fb8 in bdb_dn2id_lock (bdb=0x8a68620, dn=0xbfd493f0, rw=0, txn=0x8a890b8, lock=0xbfd493cc) at ../../../../head/servers/slapd/back-bdb/dn2id.c:47 #10 0x08125d7d in bdb_dn2id (op=0xbfd49640, dn=0xbfd493f0, ei=0xbfd493e0, txn=0x8a890b8, lock=0xbfd493cc) at ../../../../head/servers/slapd/back-bdb/dn2id.c:307 ---Type <return> to continue, or q <return> to quit---q Quit (gdb) frame 4 #4 0xb7d00819 in __db_pthread_mutex_lock (env=0x8a84550, mutex=104) at ../dist/../mutex/mut_pthread.c:207 207 RET_SET((pthread_mutex_lock(&mutexp->mutex)), ret); (gdb) p *mutexp $1 = {mutex = {__data = {__lock = 2, __count = 0, __owner = 29470, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\002\000\000\000\000\000\000\000\036s\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 2}, cond = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, pid = 29470, tid = 3080046272, mutex_next_link = 0, alloc_id = 6, mutex_set_wait = 1, mutex_set_nowait = 129, flags = 3} (gdb) The mutex being acquired in frame 4 is the same one that was already acquired in frame 7, __lock_get_api line 418. -- -- 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

Re: (ITS#5707) HEAD/RE24 and BDB 4.7.25p1 hanging
by hyc＠symas.com 23 Sep '08

23 Sep '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD/RE24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.97.30) > > > I'm trying to run current RE24 and HEAD with BDB 4.7.25p1. It hangs in test-001 > and it hangs in a LDAP conn (probably when doing a bind). Is that combination > really > stable? > > It works with very same build scripts/configuration with 4.6.21+patches. > > Further information (bt full, log, BDB build script) is in this archived mailing > list posting: > > http://www.openldap.org/lists/openldap-devel/200809/msg00075.html I was unable to reproduce the problem on my multi-core machines, but I do see it on a single-core machine. I've sent a backtrace and other debug info to the Oracle folks, will see what they have to say. -- -- 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) HEAD/RE24 and BDB 4.7.25p1 hanging
by michael＠stroeder.com 22 Sep '08

22 Sep '08

Full_Name: Michael Ströder Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.97.30) I'm trying to run current RE24 and HEAD with BDB 4.7.25p1. It hangs in test-001 and it hangs in a LDAP conn (probably when doing a bind). Is that combination really stable? It works with very same build scripts/configuration with 4.6.21+patches. Further information (bt full, log, BDB build script) is in this archived mailing list posting: http://www.openldap.org/lists/openldap-devel/200809/msg00075.html

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by ando＠sys-net.it 22 Sep '08

22 Sep '08

Gavin Henry wrote: > Again, thanks. Sets have been documentated for quite some time now: > > http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting… Right; they're not documented in the slapd.access(5) man page, yet. 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#5656) Bind operations with translucent overlay
by ghenry＠OpenLDAP.org 22 Sep '08

22 Sep '08

----- ando(a)sys-net.it wrote: > ghenry(a)OpenLDAP.org wrote: > > > Too tired today :-( For some reason I was talking about > slapo-unique, as I'm > > writing that up just now. > > Just to avoid (or increase :) confusion when you'll be back from > relax, > I don't recall working at slapo-unique recently. AFAIK, the old and > the > new config statements live together in perfect harmony, although > unique_uri is preferable as it is more expressive. OK, thanks. > I have added a restrict=<uri> parameter to slapo-constraint, which > allows to optionally restrict the entries the constraint would apply > to. > I have also allowed the <attr> to actually be an attribute list, in > case > one needs to apply the same constraint to more than one. Finally, the > > "set" type is now available. It uses the ACL sets' syntax, which, > AFAIK, is still undocumented. Again, thanks. Sets have been documentated for quite some time now: http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting… -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by ando＠sys-net.it 22 Sep '08

22 Sep '08

ghenry(a)OpenLDAP.org wrote: > Too tired today :-( For some reason I was talking about slapo-unique, as I'm > writing that up just now. Just to avoid (or increase :) confusion when you'll be back from relax, I don't recall working at slapo-unique recently. AFAIK, the old and the new config statements live together in perfect harmony, although unique_uri is preferable as it is more expressive. I have added a restrict=<uri> parameter to slapo-constraint, which allows to optionally restrict the entries the constraint would apply to. I have also allowed the <attr> to actually be an attribute list, in case one needs to apply the same constraint to more than one. Finally, the "set" type is now available. It uses the ACL sets' syntax, which, AFAIK, is still undocumented. 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#5656) Bind operations with translucent overlay
by ghenry＠OpenLDAP.org 22 Sep '08

22 Sep '08

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > > >> A note should already be in HEAD's slapo-translucent(5). > > > > Yeah, I saw that. I was reading the code and if I understand > correctly, old > > config directives will still work as long as the new URI directive > isn't present? > > Not sure what you mean there. The uri directive, afaik, is related to > > the captive database, and (relatively) transparent to the overlay. If > > you use translucent on a local instance of back-sql, there would be no > > uri directive at all. Too tired today :-( For some reason I was talking about slapo-unique, as I'm writing that up just now. Sorry for the confusion. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by ando＠sys-net.it 22 Sep '08

22 Sep '08

Gavin Henry wrote: >> A note should already be in HEAD's slapo-translucent(5). > > Yeah, I saw that. I was reading the code and if I understand correctly, old > config directives will still work as long as the new URI directive isn't present? Not sure what you mean there. The uri directive, afaik, is related to the captive database, and (relatively) transparent to the overlay. If you use translucent on a local instance of back-sql, there would be no uri directive at all. 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#5656) Bind operations with translucent overlay
by ghenry＠OpenLDAP.org 22 Sep '08

22 Sep '08

----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > Gavin Henry wrote: > > ----- ando(a)sys-net.it wrote: > > > >> RFC 3062 password modification extended operation on locally stored > > >> credentials is now in HEAD; please test and report. > >> > > > > I'll hold back adding a note in the Admin Guide about this. I think > it's best placed in the man page anyway. > > A note should already be in HEAD's slapo-translucent(5). Yeah, I saw that. I was reading the code and if I understand correctly, old config directives will still work as long as the new URI directive isn't present? My reason for asking is that I thought I might need to update the Upgrading section of the Admin Guide? > Perhaps we want the config statements sorted differently (e.g. lexicographically)? Doesn't bother me. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by ando＠sys-net.it 22 Sep '08

22 Sep '08

Gavin Henry wrote: > ----- ando(a)sys-net.it wrote: > >> RFC 3062 password modification extended operation on locally stored >> credentials is now in HEAD; please test and report. >> > > I'll hold back adding a note in the Admin Guide about this. I think it's best placed in the man page anyway. A note should already be in HEAD's slapo-translucent(5). Perhaps we want the config statements sorted differently (e.g. lexicographically)? 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#5656) Bind operations with translucent overlay
by ghenry＠OpenLDAP.org 22 Sep '08

22 Sep '08

----- ando(a)sys-net.it wrote: > RFC 3062 password modification extended operation on locally stored > credentials is now in HEAD; please test and report. > I'll hold back adding a note in the Admin Guide about this. I think it's best placed in the man page anyway. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 20 Sep '08

20 Sep '08

On Sat, 20 Sep 2008, Pierangelo Masarati wrote: > connection_next()? Or even better, the whole *c structure? Sure... (dbx) print *c *c = { c_struct_state = 2 c_conn_state = 2 c_conn_idx = 21 c_sd = 21 c_close_reason = 0x1002979d0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x1006af890 c_starttime = 1221349177 c_activitytime = 1221349191 c_connid = 41U c_peer_domain = { bv_len = 7U bv_val = 0x105d3ab40 "unknown" } c_peer_name = { bv_len = 18U bv_val = 0x1117714e0 "IP=127.0.0.1:51374" } c_listener = 0x1004acec0 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = 0x1005510b0 c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 28U bv_val = 0x11177ea00 "cn=Manager,dc=example,dc=com" } sai_ndn = { bv_len = 28U bv_val = 0x111771900 "cn=manager,dc=example,dc=com" } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 3 c_ops = { stqh_first = (nil) stqh_last = 0x10059e658 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x10059e668 } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = 0x10c759540 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x1081466b0 c_sasl_sockctx = (nil) c_sasl_extra = 0x105d38370 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 861 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 861 c_n_get = 861 c_n_read = 861 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x100071348 = &slap_send_ldap_result() c_send_search_entry = 0x1000727c8 = &slap_send_search_entry() c_send_search_reference = 0x1000753b8 = &slap_send_search_reference() c_send_ldap_extended = 0x100072038 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x100072458 = &slap_send_ldap_intermediate() } *c = { c_struct_state = 2 c_conn_state = 2 c_conn_idx = 26 c_sd = 26 c_close_reason = 0x1002979d0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x1041453f0 c_starttime = 1221416361 c_activitytime = 1221416386 c_connid = 24U c_peer_domain = { bv_len = 7U bv_val = 0x106754ec0 "unknown" } c_peer_name = { bv_len = 18U bv_val = 0x106753aa0 "IP=127.0.0.1:49627" } c_listener = 0x1004acec0 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = 0x1005510b0 c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 80U bv_val = 0x10c75ba20 "cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com" } sai_ndn = { bv_len = 80U bv_val = 0x1006b3530 "cn=barbara jensen,ou=information technology division,ou=people,dc=example,dc=com" } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 3 c_ops = { stqh_first = (nil) stqh_last = 0x10059f0f8 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x10059f108 } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = 0x1006bd3f0 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x107755210 c_sasl_sockctx = (nil) c_sasl_extra = 0x10674d4a0 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 817 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 817 c_n_get = 817 c_n_read = 817 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x100071348 = &slap_send_ldap_result() c_send_search_entry = 0x1000727c8 = &slap_send_search_entry() c_send_search_reference = 0x1000753b8 = &slap_send_search_reference() c_send_ldap_extended = 0x100072038 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x100072458 = &slap_send_ldap_intermediate() } *c = { c_struct_state = 1 c_conn_state = 9578416 c_conn_idx = 0 c_sd = 99 c_close_reason = 0x48cd983e "<bad address 0x48cd983e>" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 0 __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '' __pthread_mutex_type = 0 __pthread_mutex_magic = 0 } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 1U __pthread_lockword = 5577376U } __pthread_mutex_owner64 = 4300544672U } __pthread_mutex_data = 10U } c_sb = 0x10071ac88 c_starttime = 10 c_activitytime = 4302417080 c_connid = 8589934592U c_peer_domain = { bv_len = 2147483651600U bv_val = 0x100551b7c "" } c_peer_name = { bv_len = 0 bv_val = 0x10071ad08 "" } c_listener = 0x10071acd0 c_sasl_bind_mech = { bv_len = 15U bv_val = 0x10071acf0 "(objectClass=*)" } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 0 sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = 0x1009228f8 "" } sai_ndn = { bv_len = 128U bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 28U } c_protocol = 1 c_ops = { stqh_first = 0x1c stqh_last = 0x109753c70 } c_pending_ops = { stqh_first = (nil) stqh_last = (nil) } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 0 __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\001' __pthread_mutex_type = 450U __pthread_mutex_magic = 60032U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 0 } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = (nil) c_sasl_sockctx = (nil) c_sasl_extra = 0xf c_sasl_bindop = 0x43 c_pagedresults_state = { ps_be = 0x1005a00f0 ps_size = 16 ps_count = 3 ps_cookie = 12884901888U ps_cookieval = { bv_len = 18446744071444626464U bv_val = 0x10054a1a0 "" } } c_n_ops_received = 4299177360 c_n_ops_executing = 4302412176 c_n_ops_pending = 7165066951922169632 c_n_ops_completed = 8029985417153478656 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = (nil) c_send_search_entry = (nil) c_send_search_reference = (nil) c_send_ldap_extended = (nil) c_send_ldap_intermediate = (nil) }

1 0

Re: (ITS#5701) connection.c asserting during test008
by ando＠sys-net.it 20 Sep '08

20 Sep '08

richton(a)nbcs.rutgers.edu wrote: > Rare connection.c assertion during test008s of RE24. Here are three different > examples: > [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn > = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" > [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = > 0x1005c1b98), line 187 in "rww.c" > [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = > 0x1005c1b98), line 185 in "rww.c" Sorry, I overlooked the fact that all those issues are occurring from within back-monitor. In all cases, it's within code that loops through the connection array using connection_{first,next,close}(). Apparently, those calls are used in the right way. Can you print more information about those connections? E.g. c->c_struct_state, and *index from within connection_next()? Or even better, the whole *c structure? 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#5654) memberof syntax clunky
by ando＠sys-net.it 20 Sep '08

20 Sep '08

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.176.63.104) > > > As instructed by Howard: > > From: Howard Chu <hyc(a)highlandsun.com> > To: samba-technical(a)lists.samba.org > Subject: Re: samba4-ol-mmr > Date: Mon, 11 Aug 2008 21:09:52 -0700 (Tue, 14:09 EST) > > > >> # Generated from schema in /usr/local/samba/private/ldap/schema-tmp.ldb >> overlay memberof >> memberof-dn cn=samba-admin,cn=samba >> memberof-dangling error >> memberof-refint TRUE >> memberof-group-oc top >> memberof-member-ad msDS-ObjectReference >> memberof-memberof-ad msDS-ObjectReferenceBL >> memberof-dangling-error 32 > > (repeats once per attribute link) > > ... > > Mmm, that's really clunky. Someone should file an OpenLDAP enhancement request > on the memberof config syntax. You should only need to instantiate the overlay > once, and then it should just take a list of oc/forward-ad/back-ad config > options. > >> Look closely at how we sub in memberof configuration into the >> slapd.conf. I suggest that you could add a ${REPL_CONFIG} after each >> database, which the script could sub with either "" or by reading and >> subing in a slapd-replica.conf It's not the syntax that's clunky. You're (ab)using slapo-memberof(5), which was designed to deal with *just one* pair of member/reverse-link attribute relationship. Probably the overlay needs to be entirely reworked to provide a many-to-many relationship. At this point, I'd rather design a new one, giving up some of the not so useful extra features implemented in slapo-memberof(5), and focusing on the many-to-many main requirement. 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#5656) Bind operations with translucent overlay
by ando＠sys-net.it 20 Sep '08

20 Sep '08

RFC 3062 password modification extended operation on locally stored credentials is now in HEAD; please test and report. 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#5706) slapo-collect(5) is missing
by hyc＠symas.com 18 Sep '08

18 Sep '08

ghenry(a)suretecsystems.com wrote: > ----- ando(a)sys-net.it wrote: > >> ghenry(a)OpenLDAP.org wrote: >>> ----- ando(a)sys-net.it wrote: >>> >>>> ando(a)sys-net.it wrote: >>>> >>>>> Slapo-collect is now in re24, but no man page is available. >>>> Added to HEAD; please review. >>> If it supports cn=config, that should be mentioned in the man page. >> It does. Fixed, thanks. I'd note that only few man pages mention >> this >> fact, while most overlays do support back-config. > > Are there any left that don't? Just retcode. > Another one of my goals is to add a cn=config example > to each as well as the slapd.conf examples. > -- -- 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

Re: (ITS#5706) slapo-collect(5) is missing
by ghenry＠suretecsystems.com 18 Sep '08

18 Sep '08

----- ando(a)sys-net.it wrote: > ghenry(a)OpenLDAP.org wrote: > > ----- ando(a)sys-net.it wrote: > > > >> ando(a)sys-net.it wrote: > >> > >>> Slapo-collect is now in re24, but no man page is available. > >> Added to HEAD; please review. > > > > If it supports cn=config, that should be mentioned in the man page. > > It does. Fixed, thanks. I'd note that only few man pages mention > this > fact, while most overlays do support back-config. Are there any left that don't? Another one of my goals is to add a cn=config example to each as well as the slapd.conf examples. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

ghenry(a)OpenLDAP.org wrote: > ----- ando(a)sys-net.it wrote: > >> ando(a)sys-net.it wrote: >> >>> Slapo-collect is now in re24, but no man page is available. >> Added to HEAD; please review. > > If it supports cn=config, that should be mentioned in the man page. It does. Fixed, thanks. I'd note that only few man pages mention this fact, while most overlays do support back-config. 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#5706) slapo-collect(5) is missing
by ghenry＠OpenLDAP.org 18 Sep '08

18 Sep '08

----- ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > > > Slapo-collect is now in re24, but no man page is available. > > Added to HEAD; please review. If it supports cn=config, that should be mentioned in the man page. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

Howard Chu wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >> >>> Slapo-collect is now in re24, but no man page is available. >> >> Added to HEAD; please review. > > I'm not sure the reference to collectiveAttributeSubentry is helpful > here; this overlay was written independently of RFC3671. Its behavior > was based on my dim memory of how collective attributes behaved in the > last X.500 server I worked with, plus a lot of expedience - something > quick and easy to implement. Note that subentries cannot have children, > and the premise of this overlay is to propagate attributes from a parent > entry (not subentry) to all of its children. Right. In fact, I was a little bit confused after comparing the code with RFC 3671 & 3672. I fixed the man page. 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#5706) slapo-collect(5) is missing
by hyc＠symas.com 18 Sep '08

18 Sep '08

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Slapo-collect is now in re24, but no man page is available. > > Added to HEAD; please review. I'm not sure the reference to collectiveAttributeSubentry is helpful here; this overlay was written independently of RFC3671. Its behavior was based on my dim memory of how collective attributes behaved in the last X.500 server I worked with, plus a lot of expedience - something quick and easy to implement. Note that subentries cannot have children, and the premise of this overlay is to propagate attributes from a parent entry (not subentry) to all of its children. -- -- 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

Re: (ITS#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

quanah(a)zimbra.com wrote: > --On Thursday, September 18, 2008 8:12 PM +0000 ando(a)sys-net.it wrote: > >> ando(a)sys-net.it wrote: >> >>> Slapo-collect is now in re24, but no man page is available. >> Added to HEAD; please review. > > Do we need to acknowledge the work done on it by Brett Maxfield? Well, it's up to those who took care of it. I didn't quite followed that thread, and only credited Howard based on his initial submission in 2003. 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#5706) slapo-collect(5) is missing
by quanah＠zimbra.com 18 Sep '08

18 Sep '08

--On Thursday, September 18, 2008 8:12 PM +0000 ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Slapo-collect is now in re24, but no man page is available. > > Added to HEAD; please review. Do we need to acknowledge the work done on it by Brett Maxfield? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

ando(a)sys-net.it wrote: > Slapo-collect is now in re24, but no man page is available. Added to HEAD; please review. 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#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Slapo-collect is now in re24, but no man page is available. p.

1 0

(ITS#5705) [enhancement] slapo-constraint could honor "relax" by not checking for constraints
by ando＠sys-net.it 18 Sep '08

18 Sep '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See subject. p.

1 0

Issue in syncprov findcsn code
by Pierangelo Masarati 17 Sep '08

17 Sep '08

Not sure this is a bug, but I'm curious... I hit this while checking for ITS#5661. The code below is from HEAD's syncprov.c:613 (not changed recently; pardon any unintended line wrapping): <snip> again: switch( mode ) { case FIND_MAXCSN: cf.f_choice = LDAP_FILTER_GE; /* If there are multiple CSNs, use the one with our serverID */ for ( i=0; i<si->si_numcsns; i++) { if ( slap_serverID == si->si_sids[i] ) { maxid = i; break; } } </snip> When run by a consumer, with no serverID set (and thus slap_serverID == 0), it causes the consumer to use the contextCSN with SID == "000" instead of the most recent one. As a consequence, if one searches the contextCSN within that consumer, slapo-syncprov's syncprov_operational() causes only that value to be returned, instead of all contextCSNs. After the consumer is restarted, all values are correctly returned. To reproduce: - populate a DSA (SIDs in CSNs will default to "000") - turn it into a (multi)master by adding the serverID statement (with SID > "000") and so - perform a modification (so that the most recent contextCSN will have SID != "000") - create a consumer (no serverID statement, so that it defaults to "000") and let it pull data from the producer - search the contextCSN of the consumer I'm not sure this is a bug; it might be harmless, apart from being definitely misleading. There might be multiple solutions: - don't let syncprov_operational() muck with contextCSN that way - make syncprov_findcsn() search the newest contextCSN instead of the one with its SID - initialize slapd_serverID with some SID_UNDEFINED in order to take the action above only when SID is not defined 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 -----------------------------------

4 8

syncrepl failed without errors when a put a TAB character in slapd.conf
by liandro sg 17 Sep '08

17 Sep '08

Running slapd 2.4.10-3 version on debian 2.6.25-2-686 If I put a TAB (ascii character decimal 9) starting a line in slapd.conf , in front of syncrepl configuration option, the syncrepl funcionlity don't starts . The fonfiguration test ( slaptest) return success. If I delete the TAB character, syncrepl run ok

2 1

Re: (ITS#5704) [enhancement] allow restrictions in slapo-constraint(5)
by ando＠sys-net.it 17 Sep '08

17 Sep '08

ando(a)sys-net.it wrote: > This patch allows to restrict a constraint to entries matching an LDAP URI; > complements ITS#5702. ... in the sense that a constraint like constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" needs to be restricted to entries whose objectClass is derived from inetOrgPerson. This is accomplished by using constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" restrict="ldap:///dc=example,dc=com??sub?(objectClass=inetOrgPerson)" 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#5704) [enhancement] allow restrictions in slapo-constraint(5)
by ando＠sys-net.it 17 Sep '08

17 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando This patch allows to restrict a constraint to entries matching an LDAP URI; complements ITS#5702. p.

1 0

(ITS#5703) slapo-constraint(5) rename issue
by ando＠sys-net.it 17 Sep '08

17 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.148) Submitted by: ando I see an issue in slapo-constraint(5): it does not handle rename ops; as a consequence, a rename could result in violating constraints on the values of the naming attributes. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs