From ST@itsc.cuhk.edu.hk Mon Sep 1 03:59:46 2008 From: ST@itsc.cuhk.edu.hk To: openldap-bugs@openldap.org Subject: Re: (ITS#5545) Inconsistency in multi-master setup Date: Mon, 01 Sep 2008 03:59:45 +0000 Message-ID: <200809010359.m813xjlp049642@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0873821788200123534==" --===============0873821788200123534== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C90BE7.19D98D08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, same result on 2.4.11. Thanks a lot. Best Regards, /ST Wong st-wong(a)cuhk.edu.hk ------_=_NextPart_001_01C90BE7.19D98D08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: (ITS#5545) Inconsistency in multi-master setup

Yes, same result on 2.4.11.  = Thanks a lot.

Best Regards,
/ST Wong
st-wong(a)cuhk.edu.hk

------_=_NextPart_001_01C90BE7.19D98D08-- --===============0873821788200123534==-- From andrew.findlay@skills-1st.co.uk Mon Sep 1 17:30:45 2008 From: andrew.findlay@skills-1st.co.uk To: openldap-bugs@openldap.org Subject: Re: (ITS#5578) sortvals error Date: Mon, 01 Sep 2008 17:30:44 +0000 Message-ID: <200809011730.m81HUiXQ091197@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7043130059927526392==" --===============7043130059927526392== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Aug 30, 2008 at 10:39:13PM +0000, hyc(a)symas.com wrote: > Fixed again in HEAD, please test. Tests OK on openSUSE 10.2 (i586) and openSUSE 10.2 (X86-64) Thanks Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- --===============7043130059927526392==-- From miguel.jinez@gmail.com Mon Sep 1 18:50:44 2008 From: miguel.jinez@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5673) Replication delete problem Date: Mon, 01 Sep 2008 18:50:44 +0000 Message-ID: <200809011850.m81IoipT094134@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7798337077708241335==" --===============7798337077708241335== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Miguel Angel Version: 2.4.11 OS: Linux Ubuntu 8.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (190.244.109.137) Hello, I have found a problem with massive deletes on openldap 2.4.11 (stable) I have configure 3 masters with mirror mode, in a schema multi-master, with persistent replication I have delete 8600 objects, in one of my masters (A). Master A now has 920 objects Master B now has 920 objects Master C now has 2125 objects Master A and master B are ok, but master C has lost delete actions. Please help me to solve that Migue --===============7798337077708241335==-- From ghenry@OpenLDAP.org Mon Sep 1 19:31:24 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5545) Inconsistency in multi-master setup Date: Mon, 01 Sep 2008 19:31:23 +0000 Message-ID: <200809011931.m81JVN4Y095834@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2634936630201659284==" --===============2634936630201659284== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I forgot to ask if this was testing against only one node at a time with mirrormode setup. Your setup isn't multimaster. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============2634936630201659284==-- From ghenry@OpenLDAP.org Mon Sep 1 19:41:35 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5673) Replication delete problem Date: Mon, 01 Sep 2008 19:41:35 +0000 Message-ID: <200809011941.m81JfZ4r096885@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7590481669996242696==" --===============7590481669996242696== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit miguel.jinez(a)gmail.com wrote: > Full_Name: Miguel Angel > Version: 2.4.11 > OS: Linux Ubuntu 8.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (190.244.109.137) > > > Hello, > I have found a problem with massive deletes on openldap 2.4.11 (stable) > I have configure 3 masters with mirror mode, in a schema multi-master, with > persistent replication > I have delete 8600 objects, in one of my masters (A). > Master A now has 920 objects > Master B now has 920 objects > Master C now has 2125 objects > Master A and master B are ok, but master C has lost delete actions. > > Please help me to solve that > > Migue > > This is a duplicate of ITS#5617 and will be closed. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============7590481669996242696==-- From ghenry@OpenLDAP.org Mon Sep 1 19:42:40 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: N-way multimaster replication problem (ITS#5617) Date: Mon, 01 Sep 2008 19:42:39 +0000 Message-ID: <200809011942.m81JgdjO097553@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6592790471472851133==" --===============6592790471472851133== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit miguel.jinez(a)gmail.com wrote: > Hello, I have complied openldap 2.4.11 now, and I have test again, but > the problem persist > > El mié, 27-08-2008 a las 20:10 +0000, Gavin Henry escribió: >> Can you try on 2.4.11 now. >> >> Thanks. > > can you try Multi-Master and not MirrorMode: http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master You don't have: serverID 1 LDAP_URI -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============6592790471472851133==-- From ghenry@OpenLDAP.org Mon Sep 1 20:40:50 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5673) Replication delete problem Date: Mon, 01 Sep 2008 20:40:49 +0000 Message-ID: <200809012040.m81KenEb000303@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7985226738477800323==" --===============7985226738477800323== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Miguel Jinez wrote: > It is no the same problem, is a new problem On list please. They are related. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============7985226738477800323==-- From ghenry@OpenLDAP.org Mon Sep 1 20:40:54 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: N-way multimaster replication problem (ITS#5617) Date: Mon, 01 Sep 2008 20:40:54 +0000 Message-ID: <200809012040.m81KesqY000335@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8886432016041986341==" --===============8886432016041986341== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Miguel Jinez wrote: > I have SERVERID 1, SERVERID 2 and SERVERID 3 for each master configuration >=20 On list please. See below. >=20 >=20 > can you try Multi-Master and not MirrorMode: >=20 > http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Mast= er >=20 > You don't have: >=20 > serverID 1 LDAP_URI >=20 --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============8886432016041986341==-- From hyc@symas.com Tue Sep 2 03:27:42 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5672) Build of back-ndb fails - back-ndb.h:26:22: error: NdbApi.hpp: No such file or directory Date: Tue, 02 Sep 2008 03:27:41 +0000 Message-ID: <200809020327.m823RfOM010626@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6796998940777955126==" --===============6796998940777955126== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> hyc(a)symas.com wrote: >>> ando(a)sys-net.it wrote: >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Ströder >>>>> Version: HEAD >>>>> OS: Linux >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (84.163.97.73) >>>>> I think this says it all: >>>>> >>>>> back-ndb.h:26:22: error: NdbApi.hpp: No such file or directory >>>>> >>>>> I could provide the complete build output if needed. >>> As such, this section Works As Designed. ITS will be closed... > > Well, the reliability of expecting things to be where people document > them is the reason autotools were created in the first place... > however, I'm having other problems right now: NdbInterpretedCode.hpp > isn't included, so all occurrences of NdbInterpretedCode cause an error; > but when I explicitly include that header, it requires some other header > that is not available... Apparently, I'm using the wrong version, but > this seems to indicate that the whole Ndb API needs to stabilize. Ah yes, that's true. We had to use a number of APIs that weren't documented when development began, and also a number of APIs were added for us. So yes, you definitely need a very recent release. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6796998940777955126==-- From ST@itsc.cuhk.edu.hk Tue Sep 2 07:39:52 2008 From: ST@itsc.cuhk.edu.hk To: openldap-bugs@openldap.org Subject: Re: (ITS#5545) Inconsistency in multi-master setup Date: Tue, 02 Sep 2008 07:39:51 +0000 Message-ID: <200809020739.m827dpP4020722@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4793693125401740777==" --===============4793693125401740777== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Oops, I tested on both nodes, which is not supposed to do so in mirrormode, right? Sorry for the trouble caused. Thanks. --===============4793693125401740777==-- From ali.pouya@free.fr Tue Sep 2 15:33:19 2008 From: ali.pouya@free.fr To: openldap-bugs@openldap.org Subject: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror Date: Tue, 02 Sep 2008 15:33:19 +0000 Message-ID: <200809021533.m82FXJUZ053088@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6843667342763421615==" --===============6843667342763421615== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Pierangelo mazarati wrote : > Can you try a fresh reload of the database(s) stripping out the entryCSN > and letting slapadd generate them, using the -S switch (along with > the -w switch), in order to enforce a SID of 001 (or 002, as you like)? Hi Pierangelo, I made a new directory with only one contextCSN (SID=002) as you recommended, and reproduced the contextCSN corruption problem several times. Example1 : contextCSN:: 0L0NojA5MDIxMjU5NDkuNzMwMjg1WiMwMDAwMDAjMDAyIzAwMDAwMA== The four corrupted bytes at the beginning are : D0 BD 02 A2 (hex) Example2 : contextCSN:: 4I54oTA5MDIxNTE5MTYuMjYzNDIxWiMwMDAwMDAjMDAyIzAwMDAwMA== The four corrupted bytes at the beginning are : E0 8E 78 A1 (hex) I insist on the fact that the problem heppens ONLY if I use TWO syncrepl directives as recommended in the Admin Guide. If I use only ONE syncrepl directive, I don't reproduce the problem and the mirrors get synchronized correctly (whichever mirror side I use for writing). Also the problem happens on the stand by mirror only when therer are write operations on the active mirror (> 1000 writes per minute). I do not understand the interest of using TWO syncrepl directives for mirrormode. Thanks for your help Best Regards Ali --===============6843667342763421615==-- From miguel.jinez@gmail.com Tue Sep 2 15:35:14 2008 From: miguel.jinez@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5673) Replication delete problem Date: Tue, 02 Sep 2008 15:35:13 +0000 Message-ID: <200809021535.m82FZDIG054001@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3596887946826815035==" --===============3596887946826815035== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ------=3D_Part_7335_29974836.1220369704755 Content-Type: text/plain; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I was making a test deleting 8600 users in my ldap DIT, but I think meanwhile Master A perform the actions the synchronization doesn't respect the hierachy and deletes fathers but not his sons. Why I said that, because I try to upload again the users and in some cases they alredy exist Migue 2008/9/1 > Miguel Jinez wrote: > > It is no the same problem, is a new problem > > On list please. They are related. > > > -- > Kind Regards, > > Gavin Henry. > OpenLDAP Engineering Team. > > E ghenry(a)OpenLDAP.org > > Community developed LDAP software. > > http://www.openldap.org/project/ > > > ------=3D_Part_7335_29974836.1220369704755 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I was making a test deleting 8600 users in my ldap DIT, but = I think meanwhile Master A perform the actions the synchronization doesn'= t  respect the hierachy and deletes fathers but not his sons.
Why I s= aid that, because I try to upload again the users and in some cases they alre= dy exist

Migue

2008/9/1 <<= a href=3D"mailto:ghenry(a)openldap.org">ghenry(a)openldap.org><= br>
Miguel Jinez wrote:
> It is no the same problem, is a new problem

On list please. They are related.


--
Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E ghenry(a)OpenLDAP.org

Community developed LDAP software.

http://www.ope= nldap.org/project/



------=3D_Part_7335_29974836.1220369704755-- --===============3596887946826815035==-- From ando@sys-net.it Tue Sep 2 17:22:54 2008 From: Pierangelo Masarati To: openldap-bugs@openldap.org Subject: Issue in syncprov findcsn code Date: Tue, 02 Sep 2008 19:22:43 +0200 Message-ID: <48BD7663.7090504@sys-net.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5977403779038735287==" --===============5977403779038735287== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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): 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; isi_numcsns; i++) { if ( slap_serverID == si->si_sids[i] ) { maxid = i; break; } } 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 ----------------------------------- --===============5977403779038735287==-- From ando@sys-net.it Tue Sep 2 18:30:28 2008 From: Pierangelo Masarati To: openldap-bugs@openldap.org Subject: Re: Issue in syncprov findcsn code Date: Tue, 02 Sep 2008 20:30:20 +0200 Message-ID: <48BD863C.3020202@sys-net.it> In-Reply-To: <48BD7663.7090504@sys-net.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0319064270030026342==" --===============0319064270030026342== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Pierangelo Masarati wrote: > Not sure this is a bug, but I'm curious... Apparently, the issue is a bit different. The wrong contextCSN comes from somewhere else. When the consumer starts empty, syncprov_db_open() does not find the context entry. Subsequently, after the refresh phase, the wrong (and only) contextCSN is taken from the pending CSN list in slap_get_commit_csn(). It seems to be syncrepl_updateCookie() who uses the wrong contextCSN in slap_queue_csn(). Fixing... 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 ----------------------------------- --===============0319064270030026342==-- From ando@sys-net.it Tue Sep 2 18:32:57 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5675) Incorrect contextCSN detection during consumer initialization? Date: Tue, 02 Sep 2008 18:32:56 +0000 Message-ID: <200809021832.m82IWu75063935@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2781413108746301532==" --===============2781413108746301532== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Pierangelo Masarati Version: HEAD (earlier?) OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See and, significantly, its follow-up. The most recent contextCSN should be used instead of just the first one. p. --===============2781413108746301532==-- From ando@sys-net.it Tue Sep 2 18:57:32 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5676) Possible dereferencing of uninitialized pointer in bdb_entry_get() Date: Tue, 02 Sep 2008 18:57:31 +0000 Message-ID: <200809021857.m82IvVr2065853@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8683239953773273408==" --===============8683239953773273408== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando In bdb_entry_get(), if oex->oe_key =3D=3D bdb then boi is NULL; however, it c= ould be dereferenced few lines later (it happened to me under heavy load). A fix is coming. p. --===============8683239953773273408==-- From ando@sys-net.it Tue Sep 2 19:26:50 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror Date: Tue, 02 Sep 2008 19:26:50 +0000 Message-ID: <200809021926.m82JQolH069904@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5147238088544168557==" --===============5147238088544168557== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ali.pouya(a)free.fr wrote: > I made a new directory with only one contextCSN (SID=3D002) as you recommen= ded, > and reproduced the contextCSN corruption problem several times. >=20 > Example1 : > contextCSN:: 0L0NojA5MDIxMjU5NDkuNzMwMjg1WiMwMDAwMDAjMDAyIzAwMDAwMA=3D=3D >=20 > The four corrupted bytes at the beginning are : D0 BD 02 A2 (hex) >=20 > Example2 : > contextCSN:: 4I54oTA5MDIxNTE5MTYuMjYzNDIxWiMwMDAwMDAjMDAyIzAwMDAwMA=3D=3D >=20 > The four corrupted bytes at the beginning are : E0 8E 78 A1 (hex) >=20 >=20 > I insist on the fact that the problem heppens ONLY if I use TWO syncrepl > directives as recommended in the Admin Guide. > If I use only ONE syncrepl directive, I don't reproduce the problem and the > mirrors get synchronized correctly (whichever mirror side I use for writing= ). > Also the problem happens on the stand by mirror only when therer are write > operations on the active mirror (> 1000 writes per minute). >=20 > I do not understand the interest of using TWO syncrepl directives for > mirrormode. Well, going back to your initial posting, I think you are somehow=20 correct. Rather than not seeing the point of having two syncrepl=20 statements (of which only one is supposed to be active), I see it as an=20 inconsistent and potentially dangerous configuration. In fact, the only=20 advantage of having two syncrepl statements is related to being able to=20 share the same configuration among two symmetric servers (mirror mode,=20 multimaster, ...), using the serverID directive to determine what is the=20 "right" one. But in that case, you'd need to have multiple serverID=20 directives as well, with the URI field set. I set up a test system with=20 your configuration, and loaded it very heavily, while running the server=20 that's supposed to screw up under valgrind. I haven't seen any issue=20 yet, though. 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 ----------------------------------- --===============5147238088544168557==-- From mgwin@escp-eap.net Wed Sep 3 09:47:06 2008 From: mgwin@escp-eap.net To: openldap-bugs@openldap.org Subject: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered Date: Wed, 03 Sep 2008 09:47:06 +0000 Message-ID: <200809030947.m839l6bh029531@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8576626058734154008==" --===============8576626058734154008== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Michael Gwin Version: 2.3.30 OS: linux (debian etch x86_64) URL:=20 Submission from: (NULL) (195.85.247.248) Hi, Replication of our ldap database often stops working, with pending changes stacking up and not getting processed by slurpd. /var/lib/ldap/replog (as configured in slapd.conf by the "replog" directive) fills up with entries, and slurpd doesn't pick up on them. Whilst trying to debug the issue, I noticed there were consecutive blank lines seperating entries in the replication log (both /var/lib/ldap/replog and /var/spool/slurpd/replica/slurpd.replog). Running slurpd in one shot mode on either of these files would result in any entries before the consecutive blank lines being processed, but not the entries following them. After reducing each set of consecutive blank lines to one blank line, slurpd processes all entries correctly. The replicas are set up in slapd.conf as follows: replogfile /var/lib/ldap/replog replica uri=3Dldap://host1.domain.tld:389 starttls=3Dcritical bindmethod=3Dsimple binddn=3D"cn=3Dreplicationuser,o=3DMYORG" credentials=3DXYZ replica uri=3Dldaps://host2.domain.tld:636 bindmethod=3Dsimple binddn=3D"cn=3Dreplicationuser,o=3DMYORG" credentials=3DXYZ attrs=3Daccount,MYORGGroup,MYORGPerson,\ organization,organizationalRole,\ organizationalUnit,posixAccount,posixGroup,\ simpleSecurityObject,top NB. - the "attrs" directive of the second replica is one line in slapd.conf. - some of the (confidential) values have been changed. version info: - openldap 2.3.30 on all hosts (debian package: slapd-2.3.30-5+etch1) - all hosts are running debian etch x86_64 Not all entries are seperated by multiple blank lines. I don't know if it's ok in theory for slapd to write multiple blank lines to /var/lib/ldap/replog, but slurpd should handle them properly, or if slapd shouldn't be writing them at all. How to reproduce: Insert consecutive blank lines between two entries in a replication log, and = run slurpd in one-shot mode on it. Processing stops when the consecutive blank li= nes are encountered. --===============8576626058734154008==-- From julien@famille-garnier.com Wed Sep 3 10:08:40 2008 From: julien@famille-garnier.com To: openldap-bugs@openldap.org Subject: (ITS#5679) Translucent search Date: Wed, 03 Sep 2008 10:08:39 +0000 Message-ID: <200809031008.m83A8dY7030472@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1328472360812295220==" --===============1328472360812295220== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Julien Version: 2.4.11 OS: Linux ldap1 2.6.18-6-xen-686 #1 SMP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.49.133.163) It seems to be impossible to search local and remote together :=20 a search request against one local attribute work correctly and return result= 1 (ldapsearch "(local=3D*)") a search on a remote atttribute works fine and return result 2 (ldapsearch "(remote=3D*)") Finaly, a search with the local and remote attribute (ldapsearch "($(local=3D*)(remote=3D*))") only return results as the search on the local attribute and doesn't take the remote attribute. The respons is the same as result 1 In slapd.conf :=20 translucent_local local translucent_remote remote Thanks Juju --===============1328472360812295220==-- From mgwin@escp-eap.net Wed Sep 3 10:28:42 2008 From: mgwin@escp-eap.net To: openldap-bugs@openldap.org Subject: Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered Date: Wed, 03 Sep 2008 10:28:41 +0000 Message-ID: <200809031028.m83ASfOd031581@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4397380976636268423==" --===============4397380976636268423== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I missed a few lines from the replica definitions in slapd.conf. Not sure if it matters much, but for the sake of completeness, here are the full replica definitions (with some information obfuscated): replogfile /var/lib/ldap/replog replica uri=3Dldap://host1.domain.tld:389 starttls=3Dcritical bindmethod=3Dsimple binddn=3D"cn=3Dreplicationuser,o=3DMYORG" credentials=3DXYZ replica uri=3Dldaps://host2.domain.tld:636 bindmethod=3Dsimple binddn=3D"cn=3Dreplicationuser,o=3DMYORG" credentials=3DXYZ attrs=3Daccount,MYORGGroup,MYORGPerson,organization,organ= izationalRole,organizationalUnit,posixAccount,posixGroup,simpleSecurityObject= ,top suffix=3D"ou=3Dou3,ou=3Dou1,o=3DMYORG" suffix=3D"ou=3Dou4,ou=3Dou1,o=3DMYORG" suffix=3D"ou=3Dou5,ou=3Dou2,o=3DMYORG" suffix=3D"ou=3Dou6,ou=3Dou2,o=3DMYORG" suffix=3D"ou=3Dou7,o=3DMYORG" suffix=3D"ou=3Dou8,o=3DMYORG" --===============4397380976636268423==-- From quanah@zimbra.com Wed Sep 3 16:09:06 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: (ITS#5680) pcache not returning cached entries Date: Wed, 03 Sep 2008 16:09:05 +0000 Message-ID: <200809031609.m83G95H5051150@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0471787563067689438==" --===============0471787563067689438== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Quanah Gibson-Mount Version: 2.4.10 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As reported on the Debian bug tracker as bug#497697. The pcache overlay caches the entries but fails to return them in later searches. Search with empty cache: | # extended LDIF | # | # LDAPv3 | # base with scope subtree | # filter: (objectclass=person) | # requesting: cn | # | | # blank, Example | dn: cn=blank,o=Example | | # search result | search: 2 | result: 0 Success | | # numResponses: 2 | # numEntries: 1 Search with hot cache: | # extended LDIF | # | # LDAPv3 | # base with scope subtree | # filter: (objectclass=person) | # requesting: cn | # | | # search result | search: 2 | result: 0 Success | | # numResponses: 1 Config: | allow bind_anon_cred update_anon | include /etc/ldap/schema/core.schema | pidfile /var/run/slapd/slapd.pid | argsfile /var/run/slapd/slapd.args | loglevel none | modulepath /usr/lib/ldap | moduleload back_bdb | moduleload back_ldap | moduleload pcache | sizelimit 500 | tool-threads 1 | | database ldap | suffix "o=Example" | rootdn "cn=admin,o=Example" | uri "ldap://ldap.example.com/" | protocol-version 3 | | overlay pcache | proxycache bdb 10000 1 500 1000 | proxyattrset 0 cn | proxytemplate "(objectClass=)" 0 3600 | directory "/var/lib/ldap/cache" | | access to * by * write Log of first search: | conn=0 op=1 SRCH base="cn=blank,o=Example" scope=2 deref=0 filter="(objectClass=person)" | conn=0 op=1 SRCH attr=cn | ==> limits_get: conn=0 op=1 dn="[anonymous]" | query template of incoming query = (objectClass=) | Entering QC, querystr = (objectClass=person) | Lock QC index = 0x7d7040 | Not answerable: Unlock QC index=0x7d7040 | QUERY NOT ANSWERABLE | QUERY CACHEABLE | [...] | send_ldap_result: conn=-1 op=0 p=3 | send_ldap_result: err=0 matched="" text="" | ENTRY ADDED/MERGED, CACHED ENTRIES=1 | STORED QUERIES = 1 Log of second search: | conn=1 op=1 SRCH base="cn=blank,o=Example" scope=2 deref=0 filter="(objectClass=person)" | conn=1 op=1 SRCH attr=cn | ==> limits_get: conn=1 op=1 dn="[anonymous]" | query template of incoming query = (objectClass=) | Entering QC, querystr = (objectClass=person) | Lock QC index = 0x7d7040 | QUERY ANSWERABLE | => bdb_search Search in the cache db for (!(objectClass=glue)) or so. | bdb_dn2entry("cn=blank,ou=cz,o=jura") | => access_allowed: search access to "cn=blank,o=Example" "entry" requested | => acl_get: [1] attr entry | => acl_mask: access to entry "cn=blank,o=Example", attr "entry" requested | => acl_mask: to all values by "", (=0) | <= check a_dn_pat: * | <= acl_mask: [1] applying write(=wrscxd) (stop) | <= acl_mask: [1] mask: write(=wrscxd) | => slap_access_allowed: search access granted by write(=wrscxd) | => access_allowed: search access granted by write(=wrscxd) | search_candidates: base="cn=blank,ou=cz,o=jura" (0x00000003) scope=2 | => bdb_dn2idl("cn=blank,ou=cz,o=jura") | bdb_idl_fetch_key: @cn=blank,ou=cz,o=jura | <= bdb_dn2idl: id=1 first=3 last=3 | => bdb_filter_candidates | AND | => bdb_list_candidates 0xa0 | => bdb_filter_candidates | OR | => bdb_list_candidates 0xa1 | => bdb_filter_candidates | EQUALITY | => bdb_equality_candidates (objectClass) | <= bdb_equality_candidates: (objectClass) not indexed | <= bdb_filter_candidates: id=-1 first=1 last=3 | => bdb_filter_candidates | EQUALITY | => bdb_equality_candidates (objectClass) | <= bdb_equality_candidates: (objectClass) not indexed | <= bdb_filter_candidates: id=-1 first=1 last=3 | <= bdb_list_candidates: id=-1 first=1 last=3 | <= bdb_filter_candidates: id=-1 first=1 last=3 | <= bdb_list_candidates: id=1 first=3 last=3 | <= bdb_filter_candidates: id=1 first=3 last=3 | bdb_search_candidates: id=1 first=3 last=3 | => test_filter | EQUALITY | => access_allowed: search access to "cn=blank,ou=CZ,o=Jura" "objectClass" requested | => acl_get: [1] attr objectClass | => acl_mask: access to entry "cn=blank,ou=CZ,o=Jura", attr "objectClass" requested | => acl_mask: to value by "", (=0) | <= check a_dn_pat: * | <= acl_mask: [1] applying write(=wrscxd) (stop) | <= acl_mask: [1] mask: write(=wrscxd) | => slap_access_allowed: search access granted by write(=wrscxd) | => access_allowed: search access granted by write(=wrscxd) | <= test_filter 21 test_filter returned LDAP_INVALID_SYNTAX. | bdb_search: 3 does not match filter Content of the cache db: | dn: o=Example | structuralObjectClass: glue | objectClass: top | objectClass: glue | | dn: cn=blank,o=Example | queryId: c975e84a-0e16-102d-8355-4be7c415200f | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d | objectClass: inetOrgPerson | objectClass: organizationalPerson | objectClass: person | objectClass: ndsLoginProperties | objectClass: top The backend server is a Novell eDirectory and the proxy don't have information about the complete schema. Bastian --===============0471787563067689438==-- From ando@sys-net.it Wed Sep 3 16:52:51 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5680) pcache not returning cached entries Date: Wed, 03 Sep 2008 16:52:50 +0000 Message-ID: <200809031652.m83GqobZ055468@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8927580852709341290==" --===============8927580852709341290== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.10 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > As reported on the Debian bug tracker as bug#497697. Works as intended here (HEAD & re24). I note that in the reported slapd.conf objectClass is not indexed for the proxy database; maybe someone mucked with index statements? 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 ----------------------------------- --===============8927580852709341290==-- From ando@sys-net.it Wed Sep 3 19:08:02 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5680) pcache not returning cached entries Date: Wed, 03 Sep 2008 19:08:02 +0000 Message-ID: <200809031908.m83J82f0064613@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7052720003873820254==" --===============7052720003873820254== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit quanah(a)zimbra.com wrote: > test_filter returned LDAP_INVALID_SYNTAX. I think the culprit of the issue is here ^^^ > | dn: cn=blank,o=Example > | queryId: c975e84a-0e16-102d-8355-4be7c415200f > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d > | objectClass: inetOrgPerson > | objectClass: organizationalPerson > | objectClass: person > | objectClass: ndsLoginProperties > | objectClass: top > > The backend server is a Novell eDirectory and the proxy don't have > information about the complete schema. I suspect the remote server is returning an objectClass that is unknown to the proxy; for example, ndsLoginProperties. So, not ours :) 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 ----------------------------------- --===============7052720003873820254==-- From ando@sys-net.it Wed Sep 3 19:23:50 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5680) pcache not returning cached entries Date: Wed, 03 Sep 2008 19:23:50 +0000 Message-ID: <200809031923.m83JNodu065939@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9115855188058082300==" --===============9115855188058082300== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> test_filter returned LDAP_INVALID_SYNTAX. > > I think the culprit of the issue is here ^^^ > > > | dn: cn=blank,o=Example > > | queryId: c975e84a-0e16-102d-8355-4be7c415200f > > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d > > | objectClass: inetOrgPerson > > | objectClass: organizationalPerson > > | objectClass: person > > | objectClass: ndsLoginProperties > > | objectClass: top > > >> The backend server is a Novell eDirectory and the proxy don't have >> information about the complete schema. > > I suspect the remote server is returning an objectClass that is unknown > to the proxy; for example, ndsLoginProperties. So, not ours :) I could reproduce the issue by caching an entry with an objectClass not known to the proxy :). So the "right" solution consists in fixing the proxy's schema. Of course, OpenLDAP could inform the proxy administrator with some intelligible message or, even better, try to repair itself (e.g. by checking the remote server's subschemaSubentry). 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 ----------------------------------- --===============9115855188058082300==-- From ando@sys-net.it Wed Sep 3 20:02:44 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5680) pcache not returning cached entries Date: Wed, 03 Sep 2008 20:02:44 +0000 Message-ID: <200809032002.m83K2ier067302@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6972011491531550345==" --===============6972011491531550345== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Probably, a more consistent behavior would be to refuse caching queries containing entries that do not pass normalization. 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 ----------------------------------- --===============6972011491531550345==-- From hyc@symas.com Wed Sep 3 23:58:16 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5680) pcache not returning cached entries Date: Wed, 03 Sep 2008 23:58:15 +0000 Message-ID: <200809032358.m83NwF9N022508@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4463622288651903256==" --===============4463622288651903256== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> quanah(a)zimbra.com wrote: >> >>> test_filter returned LDAP_INVALID_SYNTAX. >> I think the culprit of the issue is here ^^^ >> >> > | dn: cn=3Dblank,o=3DExample >> > | queryId: c975e84a-0e16-102d-8355-4be7c415200f >> > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d >> > | objectClass: inetOrgPerson >> > | objectClass: organizationalPerson >> > | objectClass: person >> > | objectClass: ndsLoginProperties >> > | objectClass: top >> > >>> The backend server is a Novell eDirectory and the proxy don't have >>> information about the complete schema. >> I suspect the remote server is returning an objectClass that is unknown >> to the proxy; for example, ndsLoginProperties. So, not ours :) > > I could reproduce the issue by caching an entry with an objectClass not > known to the proxy :). So the "right" solution consists in fixing the > proxy's schema. Of course, OpenLDAP could inform the proxy > administrator with some intelligible message or, even better, try to > repair itself (e.g. by checking the remote server's subschemaSubentry). > Probably not a good idea to do that automagically. Perhaps with a config=20 switch. Also, not a good idea to import miscellaneous foreign schema globally= ;=20 we should implement per-database schema instead. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============4463622288651903256==-- From ando@sys-net.it Thu Sep 4 05:10:27 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5680) pcache not returning cached entries Date: Thu, 04 Sep 2008 05:10:27 +0000 Message-ID: <200809040510.m845ARo8062246@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2812484302722745691==" --===============2812484302722745691== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit hyc(a)symas.com wrote: >>>> The backend server is a Novell eDirectory and the proxy don't have >>>> information about the complete schema. >>> I suspect the remote server is returning an objectClass that is unknown >>> to the proxy; for example, ndsLoginProperties. So, not ours :) >> I could reproduce the issue by caching an entry with an objectClass not >> known to the proxy :). So the "right" solution consists in fixing the >> proxy's schema. Of course, OpenLDAP could inform the proxy >> administrator with some intelligible message or, even better, try to >> repair itself (e.g. by checking the remote server's subschemaSubentry). >> > Probably not a good idea to do that automagically. Perhaps with a config > switch. Right. I'll fix it. > Also, not a good idea to import miscellaneous foreign schema globally; > we should implement per-database schema instead. I think per-database subschema has been on the todolist since ever or so :) 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 ----------------------------------- --===============2812484302722745691==-- From ando@sys-net.it Thu Sep 4 06:04:09 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5681) canonicalize undef objectClass names? Date: Thu, 04 Sep 2008 06:04:09 +0000 Message-ID: <200809040604.m84649hG065258@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1458872203843108304==" --===============1458872203843108304== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Currently, slapd canonicalizes undef (or proxied) attribute names by making t= hem uppercased. It should do the same with undef objectClass names. A patch is coming. p. --===============1458872203843108304==-- From ando@sys-net.it Thu Sep 4 06:08:59 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5680) pcache not returning cached entries Date: Thu, 04 Sep 2008 06:08:58 +0000 Message-ID: <200809040608.m8468wow066661@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1711299296231408869==" --===============1711299296231408869== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Howard Chu wrote: >> Right. I'll fix it. > > Actually... I think the original patch was fine. I meant, checking the > remote server's subschema should be optional... ;) Too late :) well, I don't like too much the idea of having yet another fine-tune parameter in config, but this change could impact users that need to proxy well-configured systems and, say, cache entries with huge member lists or so... so better make diversion from original behavior optional, if the original behavior is safe in sane setups. 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 ----------------------------------- --===============1711299296231408869==-- From hyc@symas.com Thu Sep 4 06:09:16 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5680) pcache not returning cached entries Date: Thu, 04 Sep 2008 06:09:16 +0000 Message-ID: <200809040609.m8469G9U066712@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2713755887385589149==" --===============2713755887385589149== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >>>>> The backend server is a Novell eDirectory and the proxy don't have >>>>> information about the complete schema. >>>> I suspect the remote server is returning an objectClass that is unknown >>>> to the proxy; for example, ndsLoginProperties. So, not ours :) >>> I could reproduce the issue by caching an entry with an objectClass not >>> known to the proxy :). So the "right" solution consists in fixing the >>> proxy's schema. Of course, OpenLDAP could inform the proxy >>> administrator with some intelligible message or, even better, try to >>> repair itself (e.g. by checking the remote server's subschemaSubentry). >>> >> Probably not a good idea to do that automagically. Perhaps with a config >> switch. > > Right. I'll fix it. Actually... I think the original patch was fine. I meant, checking the remote server's subschema should be optional... ;) > >> Also, not a good idea to import miscellaneous foreign schema globally; >> we should implement per-database schema instead. > > I think per-database subschema has been on the todolist since ever or so :) And now we have another reason to do it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============2713755887385589149==-- From ando@sys-net.it Thu Sep 4 08:11:18 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5682) Undef objectClass soc_cname not NUL-terminated Date: Thu, 04 Sep 2008 08:11:18 +0000 Message-ID: <200809040811.m848BIcx071515@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0855136247439530559==" --===============0855136247439530559== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando The soc_cname of undefined objectClasses generated by oc_bvfind_undef() is not NUL-terminated. A recent commit, where a string-based function operated on it unvealed the issue. Fixing... p. --===============0855136247439530559==-- From ando@sys-net.it Thu Sep 4 08:15:14 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5682) Undef objectClass soc_cname not NUL-terminated Date: Thu, 04 Sep 2008 08:15:14 +0000 Message-ID: <200809040815.m848FEcs072698@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3408057978552875267==" --===============3408057978552875267== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ando(a)sys-net.it wrote: > The soc_cname of undefined objectClasses generated by oc_bvfind_undef() is = not > NUL-terminated. A recent commit, where a string-based function operated on= it > unvealed the issue. Fixing... For the records: spotted by valgrind. 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 ----------------------------------- --===============3408057978552875267==-- From ando@sys-net.it Thu Sep 4 08:41:18 2008 From: Pierangelo Masarati To: openldap-bugs@openldap.org Subject: Searching for (objectClass=UNDEFINED)... Date: Thu, 04 Sep 2008 10:41:11 +0200 Message-ID: <48BF9F27.6050903@sys-net.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8616841674912840072==" --===============8616841674912840072== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ... returns success with the text "value does not conform to assertion syntax"; is this the intended behavior, or should the filter error go completely unnoticed, and the text rather be logged, or what? The current behavior seems to be a consequence of servers/slapd/ava.c 1.45 -> 1.46 (by hyc) returning LDAP_SUCCESS instead of rc, without intentionally?) clearing text. 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 ----------------------------------- --===============8616841674912840072==-- From ando@sys-net.it Thu Sep 4 10:18:22 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5683) Don't leak syntax oid macro in case of duplicate attribute Date: Thu, 04 Sep 2008 10:18:21 +0000 Message-ID: <200809041018.m84AILFO079033@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8202971462592820994==" --===============8202971462592820994== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando p. --===============8202971462592820994==-- From rhafer@suse.de Thu Sep 4 10:31:35 2008 From: rhafer@suse.de To: openldap-bugs@openldap.org Subject: (ITS#5684) slapd crashes when adding entries do cn=config with a too large index Date: Thu, 04 Sep 2008 10:31:34 +0000 Message-ID: <200809041031.m84AVYRq080480@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8646111672734877230==" --===============8646111672734877230== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS:=20 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.240.108) slapd crashes when trying to add an indexed entry to cn=3Dconfig with an index larger than the number of sibling entries. E.g. when you have to entries below cn=3Dschema,cn=3Dconfig (with index {0} a= n {1}) and try to add cn=3D{3}myschema,cn=3Dschema,... slapd dumps core. I am currently testing a fix that just adjusts the index of the new entry to match the number of sibilings. (Another option would be to error out). --===============8646111672734877230==-- From hyc@symas.com Thu Sep 4 17:44:42 2008 From: Howard Chu To: openldap-bugs@openldap.org Subject: Re: Searching for (objectClass=UNDEFINED)... Date: Thu, 04 Sep 2008 10:41:19 -0700 Message-ID: <48C01DBF.6060704@symas.com> In-Reply-To: <48BF9F27.6050903@sys-net.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5478344405532071352==" --===============5478344405532071352== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Pierangelo Masarati wrote: > ... returns success with the text "value does not conform to assertion > syntax"; is this the intended behavior, or should the filter error go > completely unnoticed, and the text rather be logged, or what? > > The current behavior seems to be a consequence of > > servers/slapd/ava.c 1.45 -> 1.46 (by hyc) > > returning LDAP_SUCCESS instead of rc, without intentionally?) clearing text. Probably the text should be NULLed out. Illegal filters are supposed to be ignored; certainly no diagnostic should be sent back to any client. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5478344405532071352==-- From ghenry@suretecsystems.com Thu Sep 4 19:58:26 2008 From: ghenry@suretecsystems.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5545) Inconsistency in multi-master setup Date: Thu, 04 Sep 2008 19:58:26 +0000 Message-ID: <200809041958.m84JwQx1048861@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6487919696931990217==" --===============6487919696931990217== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ST(a)itsc.cuhk.edu.hk wrote: > Oops, I tested on both nodes, which is not supposed to do so in > mirrormode, right? Sorry for the trouble caused. > > Thanks. > > Not at the same time, no. The point is to have one node available to the clients at one time and the other in hot standby, whereby your network infrastructure redirects clients if one node goes down etc. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. --===============6487919696931990217==-- From Claude.lecommandeur@epfl.ch Fri Sep 5 09:03:05 2008 From: Claude.lecommandeur@epfl.ch To: openldap-bugs@openldap.org Subject: (ITS#5685) slapd segfault Date: Fri, 05 Sep 2008 09:03:04 +0000 Message-ID: <200809050903.m85934NG021989@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2455357165288743812==" --===============2455357165288743812== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Claude Lecommandeur Version: 2.2.13 OS: Redhat AS4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.178.1.102) Hi, slapd segfault on search with a very long filter. /var/log/nessages says : Sep 5 10:50:44 cognac5-mgr kernel: slapd[22263]: segfault at 0000002a978e2000 rip 0000002a96290746 rsp 00000000407ff290 error 6 gdb says : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082136928 (LWP 22263)] 0x0000002a96290746 in _IO_default_xsputn_internal () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000002a96290746 in _IO_default_xsputn_internal () from /lib64/tls/libc.so.6 #1 0x0000002a9626d06b in vfprintf () from /lib64/tls/libc.so.6 #2 0x0000002a9628c794 in vsnprintf () from /lib64/tls/libc.so.6 #3 0x0000002a962726b1 in snprintf () from /lib64/tls/libc.so.6 #4 0x000000552aadbd2e in filter2bv_x (op=0x2a99fc76a0, f=Variable "f" is not available. ) at ../../../servers/slapd/filter.c:852 #5 0x000000552aadbce2 in filter2bv_x (op=0x2a99fc76a0, f=Variable "f" is not available. ) at ../../../servers/slapd/filter.c:846 #6 0x000000552aad99e2 in do_search (op=0x2a99fc76a0, rs=0x40800d70) at ../../../servers/slapd/search.c:158 #7 0x000000552aad91b6 in connection_operation (ctx=0x40800e20, arg_v=0x2a99fc76a0) at ../../../servers/slapd/connection.c:1042 #8 0x000000552ab7f44b in ldap_int_thread_pool_wrapper (xpool=Variable "xpool" is not available. ) at ../../../libraries/libldap_r/tpool.c:467 #9 0x0000002a95f0e137 in start_thread () from /lib64/tls/libpthread.so.0 #10 0x0000002a962f3883 in clone () from /lib64/tls/libc.so.6 I am on holliday next week but will be happy to answer questions when I returns. Claude. --===============2455357165288743812==-- From ali.pouya@free.fr Fri Sep 5 12:23:05 2008 From: ali.pouya@free.fr To: openldap-bugs@openldap.org Subject: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror Date: Fri, 05 Sep 2008 12:23:05 +0000 Message-ID: <200809051223.m85CN5uU030232@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6859239607805726069==" --===============6859239607805726069== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Pierangelo Masarati wrote : > Well, going back to your initial posting, I think you are somehow=20 > correct. ... So I will use the simple configuration (only one syncrepl directive) for my p= roduction site.=20 ..... > I set up a test system with=20 > your configuration, and loaded it very heavily, while running the server=20 > that's supposed to screw up under valgrind. I haven't seen any issue=20 > yet, though. Neither me : When I run slapd with valgrind I cannot reproduce the problem ! Also if I run slap with detailed log I cannot reproduce it. Both cases slow down slapd ! Isn't this a problem of simultaneous (concurrent) access to the contextCSN me= mory zone ? I will be on vacation for two weeks. Thanks for your help. Best Regards Ali =20 --===============6859239607805726069==-- From michael@stroeder.com Fri Sep 5 14:22:22 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered Date: Fri, 05 Sep 2008 14:22:22 +0000 Message-ID: <200809051422.m85EMMdb038695@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3183320425794515831==" --===============3183320425794515831== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable mgwin(a)escp-eap.net wrote: > Replication of our ldap database often stops working, with pending changes > stacking up and not getting processed by slurpd. /var/lib/ldap/replog (as > configured in slapd.conf by the "replog" directive) fills up with entries, = and > slurpd doesn't pick up on them. 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. Ciao, Michael. --===============3183320425794515831==-- From brett.maxfield@gmail.com Fri Sep 5 14:42:13 2008 From: brett.maxfield@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5659) patch for collect overlay Date: Fri, 05 Sep 2008 14:42:13 +0000 Message-ID: <200809051442.m85EgDaL040080@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7359888987055376326==" --===============7359888987055376326== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit New patch provided, in ftp incoming/brett-maxfield-080906.patch which fixes a problem when virtual attributes of a child entry are written to. Previous patch does not deal with this consequence, and updates the parent entry instead (bad) New patch returns UnwillingToPerform with a meaningful text error, for virtual attributes on child entries, which is a better option. --===============7359888987055376326==-- From cwf-ml@arcor.de Fri Sep 5 15:37:32 2008 From: cwf-ml@arcor.de To: openldap-bugs@openldap.org Subject: (ITS#5686) OpenLDAP build broken for solaris 64bit Date: Fri, 05 Sep 2008 15:37:31 +0000 Message-ID: <200809051537.m85FbVxd042726@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5622877945241192127==" --===============5622877945241192127== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Christoph Weber-Fahr Version: openldap-2.4.11 OS: Solaris 9 (SunOS ldapsun 5.9 Generic_122300-06 sun4u sparc SUNW,Sun-Blad= e-100) URL:=20 Submission from: (NULL) (145.253.3.244) Machine has gcc (3.4.6) and gnu binutils from sunfreeware installed (plus a f= ew other things) I built Openssl and BerkeleyDB in 64bit mode. I then built openldap with the following commands: LD_LIBRARY_PATH=3D'/usr/local/lib/sparcv9:/usr/local/lib' export LD_LIBRARY_PATH sh configure \ --prefix=3D"/usr/local" \ --disable-ipv6 \ --without-threads \ --with-tls=3Dopenssl \ --without-cyrus-sasl \ CC=3D/usr/local/bin/gcc \ CPP=3D/usr/local/bin/cpp \ LDFLAGS=3D"-m64 -ldl" \ CFLAGS=3D"-m64 -I/usr/local/include -I/usr/local/ssl/include/openssl" make depend make make install All commands finish. But: - make test fails in test50 (core dump) - after installation each installed executable (including slapd) is larger th= an 8GB in size. None of them is executable on my machine - I get an immediate "Killed" from Solaris, presumably because the virtual memory is less than 8GB. The same executables in the build directory look just fine, slapd e.g. is ~2.= 8M ldapsun# [openldap-2.4.11] ll /usr/local/bin/lda* lrwxrwxrwx 1 root other 10 Sep 5 16:46 /usr/local/bin/ldapadd = -> ldapmodify* -rwxr-xr-x 1 root other 8591909768 Sep 5 16:46 /usr/local/bin/ldapcompare* -rwxr-xr-x 1 root other 8591911360 Sep 5 16:46 /usr/local/bin/ldapdelete* -rwxr-xr-x 1 root other 8591912304 Sep 5 16:46 /usr/local/bin/ldapexop* -rwxr-xr-x 1 root other 8591959528 Sep 5 16:46 /usr/local/bin/ldapmodify* -rwxr-xr-x 1 root other 8591909816 Sep 5 16:46 /usr/local/bin/ldapmodrdn* -rwxr-xr-x 1 root other 8591908712 Sep 5 16:46 /usr/local/bin/ldappasswd* -rwxr-xr-x 1 root other 8591987184 Sep 5 16:46 /usr/local/bin/ldapsearch* -rwxr-xr-x 1 root other 8591901960 Sep 5 16:46 /usr/local/bin/ldapwhoami* ldapsun# [openldap-2.4.11] ls -l clients/tools/lda* | /usr/xpg4/bin/grep -E -v '(\.o$|\.c$)' -rwxr-xr-x 1 root other 512280 Sep 5 16:40 clients/tools/ldapcompa= re -rwxr-xr-x 1 root other 513120 Sep 5 16:40 clients/tools/ldapdelete -rwxr-xr-x 1 root other 513600 Sep 5 16:40 clients/tools/ldapexop -rwxr-xr-x 1 root other 538960 Sep 5 16:40 clients/tools/ldapmodify -rwxr-xr-x 1 root other 512424 Sep 5 16:40 clients/tools/ldapmodrdn -rwxr-xr-x 1 root other 511568 Sep 5 16:40 clients/tools/ldappasswd -rwxr-xr-x 1 root other 553352 Sep 5 16:40 clients/tools/ldapsearch -rwxr-xr-x 1 root other 508240 Sep 5 16:40 clients/tools/ldapwhoami ldapsun# [openldap-2.4.11] ll /usr/local/libexec/slapd -rwxr-xr-x 1 root other 8596439592 Sep 5 16:46 /usr/local/libexec/slapd* ldapsun# [openldap-2.4.11] ll servers/slapd/slapd -rwxr-xr-x 1 root other 2896576 Sep 5 16:44 servers/slapd/slapd* Let me know if you need more info on this --===============5622877945241192127==-- From cwf-ml@arcor.de Fri Sep 5 15:49:16 2008 From: cwf-ml@arcor.de To: openldap-bugs@openldap.org Subject: Re: (ITS#5686) OpenLDAP build broken for solaris 64bit Date: Fri, 05 Sep 2008 15:49:15 +0000 Message-ID: <200809051549.m85FnF0B043146@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3938429622371407368==" --===============3938429622371407368== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit added info: here's what test Nr 50 shows: >>>>> ./scripts/test049-sync-config completed OK. >>>>> Starting test050-syncrepl-multimaster ... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... 8346 Abort - core dumped 8342 Abort - core dumped 8338 Abort - core dumped Using ldapadd to populate consumer... ldapadd failed for consumer database (255)! ./scripts/test050-syncrepl-multimaster: kill: no such process ./scripts/test050-syncrepl-multimaster: kill: no such process ./scripts/test050-syncrepl-multimaster: kill: no such process >>>>> ./scripts/test050-syncrepl-multimaster failed (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/usr/local/src/openldap-2.4.11/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/local/src/openldap-2.4.11/tests' make: *** [test] Error 2 --===============3938429622371407368==-- From quanah@zimbra.com Fri Sep 5 16:51:09 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5685) slapd segfault Date: Fri, 05 Sep 2008 16:51:08 +0000 Message-ID: <200809051651.m85Gp8PW048965@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8350024967657444790==" --===============8350024967657444790== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, September 05, 2008 9:03 AM +0000 Claude.lecommandeur(a)epfl.ch wrote: > Full_Name: Claude Lecommandeur > Version: 2.2.13 > OS: Redhat AS4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.178.1.102) Slurpd was deprecated with OpenLDAP 2.3, and removed from OpenLDAP 2.4, the current stable release. I advise upgrading to a current supported release. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============8350024967657444790==-- From quanah@zimbra.com Fri Sep 5 19:03:18 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: (ITS#5687) corrupted double-linked list on shutdown Date: Fri, 05 Sep 2008 19:03:17 +0000 Message-ID: <200809051903.m85J3HW1060382@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8509647386879863482==" --===============8509647386879863482== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Quanah Gibson-Mount Version: RE24 9/3/2008 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) While running make test, I killed test039, and on shutdown got: PID=3D10403 - Search(500): base=3D"o=3DExample,c=3DUS" scope=3Dsub filter=3D"= (cn=3DJames*)" attrs=3Dcn (more...).=20 make[2]: *** [hdb-mod] Interrupt=20 make[1]: *** [test] Interrupt=20 make: *** [test] Interrupt [quanah(a)tribes openldap-2.4.12]$ *** glibc detected *** corrupted double-li= nked list: 0x0000003bf99316b8 *** So it looks like there's a cleanup issue on shutdown. --===============8509647386879863482==-- From quanah@zimbra.com Fri Sep 5 19:10:12 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5686) OpenLDAP build broken for solaris 64bit Date: Fri, 05 Sep 2008 19:10:11 +0000 Message-ID: <200809051910.m85JABFe061849@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6857775626823554361==" --===============6857775626823554361== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, September 05, 2008 3:37 PM +0000 cwf-ml(a)arcor.de wrote: > Full_Name: Christoph Weber-Fahr > Version: openldap-2.4.11 > OS: Solaris 9 (SunOS ldapsun 5.9 Generic_122300-06 sun4u sparc > SUNW,Sun-Blade-100) URL: > Submission from: (NULL) (145.253.3.244) > > > Machine has gcc (3.4.6) and gnu binutils from sunfreeware installed (plus > a few other things) Sounds like a broken release of libtool to me. i.e., I don't see anything here that's an openldap specific issue. I'd advise examining your tool chain. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============6857775626823554361==-- From h.b.furuseth@usit.uio.no Fri Sep 5 19:23:56 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5686) OpenLDAP build broken for solaris 64bit Date: Fri, 05 Sep 2008 19:23:56 +0000 Message-ID: <200809051923.m85JNuTg063022@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2602993966859971120==" --===============2602993966859971120== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit quanah(a)zimbra.com writes: > Sounds like a broken release of libtool to me. i.e., I don't see > anything here that's an openldap specific issue. I'd advise examining > your tool chain. Hm? libtool is built from build/ltmain.sh + build/config.* bundled with OpenLDAP. And it's quite old. If that's failing, it needs an upgrade in OpenLDAP. I looked at it once but couldn't test a fresh libtool + autotools on more than one or two hosts. And the current installation uses some patches form the standar dlibtool distribution which I don't know what do. I don't remember what came of it. Anyway, it might be a fix to try libtoolize --copy --force aclocal autoconf with later versions of autotools (autoconf, automake, libtool). -- Hallvard --===============2602993966859971120==-- From quanah@zimbra.com Fri Sep 5 19:57:26 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Fri, 05 Sep 2008 19:57:25 +0000 Message-ID: <200809051957.m85JvPa0064703@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8885902720509494902==" --===============8885902720509494902== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --On Friday, September 05, 2008 7:03 PM +0000 quanah(a)zimbra.com wrote: With valgrind: [quanah(a)freelancer tests]$ *** glibc detected ***=20 /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted=20 double-linked list: 0x000000000d28a430 *** =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D /lib64/libc.so.6[0x38dc06cbb7] /lib64/libc.so.6[0x38dc06ee92] /lib64/libc.so.6(__libc_calloc+0x96)[0x38dc070376] /lib64/ld-linux-x86-64.so.2[0x38dbc09c85] /lib64/ld-linux-x86-64.so.2[0x38dbc05abc] /lib64/ld-linux-x86-64.so.2[0x38dbc07cac] /lib64/ld-linux-x86-64.so.2[0x38dbc1088f] /lib64/ld-linux-x86-64.so.2[0x38dbc0cc36] /lib64/ld-linux-x86-64.so.2[0x38dbc1036c] /lib64/libc.so.6[0x38dc101320] /lib64/ld-linux-x86-64.so.2[0x38dbc0cc36] /lib64/libc.so.6(__libc_dlopen_mode+0x47)[0x38dc101487] /lib64/libpthread.so.0[0x38dcc0e40c] /lib64/libpthread.so.0[0x38dcc0e520] /lib64/libpthread.so.0(__pthread_unwind+0x40)[0x38dcc0c430] /lib64/libpthread.so.0[0x38dcc07335] /home/quanah/q/openldap-2.4.12/libraries/libldap_r/.libs/libldap_r-2.4-releng= .so.2(ldap_pvt_thread_join+0x0)[0x2b537fec7e4a] /home/quanah/q/openldap-2.4.12/libraries/libldap_r/.libs/libldap_r-2.4-releng= .so.2[0x2b537fec6b9c] /lib64/libpthread.so.0[0x38dcc061b5] /lib64/libc.so.6(clone+0x6d)[0x38dc0cd36d] =3D=3D=3D=3D=3D=3D=3D Memory map: =3D=3D=3D=3D=3D=3D=3D=3D 00400000-00530000 r-xp 00000000 fd:00 32115271=20 /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd 00730000-00739000 rw-p 00130000 fd:00 32115271=20 /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd 00739000-0077d000 rw-p 00739000 00:00 0 0ce47000-0de31000 rw-p 0ce47000 00:00 0 40940000-40941000 ---p 40940000 00:00 0 40941000-41141000 rwxp 40941000 00:00 0 41141000-41142000 ---p 41141000 00:00 0 41142000-41942000 rwxp 41142000 00:00 0 41942000-41943000 ---p 41942000 00:00 0 41943000-42143000 rwxp 41943000 00:00 0 42143000-42144000 ---p 42143000 00:00 0 42144000-42944000 rwxp 42144000 00:00 0 42944000-42945000 ---p 42944000 00:00 0 42945000-43145000 rwxp 42945000 00:00 0 43145000-43146000 ---p 43145000 00:00 0 43146000-43946000 rwxp 43146000 00:00 0 43946000-43947000 ---p 43946000 00:00 0 43947000-44147000 rwxp 43947000 00:00 0 44147000-44148000 ---p 44147000 00:00 0 44148000-44948000 rwxp 44148000 00:00 0 44948000-44949000 ---p 44948000 00:00 0 44949000-45149000 rwxp 44949000 00:00 0 45149000-4514a000 ---p 45149000 00:00 0 4514a000-4594a000 rwxp 4514a000 00:00 0 4594a000-4594b000 ---p 4594a000 00:00 0 4594b000-4614b000 rwxp 4594b000 00:00 0 4614b000-4614c000 ---p 4614b000 00:00 0 4614c000-4694c000 rwxp 4614c000 00:00 0 4694c000-4694d000 ---p 4694c000 00:00 0 4694d000-4714d000 rwxp 4694d000 00:00 0 4714d000-4714e000 ---p 4714d000 00:00 0 4714e000-4794e000 rwxp 4714e000 00:00 0 4794e000-4794f000 ---p 4794e000 00:00 0 4794f000-4814f000 rwxp 4794f000 00:00 0 4814f000-48150000 ---p 4814f000 00:00 0 48150000-48950000 rwxp 48150000 00:00 0 48950000-48951000 ---p 48950000 00:00 0 48951000-49151000 rwxp 48951000 00:00 0 38dbc00000-38dbc1a000 r-xp 00000000 fd:00 12026130=20 /lib64/ld-2.5.so 38dbe19000-38dbe1a000 r--p 00019000 fd:00 12026130=20 /lib64/ld-2.5.so 38dbe1a000-38dbe1b000 rw-p 0001a000 fd:00 12026130=20 /lib64/ld-2.5.so 38dc000000-38dc144000 r-xp 00000000 fd:00 12026131=20 /lib64/libc-2.5.so 38dc144000-38dc344000 ---p 00144000 fd:00 12026131=20 /lib64/libc-2.5.so 38dc344000-38dc348000 r--p 00144000 fd:00 12026131=20 /lib64/libc-2.5.so 38dc348000-38dc349000 rw-p 00148000 fd:00 12026131=20 /lib64/libc-2.5.so 38dc349000-38dc34e000 rw-p 38dc349000 00:00 0 38dc400000-38dc402000 r-xp 00000000 fd:00 12026132=20 /lib64/libdl-2.5.so 38dc402000-38dc602000 ---p 00002000 fd:00 12026132=20 /lib64/libdl-2.5.so 38dc602000-38dc603000 r--p 00002000 fd:00 12026132=20 /lib64/libdl-2.5.so 38dc603000-38dc604000 rw-p 00003000 fd:00 12026132=20 /lib64/libdl-2.5.so 38dcc00000-38dcc15000 r-xp 00000000 fd:00 12026136 Core was generated by=20 `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f=20 /home/quanah'. Program terminated with signal 6, Aborted. #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 #1 0x00000038dc031980 in abort () from /lib64/libc.so.6 #2 0x00000038dc0674cb in __libc_message () from /lib64/libc.so.6 #3 0x00000038dc06cbb7 in malloc_consolidate () from /lib64/libc.so.6 #4 0x00000038dc06ee92 in _int_malloc () from /lib64/libc.so.6 #5 0x00000038dc070376 in calloc () from /lib64/libc.so.6 #6 0x00000038dbc09c85 in _dl_new_object () from /lib64/ld-linux-x86-64.so.2 #7 0x00000038dbc05abc in _dl_map_object_from_fd () from=20 /lib64/ld-linux-x86-64.so.2 #8 0x00000038dbc07cac in _dl_map_object () from /lib64/ld-linux-x86-64.so.2 #9 0x00000038dbc1088f in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #10 0x00000038dbc0cc36 in _dl_catch_error () from=20 /lib64/ld-linux-x86-64.so.2 #11 0x00000038dbc1036c in _dl_open () from /lib64/ld-linux-x86-64.so.2 #12 0x00000038dc101320 in do_dlopen () from /lib64/libc.so.6 #13 0x00000038dbc0cc36 in _dl_catch_error () from=20 /lib64/ld-linux-x86-64.so.2 #14 0x00000038dc101487 in __libc_dlopen_mode () from /lib64/libc.so.6 #15 0x00000038dcc0e40c in pthread_cancel_init () from /lib64/libpthread.so.0 #16 0x00000038dcc0e520 in _Unwind_ForcedUnwind () from=20 /lib64/libpthread.so.0 #17 0x00000038dcc0c430 in __pthread_unwind () from /lib64/libpthread.so.0 #18 0x00000038dcc07335 in pthread_exit () from /lib64/libpthread.so.0 #19 0x00002b537fec7e4a in ldap_pvt_thread_exit (retval=3D0x0) at=20 thr_posix.c:186 #20 0x00002b537fec6b9c in ldap_int_thread_pool_wrapper (xpool=3D0xce75610) at= =20 tpool.c:691 #21 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #22 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #23 0x0000000000000000 in ?? () -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============8885902720509494902==-- From h.b.furuseth@usit.uio.no Fri Sep 5 20:52:16 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Fri, 05 Sep 2008 20:52:16 +0000 Message-ID: <200809052052.m85KqGY6067497@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0652839289965146672==" --===============0652839289965146672== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > [quanah(a)freelancer tests]$ *** glibc detected *** > /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted > double-linked list: 0x000000000d28a430 *** This message comes from glibc malloc. Its data structures are corrupted. I couldn't figure out much from the the valgrind output. But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, if that code isn't rotted - maybe that'll bring out the problem in another guise. If that code still works, I don't remember. -- Hallvard --===============0652839289965146672==-- From hyc@symas.com Fri Sep 5 21:01:41 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Fri, 05 Sep 2008 21:01:40 +0000 Message-ID: <200809052101.m85L1eHP068492@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6552462637162325265==" --===============6552462637162325265== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable h.b.furuseth(a)usit.uio.no wrote: >> [quanah(a)freelancer tests]$ *** glibc detected *** >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >> double-linked list: 0x000000000d28a430 *** > > This message comes from glibc malloc. Its data structures are > corrupted. Right. But ordinarily, valgrind intercepts all mallocs and as such, any=20 corruption should have been detected first by valgrind. The fact that valgrin= d=20 didn't complain implies either a bug in valgrind or a bug in glibc. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6552462637162325265==-- From quanah@zimbra.com Fri Sep 5 21:14:54 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Fri, 05 Sep 2008 21:14:53 +0000 Message-ID: <200809052114.m85LErkZ069372@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2792476358424671478==" --===============2792476358424671478== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, September 05, 2008 8:52 PM +0000 h.b.furuseth(a)usit.uio.no wrote: >> [quanah(a)freelancer tests]$ *** glibc detected *** >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >> double-linked list: 0x000000000d28a430 *** > > This message comes from glibc malloc. Its data structures are > corrupted. > > I couldn't figure out much from the the valgrind output. > But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, > if that code isn't rotted - maybe that'll bring out the problem in > another guise. If that code still works, I don't remember. More notes: I get a core file every time I kill test039, even at stages outside the search. I only get the glibc error some of the time. Even testing with the latest and greatest valgrind, I don't see anything in its output file. I've managed to reproduce this behavior on both CentOS5 (64-bit) and RHEL4 (64-bit), which are running different kernels (and I assume glibc versions). backtrace on a non-glibc fault core: Core was generated by `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f /home/quanah'. Program terminated with signal 11, Segmentation fault. #0 0x00000038dc06ca17 in malloc_consolidate () from /lib64/libc.so.6 (gdb) bt #0 0x00000038dc06ca17 in malloc_consolidate () from /lib64/libc.so.6 #1 0x00000038dc06e607 in _int_free () from /lib64/libc.so.6 #2 0x00000038dc071fac in free () from /lib64/libc.so.6 #3 0x00002ae61bf34732 in ber_memfree_x (p=0x7302670, ctx=0x0) at memory.c:152 #4 0x000000000049d882 in slap_sl_mem_destroy (key=0x49da46, data=0x7302630) at sl_malloc.c:41 #5 0x00002ae61bce35c2 in ldap_pvt_thread_pool_context_reset (vctx=0x46da1dd0) at tpool.c:943 #6 0x00002ae61bce2a8a in ldap_int_thread_pool_wrapper (xpool=0x688e610) at tpool.c:677 #7 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #8 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? () -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============2792476358424671478==-- From ando@sys-net.it Fri Sep 5 21:47:44 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5688) slapd returns success with message when an undefined objectClass is used in filter Date: Fri, 05 Sep 2008 21:47:44 +0000 Message-ID: <200809052147.m85Lli0g070851@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3465467868120000810==" --===============3465467868120000810== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See discussion here: . A fix is coming. p. --===============3465467868120000810==-- From h.b.furuseth@usit.uio.no Fri Sep 5 22:02:10 2008 From: Hallvard B Furuseth To: openldap-bugs@openldap.org Subject: Re: Searching for (objectClass=UNDEFINED)... Date: Sat, 06 Sep 2008 00:01:57 +0200 Message-ID: In-Reply-To: <48C01DBF.6060704@symas.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0931804921075973253==" --===============0931804921075973253== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Howard Chu wrote: > Illegal filters are supposed to be ignored; certainly no diagnostic > should be sent back to any client. Well... I think _illegal_ filters should get a protocolError. OTOH filtering for unrecognized schema should get no error or diagnostic, the filter component just evaluates to Undefined (like False, except Not(Undefined) = Undefined). -- Hallvard --===============0931804921075973253==-- From ando@sys-net.it Fri Sep 5 22:06:11 2008 From: Pierangelo Masarati To: openldap-bugs@openldap.org Subject: Re: Searching for (objectClass=UNDEFINED)... Date: Sat, 06 Sep 2008 01:05:47 +0200 Message-ID: <48C1BB4B.9010203@sys-net.it> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3618702709096515707==" --===============3618702709096515707== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hallvard B Furuseth wrote: > Howard Chu wrote: >> Illegal filters are supposed to be ignored; certainly no diagnostic >> should be sent back to any client. > > Well... I think _illegal_ filters should get a protocolError. :) > OTOH filtering for unrecognized schema should get no error or > diagnostic, the filter component just evaluates to Undefined (like > False, except Not(Undefined) = Undefined). Yes. But nothing prevents success from being accompanied by further informative info in the diagnosticMessage field. That's why I asked first. I concur the filter above qualifies as undefined, and should be treated much like other undefined filters. Already fixed in HEAD (ITS#5688). 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 ----------------------------------- --===============3618702709096515707==-- From hyc@symas.com Fri Sep 5 22:11:14 2008 From: Howard Chu To: openldap-bugs@openldap.org Subject: Re: Searching for (objectClass=UNDEFINED)... Date: Fri, 05 Sep 2008 15:10:58 -0700 Message-ID: <48C1AE72.7080501@symas.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5155983607908089686==" --===============5155983607908089686== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hallvard B Furuseth wrote: > Howard Chu wrote: >> Illegal filters are supposed to be ignored; certainly no diagnostic >> should be sent back to any client. > > Well... I think _illegal_ filters should get a protocolError. > > OTOH filtering for unrecognized schema should get no error or > diagnostic, the filter component just evaluates to Undefined (like > False, except Not(Undefined) = Undefined). OK right, that's what we were really talking about here anyway. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5155983607908089686==-- From ando@sys-net.it Fri Sep 5 22:41:39 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Fri, 05 Sep 2008 22:41:39 +0000 Message-ID: <200809052241.m85Mfdxr075050@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1598599570292978666==" --===============1598599570292978666== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable h.b.furuseth(a)usit.uio.no wrote: >> [quanah(a)freelancer tests]$ *** glibc detected ***=20 >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted=20 >> double-linked list: 0x000000000d28a430 *** >=20 > This message comes from glibc malloc. Its data structures are > corrupted. >=20 > I couldn't figure out much from the the valgrind output. > But you'll get more frequent mallocs with CPPFLAGS=3D-DSLAP_NO_SL_MALLOC, > if that code isn't rotted - maybe that'll bring out the problem in > another guise. If that code still works, I don't remember. Here's my output after compiling with -DSLAP_NO_SL_MALLOC=3D1, running=20 test039 under valgrind and suddenly killing the process: =3D=3D9657=3D=3D Memcheck, a memory error detector. =3D=3D9657=3D=3D Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et = al. =3D=3D9657=3D=3D Using LibVEX rev 1658, a library for dynamic binary translat= ion. =3D=3D9657=3D=3D Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. =3D=3D9657=3D=3D Using valgrind-3.2.1, a dynamic binary instrumentation frame= work. =3D=3D9657=3D=3D Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et = al. =3D=3D9657=3D=3D For more details, rerun with: -v =3D=3D9657=3D=3D @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ masarati(a)odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap-dev= el/servers/slapd slapd starting daemon: shutdown requested and initiated. slapd shutdown: waiting for 8 threads to terminate =3D=3D9657=3D=3D Thread 3: =3D=3D9657=3D=3D Invalid read of size 4 =3D=3D9657=3D=3D at 0x807EF03: slap_listener (daemon.c:1754) =3D=3D9657=3D=3D by 0x807F9AC: slap_listener_thread (daemon.c:1997) =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) =3D=3D9657=3D=3D Address 0x415D3A8 is 32 bytes inside a block of size 164 fr= ee'd =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) =3D=3D9657=3D=3D by 0x807EDF8: close_listeners (daemon.c:1703) =3D=3D9657=3D=3D by 0x808137F: slapd_daemon_task (daemon.c:2578) =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) =3D=3D9657=3D=3D =3D=3D9657=3D=3D Invalid write of size 4 =3D=3D9657=3D=3D at 0x807EF22: slap_listener (daemon.c:1759) =3D=3D9657=3D=3D by 0x807F9AC: slap_listener_thread (daemon.c:1997) =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) =3D=3D9657=3D=3D Address 0x415D3A4 is 28 bytes inside a block of size 164 fr= ee'd =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) =3D=3D9657=3D=3D by 0x807EDF8: close_listeners (daemon.c:1703) =3D=3D9657=3D=3D by 0x808137F: slapd_daemon_task (daemon.c:2578) =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) =3D=3D9657=3D=3D =3D=3D9657=3D=3D Invalid read of size 4 =3D=3D9657=3D=3D at 0x807EFCD: slap_listener (daemon.c:1781) =3D=3D9657=3D=3D by 0x807F9AC: slap_listener_thread (daemon.c:1997) =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) =3D=3D9657=3D=3D Address 0x415D3A8 is 32 bytes inside a block of size 164 fr= ee'd =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) =3D=3D9657=3D=3D by 0x807EDF8: close_listeners (daemon.c:1703) =3D=3D9657=3D=3D by 0x808137F: slapd_daemon_task (daemon.c:2578) =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) daemon: accept(7) failed errno=3D9 (Bad file descriptor) =3D=3D9657=3D=3D =3D=3D9657=3D=3D Thread 5: =3D=3D9657=3D=3D Invalid free() / delete / delete[] =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) =3D=3D9657=3D=3D by 0x80E522B: slap_sl_free (sl_malloc.c:451) =3D=3D9657=3D=3D by 0x80874AF: do_search (search.c:221) =3D=3D9657=3D=3D by 0x8084347: connection_operation (connection.c:1084) =3D=3D9657=3D=3D by 0x8084834: connection_read_thread (connection.c:1211) =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) =3D=3D9657=3D=3D Address 0x5595D60 is 0 bytes inside a block of size 29 free= 'd =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) =3D=3D9657=3D=3D by 0x81E1D64: rwm_op_cleanup (rwm.c:64) =3D=3D9657=3D=3D by 0x80976CD: slap_cleanup_play (result.c:341) =3D=3D9657=3D=3D by 0x8097DEA: send_ldap_response (result.c:522) =3D=3D9657=3D=3D by 0x809850E: slap_send_ldap_result (result.c:642) =3D=3D9657=3D=3D by 0x81855CE: ldap_back_op_result (bind.c:1823) =3D=3D9657=3D=3D by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) =3D=3D9657=3D=3D by 0x8184D41: ldap_back_dobind (bind.c:1520) =3D=3D9657=3D=3D by 0x812C9F7: ldap_back_search (search.c:174) =3D=3D9657=3D=3D by 0x80F7DF4: glue_sub_search (backglue.c:340) =3D=3D9657=3D=3D by 0x80F8458: glue_op_search (backglue.c:467) =3D=3D9657=3D=3D by 0x80FACE3: overlay_op_walk (backover.c:657) =3D=3D9657=3D=3D by 0x80FAF18: over_op_func (backover.c:719) =3D=3D9657=3D=3D by 0x80FAF9C: over_op_search (backover.c:741) =3D=3D9657=3D=3D by 0x8087ADB: fe_op_search (search.c:366) =3D=3D9657=3D=3D by 0x80FAD63: overlay_op_walk (backover.c:667) =3D=3D9657=3D=3D by 0x80FAF18: over_op_func (backover.c:719) =3D=3D9657=3D=3D by 0x80FAF9C: over_op_search (backover.c:741) =3D=3D9657=3D=3D =3D=3D9657=3D=3D Invalid free() / delete / delete[] =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) =3D=3D9657=3D=3D by 0x80E522B: slap_sl_free (sl_malloc.c:451) =3D=3D9657=3D=3D by 0x80874D3: do_search (search.c:224) =3D=3D9657=3D=3D by 0x8084347: connection_operation (connection.c:1084) =3D=3D9657=3D=3D by 0x8084834: connection_read_thread (connection.c:1211) =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) =3D=3D9657=3D=3D Address 0x5595E60 is 0 bytes inside a block of size 29 free= 'd =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) =3D=3D9657=3D=3D by 0x81E1D90: rwm_op_cleanup (rwm.c:69) =3D=3D9657=3D=3D by 0x80976CD: slap_cleanup_play (result.c:341) =3D=3D9657=3D=3D by 0x8097DEA: send_ldap_response (result.c:522) =3D=3D9657=3D=3D by 0x809850E: slap_send_ldap_result (result.c:642) =3D=3D9657=3D=3D by 0x81855CE: ldap_back_op_result (bind.c:1823) =3D=3D9657=3D=3D by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) =3D=3D9657=3D=3D by 0x8184D41: ldap_back_dobind (bind.c:1520) =3D=3D9657=3D=3D by 0x812C9F7: ldap_back_search (search.c:174) =3D=3D9657=3D=3D by 0x80F7DF4: glue_sub_search (backglue.c:340) =3D=3D9657=3D=3D by 0x80F8458: glue_op_search (backglue.c:467) =3D=3D9657=3D=3D by 0x80FACE3: overlay_op_walk (backover.c:657) =3D=3D9657=3D=3D by 0x80FAF18: over_op_func (backover.c:719) =3D=3D9657=3D=3D by 0x80FAF9C: over_op_search (backover.c:741) =3D=3D9657=3D=3D by 0x8087ADB: fe_op_search (search.c:366) =3D=3D9657=3D=3D by 0x80FAD63: overlay_op_walk (backover.c:667) =3D=3D9657=3D=3D by 0x80FAF18: over_op_func (backover.c:719) =3D=3D9657=3D=3D by 0x80FAF9C: over_op_search (backover.c:741) conn=3D3 op=3D1 ldap_back_retry: retrying URI=3D"ldap://localhost:9011"=20 DN=3D"cn=3Dmanager,dc=3Dexample,dc=3Dcom" =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() slapd stopped. =3D=3D9657=3D=3D =3D=3D9657=3D=3D ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from= 1) =3D=3D9657=3D=3D malloc/free: in use at exit: 1,127 bytes in 15 blocks. =3D=3D9657=3D=3D malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes=20 allocated. =3D=3D9657=3D=3D For counts of detected errors, rerun with: -v =3D=3D9657=3D=3D searching for pointers to 15 not-freed blocks. =3D=3D9657=3D=3D checked 774,072 bytes. Apparently, the listener is freed while some thread is still using it. 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 ----------------------------------- --===============1598599570292978666==-- From Kurt@OpenLDAP.org Fri Sep 5 22:45:59 2008 From: Kurt Zeilenga To: openldap-bugs@openldap.org Subject: Re: Searching for (objectClass=UNDEFINED)... Date: Fri, 05 Sep 2008 15:44:51 -0700 Message-ID: <3B75E67A-0563-4658-A741-9E87121D46C3@OpenLDAP.org> In-Reply-To: <48C1BB4B.9010203@sys-net.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8872220978763928351==" --===============8872220978763928351== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sep 5, 2008, at 4:05 PM, Pierangelo Masarati wrote: >> >> OTOH filtering for unrecognized schema should get no error or >> diagnostic, the filter component just evaluates to Undefined (like >> False, except Not(Undefined) = Undefined). > > Yes. But nothing prevents success from being accompanied by further > informative info in the diagnosticMessage field. Correct. IIRC, there being at least a few of cases where we intentionally provide a diagnosticMessage with success. Whether this is one of those intentional cases or not, well, I'm not sure but I vaguely recall something about this one. > That's why I asked first. I concur the filter above qualifies as > undefined, and should be treated much like other undefined filters. > Already fixed in HEAD (ITS#5688). --===============8872220978763928351==-- From michael@stroeder.com Fri Sep 5 23:22:03 2008 From: Michael =?utf-8?q?Str=C3=B6der?= To: openldap-bugs@openldap.org Subject: Re: Searching for (objectClass=UNDEFINED)... Date: Sat, 06 Sep 2008 01:21:14 +0200 Message-ID: <48C1BEEA.1090303@stroeder.com> In-Reply-To: <48C1AE72.7080501@symas.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6314359981314534641==" --===============6314359981314534641== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Howard Chu wrote: > Hallvard B Furuseth wrote: >> Howard Chu wrote: >>> Illegal filters are supposed to be ignored; certainly no diagnostic >>> should be sent back to any client. >> >> Well... I think _illegal_ filters should get a protocolError. >> >> OTOH filtering for unrecognized schema should get no error or >> diagnostic, the filter component just evaluates to Undefined (like >> False, except Not(Undefined) = Undefined). > > OK right, that's what we were really talking about here anyway. I'd also appreciate if (objectClass=UNDEFINED) does not lead to protocolError or another LDAP error being returned instead of success. Ciao, Michael. --===============6314359981314534641==-- From hyc@symas.com Fri Sep 5 23:49:53 2008 From: Howard Chu To: openldap-bugs@openldap.org Subject: Re: Searching for (objectClass=UNDEFINED)... Date: Fri, 05 Sep 2008 16:49:36 -0700 Message-ID: <48C1C590.8040407@symas.com> In-Reply-To: <48C1BEEA.1090303@stroeder.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6349666054765742878==" --===============6349666054765742878== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Michael Ströder wrote: > I'd also appreciate if (objectClass=UNDEFINED) does not lead to > protocolError or another LDAP error being returned instead of success. Don't worry, it won't. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6349666054765742878==-- From hyc@symas.com Fri Sep 5 23:52:24 2008 From: Howard Chu To: openldap-bugs@openldap.org Subject: Re: Searching for (objectClass=UNDEFINED)... Date: Fri, 05 Sep 2008 16:52:07 -0700 Message-ID: <48C1C627.30309@symas.com> In-Reply-To: <3B75E67A-0563-4658-A741-9E87121D46C3@OpenLDAP.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5230416251139464311==" --===============5230416251139464311== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: > On Sep 5, 2008, at 4:05 PM, Pierangelo Masarati wrote: > >>> OTOH filtering for unrecognized schema should get no error or >>> diagnostic, the filter component just evaluates to Undefined (like >>> False, except Not(Undefined) =3D Undefined). >> Yes. But nothing prevents success from being accompanied by further >> informative info in the diagnosticMessage field. > > Correct. IIRC, there being at least a few of cases where we > intentionally provide a diagnosticMessage with success. Whether this > is one of those intentional cases or not, well, I'm not sure but I > vaguely recall something about this one. If that was the desire, it wasn't very effective. E.g., if there were multipl= e=20 problems with a filter only the last message would have been returned. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5230416251139464311==-- From hyc@symas.com Sat Sep 6 00:08:25 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 00:08:24 +0000 Message-ID: <200809060008.m8608OnS081174@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8854082025361762817==" --===============8854082025361762817== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >>> [quanah(a)freelancer tests]$ *** glibc detected *** >>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>> double-linked list: 0x000000000d28a430 *** >> This message comes from glibc malloc. Its data structures are >> corrupted. >> >> I couldn't figure out much from the the valgrind output. >> But you'll get more frequent mallocs with CPPFLAGS=3D-DSLAP_NO_SL_MALLOC, >> if that code isn't rotted - maybe that'll bring out the problem in >> another guise. If that code still works, I don't remember. > > Here's my output after compiling with -DSLAP_NO_SL_MALLOC=3D1, running > test039 under valgrind and suddenly killing the process: > > =3D=3D9657=3D=3D Memcheck, a memory error detector. > =3D=3D9657=3D=3D Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward e= t al. > =3D=3D9657=3D=3D Using LibVEX rev 1658, a library for dynamic binary transl= ation. > =3D=3D9657=3D=3D Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > =3D=3D9657=3D=3D Using valgrind-3.2.1, a dynamic binary instrumentation fra= mework. > =3D=3D9657=3D=3D Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward e= t al. > =3D=3D9657=3D=3D For more details, rerun with: -v > =3D=3D9657=3D=3D > @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ > masarati(a)odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap-d= evel/servers/slapd > slapd starting > daemon: shutdown requested and initiated. > slapd shutdown: waiting for 8 threads to terminate > =3D=3D9657=3D=3D Thread 3: > =3D=3D9657=3D=3D Invalid read of size 4 > =3D=3D9657=3D=3D at 0x807EF03: slap_listener (daemon.c:1754) > =3D=3D9657=3D=3D by 0x807F9AC: slap_listener_thread (daemon.c:1997) > =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) > =3D=3D9657=3D=3D Address 0x415D3A8 is 32 bytes inside a block of size 164 = free'd > =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) > =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) > =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) > =3D=3D9657=3D=3D by 0x807EDF8: close_listeners (daemon.c:1703) > =3D=3D9657=3D=3D by 0x808137F: slapd_daemon_task (daemon.c:2578) > =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) > =3D=3D9657=3D=3D > =3D=3D9657=3D=3D Invalid write of size 4 > =3D=3D9657=3D=3D at 0x807EF22: slap_listener (daemon.c:1759) > =3D=3D9657=3D=3D by 0x807F9AC: slap_listener_thread (daemon.c:1997) > =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) > =3D=3D9657=3D=3D Address 0x415D3A4 is 28 bytes inside a block of size 164 = free'd > =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) > =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) > =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) > =3D=3D9657=3D=3D by 0x807EDF8: close_listeners (daemon.c:1703) > =3D=3D9657=3D=3D by 0x808137F: slapd_daemon_task (daemon.c:2578) > =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) > =3D=3D9657=3D=3D > =3D=3D9657=3D=3D Invalid read of size 4 > =3D=3D9657=3D=3D at 0x807EFCD: slap_listener (daemon.c:1781) > =3D=3D9657=3D=3D by 0x807F9AC: slap_listener_thread (daemon.c:1997) > =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) > =3D=3D9657=3D=3D Address 0x415D3A8 is 32 bytes inside a block of size 164 = free'd > =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) > =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) > =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) > =3D=3D9657=3D=3D by 0x807EDF8: close_listeners (daemon.c:1703) > =3D=3D9657=3D=3D by 0x808137F: slapd_daemon_task (daemon.c:2578) > =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) > daemon: accept(7) failed errno=3D9 (Bad file descriptor) > =3D=3D9657=3D=3D > =3D=3D9657=3D=3D Thread 5: > =3D=3D9657=3D=3D Invalid free() / delete / delete[] > =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) > =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) > =3D=3D9657=3D=3D by 0x80E522B: slap_sl_free (sl_malloc.c:451) > =3D=3D9657=3D=3D by 0x80874AF: do_search (search.c:221) > =3D=3D9657=3D=3D by 0x8084347: connection_operation (connection.c:1084) > =3D=3D9657=3D=3D by 0x8084834: connection_read_thread (connection.c:1211) > =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) > =3D=3D9657=3D=3D Address 0x5595D60 is 0 bytes inside a block of size 29 fr= ee'd > =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) > =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) > =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) > =3D=3D9657=3D=3D by 0x81E1D64: rwm_op_cleanup (rwm.c:64) > =3D=3D9657=3D=3D by 0x80976CD: slap_cleanup_play (result.c:341) > =3D=3D9657=3D=3D by 0x8097DEA: send_ldap_response (result.c:522) > =3D=3D9657=3D=3D by 0x809850E: slap_send_ldap_result (result.c:642) > =3D=3D9657=3D=3D by 0x81855CE: ldap_back_op_result (bind.c:1823) > =3D=3D9657=3D=3D by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) > =3D=3D9657=3D=3D by 0x8184D41: ldap_back_dobind (bind.c:1520) > =3D=3D9657=3D=3D by 0x812C9F7: ldap_back_search (search.c:174) > =3D=3D9657=3D=3D by 0x80F7DF4: glue_sub_search (backglue.c:340) > =3D=3D9657=3D=3D by 0x80F8458: glue_op_search (backglue.c:467) > =3D=3D9657=3D=3D by 0x80FACE3: overlay_op_walk (backover.c:657) > =3D=3D9657=3D=3D by 0x80FAF18: over_op_func (backover.c:719) > =3D=3D9657=3D=3D by 0x80FAF9C: over_op_search (backover.c:741) > =3D=3D9657=3D=3D by 0x8087ADB: fe_op_search (search.c:366) > =3D=3D9657=3D=3D by 0x80FAD63: overlay_op_walk (backover.c:667) > =3D=3D9657=3D=3D by 0x80FAF18: over_op_func (backover.c:719) > =3D=3D9657=3D=3D by 0x80FAF9C: over_op_search (backover.c:741) > =3D=3D9657=3D=3D > =3D=3D9657=3D=3D Invalid free() / delete / delete[] > =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) > =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) > =3D=3D9657=3D=3D by 0x80E522B: slap_sl_free (sl_malloc.c:451) > =3D=3D9657=3D=3D by 0x80874D3: do_search (search.c:224) > =3D=3D9657=3D=3D by 0x8084347: connection_operation (connection.c:1084) > =3D=3D9657=3D=3D by 0x8084834: connection_read_thread (connection.c:1211) > =3D=3D9657=3D=3D by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > =3D=3D9657=3D=3D by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > =3D=3D9657=3D=3D by 0xD42DBD: clone (in /lib/libc-2.5.so) > =3D=3D9657=3D=3D Address 0x5595E60 is 0 bytes inside a block of size 29 fr= ee'd > =3D=3D9657=3D=3D at 0x4004FDA: free (vg_replace_malloc.c:233) > =3D=3D9657=3D=3D by 0x82407C9: ber_memfree_x (memory.c:152) > =3D=3D9657=3D=3D by 0x80A59E5: ch_free (ch_malloc.c:139) > =3D=3D9657=3D=3D by 0x81E1D90: rwm_op_cleanup (rwm.c:69) > =3D=3D9657=3D=3D by 0x80976CD: slap_cleanup_play (result.c:341) > =3D=3D9657=3D=3D by 0x8097DEA: send_ldap_response (result.c:522) > =3D=3D9657=3D=3D by 0x809850E: slap_send_ldap_result (result.c:642) > =3D=3D9657=3D=3D by 0x81855CE: ldap_back_op_result (bind.c:1823) > =3D=3D9657=3D=3D by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) > =3D=3D9657=3D=3D by 0x8184D41: ldap_back_dobind (bind.c:1520) > =3D=3D9657=3D=3D by 0x812C9F7: ldap_back_search (search.c:174) > =3D=3D9657=3D=3D by 0x80F7DF4: glue_sub_search (backglue.c:340) > =3D=3D9657=3D=3D by 0x80F8458: glue_op_search (backglue.c:467) > =3D=3D9657=3D=3D by 0x80FACE3: overlay_op_walk (backover.c:657) > =3D=3D9657=3D=3D by 0x80FAF18: over_op_func (backover.c:719) > =3D=3D9657=3D=3D by 0x80FAF9C: over_op_search (backover.c:741) > =3D=3D9657=3D=3D by 0x8087ADB: fe_op_search (search.c:366) > =3D=3D9657=3D=3D by 0x80FAD63: overlay_op_walk (backover.c:667) > =3D=3D9657=3D=3D by 0x80FAF18: over_op_func (backover.c:719) > =3D=3D9657=3D=3D by 0x80FAF9C: over_op_search (backover.c:741) > conn=3D3 op=3D1 ldap_back_retry: retrying URI=3D"ldap://localhost:9011" > DN=3D"cn=3Dmanager,dc=3Dexample,dc=3Dcom" > =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() > =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() > =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() > =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() > =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() > =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() > =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() > =3D=3D9657=3D=3D Warning: invalid file descriptor -1 in syscall close() > slapd stopped. > =3D=3D9657=3D=3D > =3D=3D9657=3D=3D ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 fr= om 1) > =3D=3D9657=3D=3D malloc/free: in use at exit: 1,127 bytes in 15 blocks. > =3D=3D9657=3D=3D malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes > allocated. > =3D=3D9657=3D=3D For counts of detected errors, rerun with: -v > =3D=3D9657=3D=3D searching for pointers to 15 not-freed blocks. > =3D=3D9657=3D=3D checked 774,072 bytes. > > Apparently, the listener is freed while some thread is still using it. Since that can only occur during shutdown, I don't think it's really a high=20 priority problem. More to the point, it will not cause any heap corruption.=20 The serious problem is in thread 5, where rwm_op_cleanup frees a DN that=20 do_search also tries to free. It looks like rwm_op_cleanup is badly broken=20 here, it apparently should be checking to make sure ros->ro_dn is !=3D ros->r= _dn=20 before freeing r_dn (and ndn). --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============8854082025361762817==-- From quanah@zimbra.com Sat Sep 6 01:12:36 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 01:12:36 +0000 Message-ID: <200809060112.m861CaEE086607@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2061075971922438651==" --===============2061075971922438651== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Saturday, September 06, 2008 12:08 AM +0000 hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>>> [quanah(a)freelancer tests]$ *** glibc detected *** >>>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>>> double-linked list: 0x000000000d28a430 *** >>> This message comes from glibc malloc. Its data structures are >>> corrupted. >>> >>> I couldn't figure out much from the the valgrind output. >>> But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, >>> if that code isn't rotted - maybe that'll bring out the problem in >>> another guise. If that code still works, I don't remember. >> >> Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running >> test039 under valgrind and suddenly killing the process: >> >> ==9657== Memcheck, a memory error detector. >> ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. >> ==9657== Using LibVEX rev 1658, a library for dynamic binary translation. >> ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. >> ==9657== Using valgrind-3.2.1, a dynamic binary instrumentation >> framework. ==9657== Copyright (C) 2000-2006, and GNU GPL'd, by Julian >> Seward et al. ==9657== For more details, rerun with: -v >> ==9657== >> @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ >> masarati(a)odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap- >> devel/servers/slapd slapd starting >> daemon: shutdown requested and initiated. >> slapd shutdown: waiting for 8 threads to terminate >> ==9657== Thread 3: >> ==9657== Invalid read of size 4 >> ==9657== at 0x807EF03: slap_listener (daemon.c:1754) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== >> ==9657== Invalid write of size 4 >> ==9657== at 0x807EF22: slap_listener (daemon.c:1759) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== >> ==9657== Invalid read of size 4 >> ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> daemon: accept(7) failed errno=9 (Bad file descriptor) >> ==9657== >> ==9657== Thread 5: >> ==9657== Invalid free() / delete / delete[] >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >> ==9657== by 0x80874AF: do_search (search.c:221) >> ==9657== by 0x8084347: connection_operation (connection.c:1084) >> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) >> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== >> ==9657== Invalid free() / delete / delete[] >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >> ==9657== by 0x80874D3: do_search (search.c:224) >> ==9657== by 0x8084347: connection_operation (connection.c:1084) >> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) >> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" >> DN="cn=manager,dc=example,dc=com" >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> slapd stopped. >> ==9657== >> ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) >> ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. >> ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes >> allocated. >> ==9657== For counts of detected errors, rerun with: -v >> ==9657== searching for pointers to 15 not-freed blocks. >> ==9657== checked 774,072 bytes. >> >> Apparently, the listener is freed while some thread is still using it. > > Since that can only occur during shutdown, I don't think it's really a > high priority problem. More to the point, it will not cause any heap > corruption. The serious problem is in thread 5, where rwm_op_cleanup > frees a DN that do_search also tries to free. It looks like > rwm_op_cleanup is badly broken here, it apparently should be checking to > make sure ros->ro_dn is != ros->r_dn before freeing r_dn (and ndn). With the latest rwm revision, I still get the glibc corruption: PID=15912 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). [quanah(a)tribes tests]$ *** glibc detected *** corrupted double-linked list: 0x0000003bf99316b8 *** when I hit control-C during the search. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============2061075971922438651==-- From quanah@zimbra.com Sat Sep 6 01:28:28 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 01:28:27 +0000 Message-ID: <200809060128.m861SR9k091225@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3573298004197630320==" --===============3573298004197630320== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit --On Saturday, September 06, 2008 1:12 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, September 06, 2008 12:08 AM +0000 hyc(a)symas.com wrote: > >> ando(a)sys-net.it wrote: >>> h.b.furuseth(a)usit.uio.no wrote: >>>>> [quanah(a)freelancer tests]$ *** glibc detected *** >>>>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>>>> double-linked list: 0x000000000d28a430 *** >>>> This message comes from glibc malloc. Its data structures are >>>> corrupted. >>>> >>>> I couldn't figure out much from the the valgrind output. >>>> But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, >>>> if that code isn't rotted - maybe that'll bring out the problem in >>>> another guise. If that code still works, I don't remember. >>> >>> Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running >>> test039 under valgrind and suddenly killing the process: >>> >>> ==9657== Memcheck, a memory error detector. >>> ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. >>> ==9657== Using LibVEX rev 1658, a library for dynamic binary >>> translation. ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by >>> OpenWorks LLP. ==9657== Using valgrind-3.2.1, a dynamic binary >>> instrumentation framework. ==9657== Copyright (C) 2000-2006, and GNU >>> GPL'd, by Julian Seward et al. ==9657== For more details, rerun with: -v >>> ==9657== >>> @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ >>> masarati(a)odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap- >>> devel/servers/slapd slapd starting >>> daemon: shutdown requested and initiated. >>> slapd shutdown: waiting for 8 threads to terminate >>> ==9657== Thread 3: >>> ==9657== Invalid read of size 4 >>> ==9657== at 0x807EF03: slap_listener (daemon.c:1754) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== >>> ==9657== Invalid write of size 4 >>> ==9657== at 0x807EF22: slap_listener (daemon.c:1759) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== >>> ==9657== Invalid read of size 4 >>> ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> daemon: accept(7) failed errno=9 (Bad file descriptor) >>> ==9657== >>> ==9657== Thread 5: >>> ==9657== Invalid free() / delete / delete[] >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >>> ==9657== by 0x80874AF: do_search (search.c:221) >>> ==9657== by 0x8084347: connection_operation (connection.c:1084) >>> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) >>> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >>> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >>> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >>> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >>> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >>> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >>> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >>> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >>> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >>> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >>> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== >>> ==9657== Invalid free() / delete / delete[] >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >>> ==9657== by 0x80874D3: do_search (search.c:224) >>> ==9657== by 0x8084347: connection_operation (connection.c:1084) >>> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) >>> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >>> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >>> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >>> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >>> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >>> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >>> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >>> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >>> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >>> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >>> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" >>> DN="cn=manager,dc=example,dc=com" >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> slapd stopped. >>> ==9657== >>> ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) >>> ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. >>> ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes >>> allocated. >>> ==9657== For counts of detected errors, rerun with: -v >>> ==9657== searching for pointers to 15 not-freed blocks. >>> ==9657== checked 774,072 bytes. >>> >>> Apparently, the listener is freed while some thread is still using it. >> >> Since that can only occur during shutdown, I don't think it's really a >> high priority problem. More to the point, it will not cause any heap >> corruption. The serious problem is in thread 5, where rwm_op_cleanup >> frees a DN that do_search also tries to free. It looks like >> rwm_op_cleanup is badly broken here, it apparently should be checking to >> make sure ros->ro_dn is != ros->r_dn before freeing r_dn (and ndn). > > With the latest rwm revision, I still get the glibc corruption: > > PID=15912 - Search(500): base="o=Example,c=US" scope=sub > filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). > > [quanah(a)tribes tests]$ *** glibc detected *** corrupted double-linked > list: 0x0000003bf99316b8 *** > > when I hit control-C during the search. Longer backtrace: Loaded symbols for /lib64/libgcc_s.so.1 #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 #1 0x0000003bf972fa5e in abort () from /lib64/tls/libc.so.6 #2 0x0000003bf97635e1 in __libc_message () from /lib64/tls/libc.so.6 #3 0x0000003bf9768a78 in malloc_consolidate () from /lib64/tls/libc.so.6 #4 0x0000003bf97698a9 in _int_malloc () from /lib64/tls/libc.so.6 #5 0x0000003bf976b682 in malloc () from /lib64/tls/libc.so.6 #6 0x0000002a956bc46d in ber_memalloc_x (s=4060, ctx=0x0) at memory.c:226 #7 0x0000002a956bc5b1 in ber_memrealloc_x (p=0x0, s=4060, ctx=0x0) at memory.c:304 #8 0x0000002a956ba5ef in ber_realloc (ber=0x7ce520, len=1) at io.c:155 #9 0x0000002a956ba49b in ber_write (ber=0x7ce520, buf=0x42001010 "\002�\177@", len=1, nosos=0) at io.c:114 #10 0x0000002a956b8145 in ber_put_tag (ber=0x7ce520, tag=0, nosos=0) at encode.c:100 #11 0x0000002a956b877e in ber_put_int_or_enum (ber=0x7ce520, num=6, tag=2) at encode.c:284 #12 0x0000002a956b8933 in ber_put_int (ber=0x7ce520, num=6, tag=2) at encode.c:333 #13 0x0000002a956b99f7 in ber_printf (ber=0x7ce520, fmt=0x2a955a1629 "iti") at encode.c:774 #14 0x0000002a95574f68 in do_abandon (ld=0x81f9f0, origid=5, msgid=5, sctrls=0x0, sendabandon=1) at abandon.c:243 #15 0x0000002a95574c49 in ldap_abandon_ext (ld=0x81f9f0, msgid=5, sctrls=0x0, cctrls=0x0) at abandon.c:80 #16 0x0000002a974ac864 in ldap_back_cancel (lc=0x81f5d0, op=0x7bab00, rs=0x42002cc0, msgid=5, sendok=LDAP_BACK_DONTSEND) at bind.c:1607 #17 0x0000002a974a7d02 in ldap_back_search (op=0x7bab00, rs=0x42002cc0) at search.c:287 #18 0x00000000004ac45d in glue_sub_search (op=0x7bab00, rs=0x42002cc0, b0=0x42001740, on=0x6c1e70) at backglue.c:340 #19 0x00000000004aca5f in glue_op_search (op=0x7bab00, rs=0x42002cc0) at backglue.c:452 #20 0x00000000004afacf in overlay_op_walk (op=0x7bab00, rs=0x42002cc0, which=op_search, oi=0x6c1c90, on=0x6c1e70) at backover.c:657 #21 0x00000000004afd2b in over_op_func (op=0x7bab00, rs=0x42002cc0, which=op_search) at backover.c:719 #22 0x00000000004afdc1 in over_op_search (op=0x7bab00, rs=0x42002cc0) at backover.c:741 #23 0x0000000000435ea8 in fe_op_search (op=0x7bab00, rs=0x42002cc0) at search.c:366 #24 0x00000000004afb63 in overlay_op_walk (op=0x7bab00, rs=0x42002cc0, which=op_search, oi=0x702480, on=0x0) at backover.c:667 #25 0x00000000004afd2b in over_op_func (op=0x7bab00, rs=0x42002cc0, which=op_search) at backover.c:719 #26 0x00000000004afdc1 in over_op_search (op=0x7bab00, rs=0x42002cc0) at backover.c:741 #27 0x0000000000435865 in do_search (op=0x7bab00, rs=0x42002cc0) at search.c:217 #28 0x0000000000432839 in connection_operation (ctx=0x42002e20, arg_v=0x7bab00) at connection.c:1084 #29 0x0000000000432d75 in connection_read_thread (ctx=0x42002e20, argv=0x2b) at connection.c:1211 #30 0x0000002a95568cd0 in ldap_int_thread_pool_wrapper (xpool=0x6a3500) at tpool.c:663 #31 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #32 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6 (gdb) info threads 15 process 25502 0x0000003bfa00714b in pthread_join () from /lib64/tls/libpthread.so.0 14 process 25532 0x0000003bfa008b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 13 process 25554 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 12 process 25555 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 11 process 25821 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 10 process 25834 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 9 process 25852 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 8 process 25869 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 7 process 25870 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 6 process 25871 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 5 process 25923 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 4 process 25925 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 3 process 25928 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 2 process 25931 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 * 1 process 25820 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3573298004197630320==-- From quanah@zimbra.com Sat Sep 6 01:32:24 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 01:32:23 +0000 Message-ID: <200809060132.m861WNvE092860@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8215170396794643057==" --===============8215170396794643057== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Saturday, September 06, 2008 1:28 AM +0000 quanah(a)zimbra.com wrote: This one too: Loaded symbols for ../servers/slapd/overlays/.libs/rwm-2.4-releng.so.2 #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 #1 0x0000003bf972fa5e in abort () from /lib64/tls/libc.so.6 #2 0x0000003bf97635e1 in __libc_message () from /lib64/tls/libc.so.6 #3 0x0000003bf9768a78 in malloc_consolidate () from /lib64/tls/libc.so.6 #4 0x0000003bf97698a9 in _int_malloc () from /lib64/tls/libc.so.6 #5 0x0000003bf976b3d2 in calloc () from /lib64/tls/libc.so.6 #6 0x0000002a956bc517 in ber_memcalloc_x (n=1, s=560, ctx=0x0) at memory.c:277 #7 0x0000002a9556a5c0 in ldap_create (ldp=0x45808270) at open.c:113 #8 0x0000002a9556a985 in ldap_initialize (ldp=0x458082e8, url=0x7070c0 "ldap://localhost:9011") at open.c:223 #9 0x0000002a974aa3df in ldap_back_prepare_conn (lc=0x7d63d0, op=0x810030, rs=0x45809cc0, sendok=LDAP_BACK_DONTSEND) at bind.c:639 #10 0x0000002a974ad2c2 in ldap_back_retry (lcp=0x45808520, op=0x810030, rs=0x45809cc0, sendok=LDAP_BACK_DONTSEND) at bind.c:1893 #11 0x0000002a974a8668 in ldap_back_search (op=0x810030, rs=0x45809cc0) at search.c:502 #12 0x00000000004ac45d in glue_sub_search (op=0x810030, rs=0x45809cc0, b0=0x45808740, on=0x6c1e70) at backglue.c:340 #13 0x00000000004aca5f in glue_op_search (op=0x810030, rs=0x45809cc0) at backglue.c:452 #14 0x00000000004afacf in overlay_op_walk (op=0x810030, rs=0x45809cc0, which=op_search, oi=0x6c1c90, on=0x6c1e70) at backover.c:657 #15 0x00000000004afd2b in over_op_func (op=0x810030, rs=0x45809cc0, which=op_search) at backover.c:719 #16 0x00000000004afdc1 in over_op_search (op=0x810030, rs=0x45809cc0) at backover.c:741 #17 0x0000000000435ea8 in fe_op_search (op=0x810030, rs=0x45809cc0) at search.c:366 #18 0x00000000004afb63 in overlay_op_walk (op=0x810030, rs=0x45809cc0, which=op_search, oi=0x702480, on=0x0) at backover.c:667 #19 0x00000000004afd2b in over_op_func (op=0x810030, rs=0x45809cc0, which=op_search) at backover.c:719 #20 0x00000000004afdc1 in over_op_search (op=0x810030, rs=0x45809cc0) at backover.c:741 #21 0x0000000000435865 in do_search (op=0x810030, rs=0x45809cc0) at search.c:217 #22 0x0000000000432839 in connection_operation (ctx=0x45809e20, arg_v=0x810030) at connection.c:1084 #23 0x0000000000432d75 in connection_read_thread (ctx=0x45809e20, argv=0x29) at connection.c:1211 #24 0x0000002a95568cd0 in ldap_int_thread_pool_wrapper (xpool=0x6a3500) at tpool.c:663 #25 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #26 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6 (gdb) info threads 18 process 30967 0x0000003bfa00714b in pthread_join () from /lib64/tls/libpthread.so.0 17 process 31162 0x0000003bfa008b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 16 process 31178 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 15 process 31259 0x0000003bfa00af8b in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0 14 process 31262 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 13 process 31313 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 12 process 31397 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 11 process 31402 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 10 process 31403 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 9 process 31408 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 8 process 31409 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 7 process 31423 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 6 process 31485 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 5 process 31486 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 4 process 31497 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 3 process 31498 0x0000003bfa00af8b in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0 2 process 31511 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 * 1 process 31422 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============8215170396794643057==-- From ando@sys-net.it Sat Sep 6 09:39:52 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 09:39:52 +0000 Message-ID: <200809060939.m869dqAh025422@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2548714293740890102==" --===============2548714293740890102== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Quanah, I'm not seeing failures like yours, but valgrind is telling me that there is still a double-free in rwm in case of CTRL^C (apart from the listener-related one, which occurs very often): ==12729== Thread 7: ==12729== Invalid free() / delete / delete[] ==12729== at 0x4004FDA: free (vg_replace_malloc.c:233) ==12729== by 0x8240855: ber_memfree_x (memory.c:152) ==12729== by 0x80E5277: slap_sl_free (sl_malloc.c:451) ==12729== by 0x80874AF: do_search (search.c:221) ==12729== by 0x8084347: connection_operation (connection.c:1084) ==12729== by 0x8084834: connection_read_thread (connection.c:1211) ==12729== by 0x820F460: ldap_int_thread_pool_wrapper (tpool.c:663) ==12729== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==12729== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==12729== Address 0x44F7908 is 0 bytes inside a block of size 19 free'd ==12729== at 0x4004FDA: free (vg_replace_malloc.c:233) ==12729== by 0x8240855: ber_memfree_x (memory.c:152) ==12729== by 0x80A5A31: ch_free (ch_malloc.c:139) ==12729== by 0x81E1DC0: rwm_op_cleanup (rwm.c:65) ==12729== by 0x80976CD: slap_cleanup_play (result.c:341) ==12729== by 0x8097DEA: send_ldap_response (result.c:522) ==12729== by 0x809850E: slap_send_ldap_result (result.c:642) ==12729== by 0x812D806: ldap_back_search (search.c:544) ==12729== by 0x80F7E40: glue_sub_search (backglue.c:340) ==12729== by 0x80F83A9: glue_op_search (backglue.c:452) ==12729== by 0x80FAD2F: overlay_op_walk (backover.c:657) ==12729== by 0x80FAF64: over_op_func (backover.c:719) ==12729== by 0x80FAFE8: over_op_search (backover.c:741) ==12729== by 0x8087ADB: fe_op_search (search.c:366) ==12729== by 0x80FADAF: overlay_op_walk (backover.c:667) ==12729== by 0x80FAF64: over_op_func (backover.c:719) ==12729== by 0x80FAFE8: over_op_search (backover.c:741) ==12729== by 0x8087483: do_search (search.c:217) ==12729== by 0x8084347: connection_operation (connection.c:1084) ==12729== by 0x8084834: connection_read_thread (connection.c:1211) ==12729== It seems that rwm_op_cleanup() frees the massaged DN but does not restore the original values, since do_search frees it again. I guess the dn does get massaged, since r_dn is not null. 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 ----------------------------------- --===============2548714293740890102==-- From ando@sys-net.it Sat Sep 6 13:24:15 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 13:24:15 +0000 Message-ID: <200809061324.m86DOFOD032033@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5447016406147240274==" --===============5447016406147240274== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ando(a)sys-net.it wrote: > It seems that rwm_op_cleanup() frees the massaged DN but does not > restore the original values, since do_search frees it again. I guess > the dn does get massaged, since r_dn is not null. The problem is in glue_op_search(): it saves a copy of the rewritten DN; in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a dangling pointer to it is later restored in o_req_[n]dn by glue_op_search (lines 446-7 or 463-4). Trying to fix it... 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 ----------------------------------- --===============5447016406147240274==-- From ando@sys-net.it Sat Sep 6 14:26:38 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 14:26:37 +0000 Message-ID: <200809061426.m86EQbaj034974@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6812910413957291886==" --===============6812910413957291886== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ando(a)sys-net.it wrote: > The problem is in glue_op_search(): it saves a copy of the rewritten DN; > in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a > dangling pointer to it is later restored in o_req_[n]dn by > glue_op_search (lines 446-7 or 463-4). Trying to fix it... I've applied a fix that works around this issue without apparently breaking back-glue (servers/slapd/backglue.c 1.139 -> 1.140). Please test. 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 ----------------------------------- --===============6812910413957291886==-- From ando@sys-net.it Sat Sep 6 14:28:41 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 14:28:40 +0000 Message-ID: <200809061428.m86ESeAm035674@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7975357880411347055==" --===============7975357880411347055== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > The serious problem is in thread 5, where rwm_op_cleanup frees a DN that=20 > do_search also tries to free. It looks like rwm_op_cleanup is badly broken = > here, it apparently should be checking to make sure ros->ro_dn is !=3D ros-= >r_dn=20 > before freeing r_dn (and ndn). This issue can be serious since it could also hit in case of abandon,=20 not just in case of shutdown. 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 ----------------------------------- --===============7975357880411347055==-- From ando@sys-net.it Sat Sep 6 15:53:10 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5679) Translucent search Date: Sat, 06 Sep 2008 15:53:10 +0000 Message-ID: <200809061553.m86FrA1P040676@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7896209797137278092==" --===============7896209797137278092== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable julien(a)famille-garnier.com wrote: > It seems to be impossible to search local and remote together :=20 >=20 > a search request against one local attribute work correctly and return resu= lt 1 > (ldapsearch "(local=3D*)") > a search on a remote atttribute works fine and return result 2 (ldapsearch > "(remote=3D*)") >=20 > Finaly, a search with the local and remote attribute (ldapsearch > "($(local=3D*)(remote=3D*))") I assume "$" is a typo, while you meant "&" in the above filter. > only return results as the search on the local > attribute and doesn't take the remote attribute. The respons is the same as > result 1 >=20 >=20 > In slapd.conf :=20 > translucent_local local > translucent_remote remote I've checked the current code, and it appears to work as intended. Can=20 you confirm the fact that the local and remote attributes are contained=20 only in the local and the remote database, respectively? You can easily=20 check by directly searching the remote database. Otherwise, you don't=20 provide enough information about configuration and database contents to=20 reproduce the issue. 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 ----------------------------------- --===============7896209797137278092==-- From quanah@zimbra.com Sat Sep 6 19:25:10 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5687) corrupted double-linked list on shutdown Date: Sat, 06 Sep 2008 19:25:09 +0000 Message-ID: <200809061925.m86JP9Uw049168@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1580206534053727750==" --===============1580206534053727750== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Saturday, September 06, 2008 2:26 PM +0000 ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> The problem is in glue_op_search(): it saves a copy of the rewritten DN; >> in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a >> dangling pointer to it is later restored in o_req_[n]dn by >> glue_op_search (lines 446-7 or 463-4). Trying to fix it... > > I've applied a fix that works around this issue without apparently > breaking back-glue (servers/slapd/backglue.c 1.139 -> 1.140). Please > test. I have no more issues after applying these additional fixes. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============1580206534053727750==-- From ando@sys-net.it Sun Sep 7 22:13:15 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5663) Declaring substitute syntax as LDAP syntax Date: Sun, 07 Sep 2008 22:13:14 +0000 Message-ID: <200809072213.m87MDEEV022806@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3098575539032751850==" --===============3098575539032751850== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The suggested extension has been added to syntax add code; parsing of a syntax with the given extension will result in using the implementation of the substitute syntax if an implementation is missing for the given syntax. This only works for syntaxes added programmatically using syn_add(), e.g. by run-time modules, as there's no provisions for adding syntaxes via configuration. 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 ----------------------------------- --===============3098575539032751850==-- From julien.garnier@dr13.cnrs.fr Mon Sep 8 08:56:15 2008 From: julien.garnier@dr13.cnrs.fr To: openldap-bugs@openldap.org Subject: Re: (ITS#5679) Translucent search Date: Mon, 08 Sep 2008 08:56:14 +0000 Message-ID: <200809080856.m888uEca044655@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3378238798432147391==" --===============3378238798432147391== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is a cryptographically signed message in MIME format. --------------ms090100030100000501010002 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Pierangelo Masarati a écrit :
julien(a)famille-garnier.com wrote:

It seems to be impossible to search local and remote together :
a search request against one local attribute work correctly and return result 1
(ldapsearch "(local=3D*)")
a search on a remote atttribute works fine  and return result 2 (ldapsearch
"(remote=3D*)")

Finaly, a search with the local and remote attribute  (ldapsearch
"($(local=3D*)(remote=3D*))")

I assume "$" is a typo, while you meant "&" in the above filter.
Hi Pierangelo,
yes, it is a typo

only return results as the search on the local
attribute and doesn't take the remote attribute. The respons is the same as
result 1


In slapd.conf : translucent_local local
translucent_remote remote

I've checked the current code, and it appears to work as intended.  Can you confirm the fact that the local and remote attributes are contained only in the local and the remote database, respectively?  You can easily check by directly searching the remote database.  Otherwise, you don't provide enough information about configuration and database contents to reproduce the issue.
my config :

ldap_relay (remote in the translucent config) is synchronize with a master via syncrepl. :

#######################################################################
# Global Directives:

# Features to permit
allow bind_v2

# Schema and objectClass definitions
include         /etc/openldap/schema/= core.schema
include         /etc/openldap/schema/= cosine.schema
include         /etc/openldap/schema/= nis.schema
include         /etc/openldap/schema/= inetorgperson.schema
include         /etc/openldap/schema/= cnrs.schema

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile         /var/run/slapd/slapd.= pid

# List of arguments that were passed to the server
argsfile        /var/run/slapd/slapd.args<= br>
# Read slapd.conf(5) for possible values
loglevel        0

# Where the dynamically loaded modules are stored

# The maximum number of entries that is returned for a search operation
sizelimit 500000

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 2

#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend         bdb
#checkpoint 512 30

database        bdb

# The base of your directory in database #1
suffix          "ou=3DPeople,dc= =3Dcnrs,dc=3Dfr"

# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn          "cn=3Dadmin,ou= =3DPeople,dc=3Dcnrs,dc=3Dfr"
rootpw          "password"

# Where the database file are physically stored for database #1
directory       "/var/lib/ldap-people"

# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
#dbconfig set_cachesize 0 2097152 0
dbconfig set_cachesize 0 536870912 0
dbconfig set_flags    DB_LOG_AUTOREMOVE

# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057
# for more information.

# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requestd and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500
dbconfig set_flags    DB_LOG_AUTOREMOVE


# Indexing options for database #1
index objectClass          =              eq index ou,cn,mail,surname,givenname      eq,pres,sub<= br> index uid           &n= bsp;            &= nbsp;      eq,pres,sub
index entryUUID,entryCSN         = ;       eq,pres
index cnrsRole,cnrsDepartement        = ;  eq,pres,sub
index cnrsDelegation         &nb= sp;          eq,pres,sub
index departmentNumber         &= nbsp;        eq,pres,sub

# Save the time that the entry gets modified, for database #1
lastmod         on

#id du client (numero DR)
syncrepl rid=3D013
        provider=3Dldap://sagan.dr15.cnrs.fr:389
        searchbase=3D"ou=3DPeople,dc=3Dcnr= s,dc=3Dfr"
        type=3DrefreshAndPersist
        scope=3Dsub
        interval=3D00:00:00:10
        retry=3D"60 10 300 +"
        attrs=3D"*"
        schemachecking=3Doff
        bindmethod=3Dsimple
        binddn=3D"cn=3Dsync-dr13,ou=3Dpeop= le,dc=3Dcnrs,dc=3Dfr"
        credentials=3D"password"

access to dn.base=3D"" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
        by dn=3D"cn=3Dadmin,ou=3DPeople,dc= =3Dcnrs,dc=3Dfr" write
        by * read


*******************************************************************
*******************************************************************

My ldap server user translucent to add attributes to ldap_relay :

# Schema and objectClass definitions
include         /etc/openldap/schema/= core.schema
include         /etc/openldap/schema/= cosine.schema
include         /etc/openldap/schema/= nis.schema
include         /etc/openldap/schema/= inetorgperson.schema
include         /etc/openldap/schema/= DR13.schema
include         /etc/openldap/schema/= cnrs.schema
include         /etc/openldap/schema/= dyngroup.schema
#include         /etc/openldap/schema= /calendar.schema
#include         /etc/openldap/schema= /julien.schema

pidfile         /var/run/slapd/slapd.= pid
argsfile        /var/run/slapd/slapd.args<= br> loglevel      0

allow bind_v2

# The maximum number of entries that is returned for a search operation
sizelimit       50000

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads    1

#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend         bdb

#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database        bdb

# The base of your directory in database #1
suffix          "ou=3DPeople,dc= =3Dcnrs,dc=3Dfr"

# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn          "cn=3Dadmin,ou= =3DPeople,dc=3Dcnrs,dc=3Dfr"
rootpw          "password"

# Where the database file are physically stored for database #1
directory       "/var/lib/ldap-people"

dbconfig set_cachesize 0 536870912 0
dbconfig set_flags    DB_LOG_AUTOREMOVE
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500

# Indexing options for database #1
index objectClass          =              eq,p= res
index ou,cn,mail,surname,givenname      eq,pres,sub<= br> index uid           &n= bsp;            &= nbsp;      eq,pres
index entryCSN,entryUUID         = ;       eq,pres
index cnrsDelegation         &nb= sp;          eq,pres,sub
index Service,ACMO,corinfo,corcom,corform,corvalo,gxlab,corsecu,authtest,GLabintel&= nbsp;            =    eq,pres,sub

overlay         translucent
translucent_no_glue off
translucent_strict off

translucent_local ACMO,Service,corinfo,corcom,corform,corvalo,gxlab,corsecu,userPassword,shadow= LastChange,authtest,GLabintel,Poste
translucent_remote sn,GivenName,mail,street,Postalcode,l,cnrsDelegation,uid

uri             <= a class=3D"moz-txt-link-freetext" href=3D"ldap://ldap_relay.dr13.cnrs.fr">ldap://ldap_relay.dr13.cnrs.fr lastmod         off

acl-bind        binddn=3D"cn=3Dadmin,ou=3D= People,dc=3Dcnrs,dc=3Dfr" credentials=3D"password"

access to attrs=3DuserPassword,shadowLastChange
        by dn=3D"cn=3Dadmin,ou=3DPeople,dc= =3Dcnrs,dc=3Dfr" write
        by anonymous auth
        by self write
        by * none

access to dn.base=3D""
        by * read

# acces de l'IBMM (UMR5247)
access to dn.sub=3D"ou=3Dpeople,dc=3Dcnrs,dc=3Dfr"
        filter=3D(ou=3DUMR5247*)
        by peername.regex=3D"IP=3D193\.49\= .133\..+" read
        by peername.regex=3D"IP=3D127\.0\.= 0\.1" read
        by peername.regex=3D"IP=3D194\.214= \.161\.70" read

# acces de la delegation : lecture pour tout
access to *
        by peername.regex=3D"IP=3D193\.49\= .133\..+" read
        by peername.regex=3D"IP=3D127\.0\.= 0\.1" read
        by dn=3D"cn=3Dadmin,ou=3DPeople,dc= =3Dcnrs,dc=3Dfr" write
        by * none
***********************************************************
***********************************************************

the searches :
ou is in remote (it's ou derivated from inetorgperson)
corsecu is in local : attribute is add to inetorgperson :
attributetype ( 1.3.6.1.4.1.10813.13.2.9
        NAME 'CorSecu'
        DESC 'Correspondant Securité= ;'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch         SYNTAX 1.3.6.1.4.1.1466.115.121.1.= 15 )


if I search who is corsecu :

 ldapsearch -x -b "ou=3DPeople,dc=3Dcnrs,dc=3Dfr"  "(corsecu=3D*)" = ou corsecu
# extended LDIF
#
# LDAPv3
# base <ou=3DPeople,dc=3Dcnrs,dc=3Dfr> with scope subtree
# filter: (corsecu=3D*)
# requesting: ou corsecu
#

# martine.costanzo, cnrs, People, cnrs.fr
dn: uid=3Dmartine.costanzo,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr
ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D=3D
CorSecu: MOY1300

# vincent.chicot, cnrs, People, cnrs.fr
dn: uid=3Dvincent.chicot,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr
ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D=3D
CorSecu: MOY1300

# josiane.tack.1, cnrs, People, cnrs.fr
dn: uid=3Djosiane.tack.1,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr
ou:: VU1SNTI0MyAtICgxKSAtIEfDqW9zY2llbmNlcyBNb250cGVsbGllcg=3D=3D
CorSecu: UMR5243

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Josian Tack is in OU  =3D UMR5243 - (1) - Géosciences Montpellier=
other are in OU =3D MOY1300 - (1) - Délégation Languedoc-Roussi= llon

If I only want corsecu in ou MOY1300 :

ldapsearch -x -b "ou=3DPeople,dc=3Dcnrs,dc=3Dfr"  "(&(ou=3DMOY1300*)(corsecu=3D*))" ou corsecu

# extended LDIF
#
# LDAPv3
# base <ou=3DPeople,dc=3Dcnrs,dc=3Dfr> with scope subtree
# filter: (&(ou=3DMOY1300*)(corsecu=3D*))
# requesting: ou corsecu
#

# martine.costanzo, cnrs, People, cnrs.fr
dn: uid=3Dmartine.costanzo,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr
ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D=3D
CorSecu: MOY1300

# vincent.chicot, cnrs, People, cnrs.fr
dn: uid=3Dvincent.chicot,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr
ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D=3D
CorSecu: MOY1300

# josiane.tack.1, cnrs, People, cnrs.fr
dn: uid=3Djosiane.tack.1,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr
ou:: VU1SNTI0MyAtICgxKSAtIEfDqW9zY2llbmNlcyBNb250cGVsbGllcg=3D=3D
CorSecu: UMR5243

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Josiane Tack is always here


Thanks

Julien


--------------ms090100030100000501010002 Content-Type: application/x-pkcs7-signature; name=3D"smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=3D"smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxTCC A2kwggJRoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoT BENOUlMxDTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NTI4WhcNMTEwNDI1MDU0NTI4WjAw MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyQlSTUNpNZM31NKiH++/aLeFo2lCbD/EdAsq k8Vzl0yoN+BS3qY5EbkZbUwU3x/o0XsfvqsfOqTz4MxEavsJmlRetHAfYUPmXCiwwnxCmFS/ +N2NmN2bnWIY0Vzk6qZkgTdYZqj1eiXNyn1q1E/IpPEp7hA+KdulYJ706Xj99ih8kVFa/a8y 45ub5FOWpK4DJPBoNxS7LPsZyGtfehmcCRtj2JF7BcxJMTH6GPwZ1j/Y4DdBcxmzIfLOjQly ROrlDF5iiscuxzZOPOKUcbnjU5fgFxTE8YQ9jyqL5X6xeWaNABwPR6O+Kln/eDowWrJXnjke VBbfBKm6xYvLyzlQUQIDAQABo4GSMIGPMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFFd9dKaS m4hc/uQEKfTsOmcnVOD4MFMGA1UdIwRMMEqAFFbraLnSXH6YtaVTw5FvY1jE+Wu3oS+kLTAr MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SU4IBADALBgNVHQ8E BAMCAQYwDQYJKoZIhvcNAQEEBQADggEBAEc8oDJIziXlPHqdm+CF/44HRs8MOif5Un3d8x7y vgBqvLt2WV6xoI4h4Y+54Z7Aog3H65z/qtiZdxb3CehCzhltPGHZ/oNHZJa74xqUXJgXeKUk V/JQw0a/z4VLRjnhU0mzbvghbOAJsA6QqsKWC2ZiWhHZaLScVt3zrJ9F8mWX3DAf4HRN+0iY U438vLKSBM6KJhb7Mn1tXk36IcskrwAnozVizkwLendcMYpKuKyu7DofQXUouGwJF+YE6u3B L72QvPko9jHauBqNWpRm2n1ETnjw2VXs7RKfy8q8no78VLT8+x7fPCBcZMx69Ytyouj+TThX KVNQ4bxYoJEggZUwggSoMIIDkKADAgECAgIOdzANBgkqhkiG9w0BAQUFADAwMQswCQYDVQQG EwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMB4XDTA3MTEwODEyMDAw NFoXDTA4MTEwNzEyMDAwNFowczELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxEDAOBgNV BAsTB01PWTEzMDAxFzAVBgNVBAMTDkp1bGllbiBHYXJuaWVyMSowKAYJKoZIhvcNAQkBFhtK dWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDnOJa63KmBNrk1iWwIoBfaNRIoB5R+4X+aCOXHD9jXaq5WUV42JEFHvgA87t6esw5U lKgjjyDa8IEW6YQX/WQ9EuHVq4zAvYFQ37bv+obvf1icCyOxDCqqozcIaP8vawVhD244p3bx nVP18QlmlS6MAoqD2NSOgdXjrqQb2uJSE+KLwGMnjjs4zb8lRt2dYp67z7SBLYTnTq04o0Yr fOtYt+rnlleDlWKdJGgNqryiHO20tKlOAUHE4ahZHjsKhEZGdJ4KCoEuDNQtyRLznRGuuH+b 2QjecVL2DmF26hNYlgM4c4TNWETGEBSgdBnlntcEQH443LN2qEx+lRA5dIr/AgMBAAGjggGH MIIBgzAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIEsDAOBgNVHQ8BAf8EBAMCBeAw cAYJYIZIAYb4QgENBGMWYUNlcnRpZmljYXQgQ05SUy1QbHVzLiBQb3VyIHRvdXRlIGluZm9y bWF0aW9uIHNlIHJlcG9ydGVyIOAgaHR0cDovL2lnYy5zZXJ2aWNlcy5jbnJzLmZyL0NOUlMt UGx1cy8wHQYDVR0OBBYEFECFdlYtLkLUfoSH/7VfvQ4hYG60MFMGA1UdIwRMMEqAFFd9dKaS m4hc/uQEKfTsOmcnVOD4oS+kLTArMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsG A1UEAxMEQ05SU4IBATAmBgNVHREEHzAdgRtKdWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIw QgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybHMuc2VydmljZXMuY25ycy5mci9DTlJTLVBs dXMvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuz1KzmYgAcfVPB1mE8GBR0Yzz/td ij3IttaeiCmpDfArhOwdolUiLV1MF/oJGDHX+yxpcHNu6wH3E6eEVoYycPwCcN5P9mTaxrTG KYXIj6RoDPIiCQpE9zjKV+c0jJr0bwBZIIJfCIpOpmcHHW+3BbtqjuboydwOqh5ICesPnMRr BA6WEEnB7pv1sp0vAoK0O7/ctJS6C/X37LsTBYcHVkKoyjGYUYdBjWUgmPs+jsArqe+QKSRA zl/3Xc83ZZ681aKApq9hrlmDYpP50E87uK+c2ul/fm4iwvJdb3WkyQaCfc4Epot5GMusb5/C j8JLmtpc7mv+DIrhbz3jbmZ0HTCCBKgwggOQoAMCAQICAg53MA0GCSqGSIb3DQEBBQUAMDAx CzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMwHhcNMDcx MTA4MTIwMDA0WhcNMDgxMTA3MTIwMDA0WjBzMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05S UzEQMA4GA1UECxMHTU9ZMTMwMDEXMBUGA1UEAxMOSnVsaWVuIEdhcm5pZXIxKjAoBgkqhkiG 9w0BCQEWG0p1bGllbi5HYXJuaWVyQGRyMTMuY25ycy5mcjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAOc4lrrcqYE2uTWJbAigF9o1EigHlH7hf5oI5ccP2NdqrlZRXjYkQUe+ ADzu3p6zDlSUqCOPINrwgRbphBf9ZD0S4dWrjMC9gVDftu/6hu9/WJwLI7EMKqqjNwho/y9r BWEPbjindvGdU/XxCWaVLowCioPY1I6B1eOupBva4lIT4ovAYyeOOzjNvyVG3Z1inrvPtIEt hOdOrTijRit861i36ueWV4OVYp0kaA2qvKIc7bS0qU4BQcThqFkeOwqERkZ0ngoKgS4M1C3J EvOdEa64f5vZCN5xUvYOYXbqE1iWAzhzhM1YRMYQFKB0GeWe1wRAfjjcs3aoTH6VEDl0iv8C AwEAAaOCAYcwggGDMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1UdDwEB /wQEAwIF4DBwBglghkgBhvhCAQ0EYxZhQ2VydGlmaWNhdCBDTlJTLVBsdXMuIFBvdXIgdG91 dGUgaW5mb3JtYXRpb24gc2UgcmVwb3J0ZXIg4CBodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMu ZnIvQ05SUy1QbHVzLzAdBgNVHQ4EFgQUQIV2Vi0uQtR+hIf/tV+9DiFgbrQwUwYDVR0jBEww SoAUV310ppKbiFz+5AQp9Ow6ZydU4PihL6QtMCsxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRD TlJTMQ0wCwYDVQQDEwRDTlJTggEBMCYGA1UdEQQfMB2BG0p1bGllbi5HYXJuaWVyQGRyMTMu Y25ycy5mcjBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vY3Jscy5zZXJ2aWNlcy5jbnJzLmZy L0NOUlMtUGx1cy9nZXRkZXIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC7PUrOZiABx9U8HWYT wYFHRjPP+12KPci21p6IKakN8CuE7B2iVSItXUwX+gkYMdf7LGlwc27rAfcTp4RWhjJw/AJw 3k/2ZNrGtMYphciPpGgM8iIJCkT3OMpX5zSMmvRvAFkggl8Iik6mZwcdb7cFu2qO5ujJ3A6q HkgJ6w+cxGsEDpYQScHum/WynS8CgrQ7v9y0lLoL9ffsuxMFhwdWQqjKMZhRh0GNZSCY+z6O wCup75ApJEDOX/ddzzdlnrzVooCmr2GuWYNik/nQTzu4r5za6X9+biLC8l1vdaTJBoJ9zgSm i3kYy6xvn8KPwkua2lzua/4MiuFvPeNuZnQdMYICojCCAp4CAQEwNjAwMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzAgIOdzAJBgUrDgMCGgUAoIIB QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA5MDgwODU1 MDBaMCMGCSqGSIb3DQEJBDEWBBSid4zDaEYBT67+19UaSp/1nXMUWDBFBgkrBgEEAYI3EAQx ODA2MDAxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMC Ag53MEcGCyqGSIb3DQEJEAILMTigNjAwMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzES MBAGA1UEAxMJQ05SUy1QbHVzAgIOdzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQA04y3ZTPTP04e07uaMNwF5+4i+329g+KgAd+lmUvfaGJsOyGjw pCsZQIqeBzZFAfCNtmp8VyU2TCVcF6A5odWabasUltXe8HfLN64njJ/50iUQfDRFZEcZfh9b nYSTsHiuCyua78Iim18gNflXQReHWdreoSkg0MDaq0MTd98tNxZsOFPa4l9e7Xj29F4HHgck pD/0XXmP6/ZtFOxZUojL92H31RS6MlPeLC0EX5RjkLQ4maXlMvjX1MQUpv6uwOG1rkSaTDKW zEcUcKP/gYFHL7LDUZC8GlhLGvuzxrSamS2RRJE+mAzc/U+aOf6O7qeFyje8PM6r57qc0iQQ XCDeAAAAAAAA --------------ms090100030100000501010002-- --===============3378238798432147391==-- From ando@sys-net.it Mon Sep 8 10:18:06 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5679) Translucent search Date: Mon, 08 Sep 2008 10:18:05 +0000 Message-ID: <200809081018.m88AI5wM047801@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0419330227141330771==" --===============0419330227141330771== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Should now be fixed 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 ----------------------------------- --===============0419330227141330771==-- From ando@sys-net.it Mon Sep 8 10:55:47 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5689) back-config handling of olcTranslucentLocal/Remote is broken Date: Mon, 08 Sep 2008 10:55:47 +0000 Message-ID: <200809081055.m88AtlKQ050512@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3440830463673403561==" --===============3440830463673403561== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.148) Submitted by: ando remove the ARG_STRING to fix. p. --===============3440830463673403561==-- From julien.garnier@dr13.cnrs.fr Mon Sep 8 11:44:25 2008 From: julien.garnier@dr13.cnrs.fr To: openldap-bugs@openldap.org Subject: Re: (ITS#5679) Translucent search Date: Mon, 08 Sep 2008 11:44:24 +0000 Message-ID: <200809081144.m88BiOjr053543@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8350949661389684876==" --===============8350949661389684876== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is a cryptographically signed message in MIME format. --------------ms090702020105050508040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Pierangelo Masarati a =E9crit : > Should now be fixed in HEAD; please test and report. > > p. I've just install head : @(#) $OpenLDAP: slapd 2.X (Sep 8 2008 13:30:44) $ Seems to be OK, I only retrieve my 2 users What was the problem ? Thanks ! Julien *************************************************************************= ** ldapsearch -x -b "ou=3DPeople,dc=3Dcnrs,dc=3Dfr" =20 "(&(ou=3DMOY1300*)(corsecu=3D*))" ou corsecu # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(ou=3DMOY1300*)(corsecu=3D*)) # requesting: ou corsecu # # martine.costanzo, cnrs, People, cnrs.fr dn: uid=3Dmartine.costanzo,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D= =3D CorSecu: MOY1300 # vincent.chicot, cnrs, People, cnrs.fr dn: uid=3Dvincent.chicot,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D= =3D CorSecu: MOY1300 # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 --------------ms090702020105050508040500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxTCC A2kwggJRoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoT BENOUlMxDTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NTI4WhcNMTEwNDI1MDU0NTI4WjAw MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyQlSTUNpNZM31NKiH++/aLeFo2lCbD/EdAsq k8Vzl0yoN+BS3qY5EbkZbUwU3x/o0XsfvqsfOqTz4MxEavsJmlRetHAfYUPmXCiwwnxCmFS/ +N2NmN2bnWIY0Vzk6qZkgTdYZqj1eiXNyn1q1E/IpPEp7hA+KdulYJ706Xj99ih8kVFa/a8y 45ub5FOWpK4DJPBoNxS7LPsZyGtfehmcCRtj2JF7BcxJMTH6GPwZ1j/Y4DdBcxmzIfLOjQly ROrlDF5iiscuxzZOPOKUcbnjU5fgFxTE8YQ9jyqL5X6xeWaNABwPR6O+Kln/eDowWrJXnjke VBbfBKm6xYvLyzlQUQIDAQABo4GSMIGPMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFFd9dKaS m4hc/uQEKfTsOmcnVOD4MFMGA1UdIwRMMEqAFFbraLnSXH6YtaVTw5FvY1jE+Wu3oS+kLTAr MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SU4IBADALBgNVHQ8E BAMCAQYwDQYJKoZIhvcNAQEEBQADggEBAEc8oDJIziXlPHqdm+CF/44HRs8MOif5Un3d8x7y vgBqvLt2WV6xoI4h4Y+54Z7Aog3H65z/qtiZdxb3CehCzhltPGHZ/oNHZJa74xqUXJgXeKUk V/JQw0a/z4VLRjnhU0mzbvghbOAJsA6QqsKWC2ZiWhHZaLScVt3zrJ9F8mWX3DAf4HRN+0iY U438vLKSBM6KJhb7Mn1tXk36IcskrwAnozVizkwLendcMYpKuKyu7DofQXUouGwJF+YE6u3B L72QvPko9jHauBqNWpRm2n1ETnjw2VXs7RKfy8q8no78VLT8+x7fPCBcZMx69Ytyouj+TThX KVNQ4bxYoJEggZUwggSoMIIDkKADAgECAgIOdzANBgkqhkiG9w0BAQUFADAwMQswCQYDVQQG EwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMB4XDTA3MTEwODEyMDAw NFoXDTA4MTEwNzEyMDAwNFowczELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxEDAOBgNV BAsTB01PWTEzMDAxFzAVBgNVBAMTDkp1bGllbiBHYXJuaWVyMSowKAYJKoZIhvcNAQkBFhtK dWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDnOJa63KmBNrk1iWwIoBfaNRIoB5R+4X+aCOXHD9jXaq5WUV42JEFHvgA87t6esw5U lKgjjyDa8IEW6YQX/WQ9EuHVq4zAvYFQ37bv+obvf1icCyOxDCqqozcIaP8vawVhD244p3bx nVP18QlmlS6MAoqD2NSOgdXjrqQb2uJSE+KLwGMnjjs4zb8lRt2dYp67z7SBLYTnTq04o0Yr fOtYt+rnlleDlWKdJGgNqryiHO20tKlOAUHE4ahZHjsKhEZGdJ4KCoEuDNQtyRLznRGuuH+b 2QjecVL2DmF26hNYlgM4c4TNWETGEBSgdBnlntcEQH443LN2qEx+lRA5dIr/AgMBAAGjggGH MIIBgzAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIEsDAOBgNVHQ8BAf8EBAMCBeAw cAYJYIZIAYb4QgENBGMWYUNlcnRpZmljYXQgQ05SUy1QbHVzLiBQb3VyIHRvdXRlIGluZm9y bWF0aW9uIHNlIHJlcG9ydGVyIOAgaHR0cDovL2lnYy5zZXJ2aWNlcy5jbnJzLmZyL0NOUlMt UGx1cy8wHQYDVR0OBBYEFECFdlYtLkLUfoSH/7VfvQ4hYG60MFMGA1UdIwRMMEqAFFd9dKaS m4hc/uQEKfTsOmcnVOD4oS+kLTArMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsG A1UEAxMEQ05SU4IBATAmBgNVHREEHzAdgRtKdWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIw QgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybHMuc2VydmljZXMuY25ycy5mci9DTlJTLVBs dXMvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuz1KzmYgAcfVPB1mE8GBR0Yzz/td ij3IttaeiCmpDfArhOwdolUiLV1MF/oJGDHX+yxpcHNu6wH3E6eEVoYycPwCcN5P9mTaxrTG KYXIj6RoDPIiCQpE9zjKV+c0jJr0bwBZIIJfCIpOpmcHHW+3BbtqjuboydwOqh5ICesPnMRr BA6WEEnB7pv1sp0vAoK0O7/ctJS6C/X37LsTBYcHVkKoyjGYUYdBjWUgmPs+jsArqe+QKSRA zl/3Xc83ZZ681aKApq9hrlmDYpP50E87uK+c2ul/fm4iwvJdb3WkyQaCfc4Epot5GMusb5/C j8JLmtpc7mv+DIrhbz3jbmZ0HTCCBKgwggOQoAMCAQICAg53MA0GCSqGSIb3DQEBBQUAMDAx CzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMwHhcNMDcx MTA4MTIwMDA0WhcNMDgxMTA3MTIwMDA0WjBzMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05S UzEQMA4GA1UECxMHTU9ZMTMwMDEXMBUGA1UEAxMOSnVsaWVuIEdhcm5pZXIxKjAoBgkqhkiG 9w0BCQEWG0p1bGllbi5HYXJuaWVyQGRyMTMuY25ycy5mcjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAOc4lrrcqYE2uTWJbAigF9o1EigHlH7hf5oI5ccP2NdqrlZRXjYkQUe+ ADzu3p6zDlSUqCOPINrwgRbphBf9ZD0S4dWrjMC9gVDftu/6hu9/WJwLI7EMKqqjNwho/y9r BWEPbjindvGdU/XxCWaVLowCioPY1I6B1eOupBva4lIT4ovAYyeOOzjNvyVG3Z1inrvPtIEt hOdOrTijRit861i36ueWV4OVYp0kaA2qvKIc7bS0qU4BQcThqFkeOwqERkZ0ngoKgS4M1C3J EvOdEa64f5vZCN5xUvYOYXbqE1iWAzhzhM1YRMYQFKB0GeWe1wRAfjjcs3aoTH6VEDl0iv8C AwEAAaOCAYcwggGDMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1UdDwEB /wQEAwIF4DBwBglghkgBhvhCAQ0EYxZhQ2VydGlmaWNhdCBDTlJTLVBsdXMuIFBvdXIgdG91 dGUgaW5mb3JtYXRpb24gc2UgcmVwb3J0ZXIg4CBodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMu ZnIvQ05SUy1QbHVzLzAdBgNVHQ4EFgQUQIV2Vi0uQtR+hIf/tV+9DiFgbrQwUwYDVR0jBEww SoAUV310ppKbiFz+5AQp9Ow6ZydU4PihL6QtMCsxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRD TlJTMQ0wCwYDVQQDEwRDTlJTggEBMCYGA1UdEQQfMB2BG0p1bGllbi5HYXJuaWVyQGRyMTMu Y25ycy5mcjBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vY3Jscy5zZXJ2aWNlcy5jbnJzLmZy L0NOUlMtUGx1cy9nZXRkZXIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC7PUrOZiABx9U8HWYT wYFHRjPP+12KPci21p6IKakN8CuE7B2iVSItXUwX+gkYMdf7LGlwc27rAfcTp4RWhjJw/AJw 3k/2ZNrGtMYphciPpGgM8iIJCkT3OMpX5zSMmvRvAFkggl8Iik6mZwcdb7cFu2qO5ujJ3A6q HkgJ6w+cxGsEDpYQScHum/WynS8CgrQ7v9y0lLoL9ffsuxMFhwdWQqjKMZhRh0GNZSCY+z6O wCup75ApJEDOX/ddzzdlnrzVooCmr2GuWYNik/nQTzu4r5za6X9+biLC8l1vdaTJBoJ9zgSm i3kYy6xvn8KPwkua2lzua/4MiuFvPeNuZnQdMYICojCCAp4CAQEwNjAwMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzAgIOdzAJBgUrDgMCGgUAoIIB QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA5MDgxMTQz NTBaMCMGCSqGSIb3DQEJBDEWBBT/z7sYiEHm4wcm/1VtTFildsjJlDBFBgkrBgEEAYI3EAQx ODA2MDAxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMC Ag53MEcGCyqGSIb3DQEJEAILMTigNjAwMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzES MBAGA1UEAxMJQ05SUy1QbHVzAgIOdzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQDT70G5dWoLsUNxEnn23uXSg3MAa3xSAWUPJjio5a+iXc+63O2l mjkeYt/uvUyfHNtjfHldd7n8f2Ia20Q7tsIttT0llBozXtuvuJ8UYJ4aAxYxyaeLejLtojFA 5Ewh0O0YZ3vlM7SSm55uzh4MnuMPZdiGqdnw+GbF+RJiN2O9uSrcCRrlyWyCo/xLU5XokkHX hXbpRwy6e9A8QLS89Vqa3ndqtf4Uyy6GPMrCyQp5JgKW968uleP8lyB1tbyyU8mhlLLyvblo WaAWn339Nc/UPLOJy61qv2WTWDVDZzt6GbL07TQcqdx5iJf0Ra8zFN+5E5+7ffUhLtzBAa2m F9CfAAAAAAAA --------------ms090702020105050508040500-- --===============8350949661389684876==-- From julien.garnier@dr13.cnrs.fr Mon Sep 8 12:22:06 2008 From: julien.garnier@dr13.cnrs.fr To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 08 Sep 2008 12:22:05 +0000 Message-ID: <200809081222.m88CM5os055666@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8738959255874630927==" --===============8738959255874630927== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, I'm interersted in this option to. Juju --===============8738959255874630927==-- From ando@sys-net.it Mon Sep 8 13:12:58 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5679) Translucent search Date: Mon, 08 Sep 2008 13:12:58 +0000 Message-ID: <200809081312.m88DCwUn058053@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8841158469179669188==" --===============8841158469179669188== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Julien Garnier wrote: > Pierangelo Masarati a écrit : >> Should now be fixed in HEAD; please test and report. >> >> p. > > I've just install head : > @(#) $OpenLDAP: slapd 2.X (Sep 8 2008 13:30:44) $ > > Seems to be OK, I only retrieve my 2 users > What was the problem ? In your specific case (a "liberal" local filter and a strict remote filter ANDed) the original filter was not applied to the entire entry, after merging the local and remote parts. 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 ----------------------------------- --===============8841158469179669188==-- From quanah@zimbra.com Mon Sep 8 23:41:41 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: (ITS#5690) cn=config cannot be rootdn Date: Mon, 08 Sep 2008 23:41:40 +0000 Message-ID: <200809082341.m88NfelU095693@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7478700034369782448==" --===============7478700034369782448== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In OpenLDAP 2.3, it was possible to set the rootdn of the main database to be cn=3Dconfig. This no longer works in OpenLDAP 2.4, but seems like it should = be valid to me. Example config: include /opt/zimbra/openldap-2.4.12/etc/openldap/schema/core.schema include "/opt/zimbra/openldap-2.4.12/etc/openldap/schema/cosine.schem= a" include "/opt/zimbra/openldap-2.4.12/etc/openldap/schema/inetorgperso= n.schema" pidfile /opt/zimbra/openldap-2.4.12/var/run/slapd.pid argsfile /opt/zimbra/openldap-2.4.12/var/run/slapd.args modulepath /opt/zimbra/openldap-2.4.12/libexec/openldap moduleload back_hdb.la moduleload back_monitor.la moduleload syncprov.la moduleload accesslog.la database config rootpw secret database monitor rootdn "cn=3Dconfig" access to dn.children=3D"cn=3Dmonitor" by * read database hdb suffix cn=3Daccesslog directory /opt/zimbra/data/openldap/accesslog/db rootdn cn=3Daccesslog index default eq index entryCSN index objectClass index reqEnd index reqResult index reqStart access to dn.subtree=3D"cn=3Daccesslog" by dn.exact=3D"cn=3Dconfig" read by dn.exact=3D"uid=3Dzmreplica,cn=3Dadmins,cn=3Dzimbra" read # Checkpoint the database to prevent transaction loss in unclean shutdowns, a= nd speed up slapd shutdowns. checkpoint 64 5 cachesize 10000 timelimit unlimited sizelimit unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database hdb suffix "" rootdn "cn=3Dconfig" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /opt/zimbra/data/openldap/db # Indices to maintain index objectClass eq index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub # recommended for replication index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited overlay syncprov syncprov-checkpoint 20 10 syncprov-sessionlog 500 overlay accesslog logdb cn=3Daccesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 Slaptest fails with: line 74 (suffix "") >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> line 75 (rootdn "cn=3Dconfig") >>> dnPrettyNormal: <<< dnPrettyNormal: , line 79 (rootpw ***) /opt/zimbra/openldap-2.4.12/etc/openldap/slapd.conf: line 79: can on= ly be set when rootdn is under suffix slaptest: bad configuration file! cn=3Dconfig is *clearly* under "", and changing it to "cn=3Dconfig,dc=3Djunk"= works.=20 So it's specific to the term "cn=3Dconfig". Changing it to "cn=3Djoe" works = just fine. It also doesn't seem to care that I use "cn=3Dconfig" with back-monito= r... --===============7478700034369782448==-- From ando@sys-net.it Tue Sep 9 08:54:19 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Tue, 09 Sep 2008 08:54:19 +0000 Message-ID: <200809090854.m898sJm3040833@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7450705749090202890==" --===============7450705749090202890== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable mateusz.kijowski(a)gmail.com wrote: > Full_Name: Mateusz Kijowski > Version: 2.3.43 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.126.222.22) >=20 >=20 > In some use scenarios, it is useful if the translucent overlay does not for= ward > bind operation requests to the remote server when there are values for > userPassword attribute in the local database. It would be nice if this coul= d be > enabled or disabled by a configuration option. For consistency, enabling th= is > behavior should also affect the PASSMOD extended operation to modify the lo= cal > value of userPassword. The local bind feature has been added to HEAD; please test. As for the=20 passmod feature, that requires a little bit more. 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 ----------------------------------- --===============7450705749090202890==-- From ando@sys-net.it Tue Sep 9 10:10:27 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5690) cn=config cannot be rootdn Date: Tue, 09 Sep 2008 10:10:26 +0000 Message-ID: <200809091010.m89AAQCa045111@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7245268182146149256==" --===============7245268182146149256== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > In OpenLDAP 2.3, it was possible to set the rootdn of the main database to = be > cn=3Dconfig. This no longer works in OpenLDAP 2.4, but seems like it shoul= d be > valid to me. ... > cn=3Dconfig is *clearly* under "" No, cn=3Dconfig is *clearly* under cn=3Dconfig, which comes earlier than "". = As such, auth'ing as cn=3Dconfig will be intercepted by back-config,=20 hence the config error. > and changing it to "cn=3Dconfig,dc=3Djunk" works.=20 > So it's specific to the term "cn=3Dconfig". Changing it to "cn=3Djoe" work= s just > fine. It also doesn't seem to care that I use "cn=3Dconfig" with back-moni= tor... But then you don't need to set rootpw. 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 ----------------------------------- --===============7245268182146149256==-- From andreas.moroder@gmx.net Tue Sep 9 12:45:51 2008 From: andreas.moroder@gmx.net To: openldap-bugs@openldap.org Subject: (ITS#5691) malloc withou check Date: Tue, 09 Sep 2008 12:45:51 +0000 Message-ID: <200809091245.m89CjpDD054377@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7979929353489560926==" --===============7979929353489560926== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in servers/slapd/add.c int the function slap_entry2mods() malloc() is called three times and the result is not checked against NULL. Bye Andreas --===============7979929353489560926==-- From andreas.moroder@gmx.net Tue Sep 9 13:08:45 2008 From: andreas.moroder@gmx.net To: openldap-bugs@openldap.org Subject: (ITS#5692) literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN Date: Tue, 09 Sep 2008 13:08:44 +0000 Message-ID: <200809091308.m89D8iEY055340@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9124695743153179044==" --===============9124695743153179044== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in /servers/slapd/bconfig.c /libraries/libldap_r/tls.c /libraries/libldap_r/tls.c ./libraries/liblber/stdio.c /libraries/liblunicode/ucdata/ucgendat.c /contrib/slapd-modules/lastmod/lastmod.c the literal value 8192 is used for array sizes instead of SLAP_LDAPDN_MAXLEN = 8192 defined in /servers/slapd/slap.h =20 I think this could become a problem if SLAP_LDAPDN_MAXLEN grows in a future release. A question from a newbie: What happens in a mixed environment with a never version with bigger SLAP_LDAPDN_MAXLEN that replicates his entries to a version with SLAP_LDAPDN_MAXLEN at 8192 ? Isn't it wrong not to check for a buffer owerflow when strings are concantena= ted and suppose that the data we use does not exceed the limit ? Bye Andreas --===============9124695743153179044==-- From toby@inf.ed.ac.uk Tue Sep 9 14:01:18 2008 From: toby@inf.ed.ac.uk To: openldap-bugs@openldap.org Subject: Re: (ITS#5665) slapd crashing with slapo-pcache when using attrset "*" Date: Tue, 09 Sep 2008 14:01:18 +0000 Message-ID: <200809091401.m89E1Isd058278@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4868729331911787813==" --===============4868729331911787813== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi again, I haven't been able to reproduce the problem since patching, so I consider it fixed.... Many thanks Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --===============4868729331911787813==-- From ando@sys-net.it Tue Sep 9 15:45:08 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5693) [enhancement] extension of slapo-translucent filtering approach Date: Tue, 09 Sep 2008 15:45:08 +0000 Message-ID: <200809091545.m89Fj8LE067188@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3543568648429769068==" --===============3543568648429769068== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I see a few potential issues in current slapo-translucent(5) filtering approach: - if an attribute is marked as local, it will not be used to filter entries on the remote server; however, that attribute might exist in entries on the remo= te server, resulting in inconsistent search results - the same is also true in the reverse case in those cases, it might be helpful to let the same attribute be listed as lo= cal *and* remote, acting accordingly. Also, there is no way to indicate that some attributes are local and *all the others* are remote (and viceversa); it is suggested to allow "*" (and "+"?), = as well as "1.1" to indicate no attributes. Wildcards would take effect unless attribute specifications are present. I don't know, right now, how easy it would be to implement those enhancements; I'm just noting them here as a reminder for a feature request. p. --===============3543568648429769068==-- From ando@sys-net.it Tue Sep 9 16:02:56 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5692) Re: literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN Date: Tue, 09 Sep 2008 16:02:56 +0000 Message-ID: <200809091602.m89G2uIY071063@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6919089260411713108==" --===============6919089260411713108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit In none of the files you indicated the buffer size 8192 is used for a DN, so I see no reason for hijacking SLAP_LDAPDN_MAXLEN for that purpose. It might be good practice to define one or more macros and consistently use them, although in the specific cases there is no repeated use of the value, nor specific consistency constraints for the use of that value. With respect to your second question, OpenLDAP never relies on SLAP_LDAPDN_MAXLEN stability in terms of buffer access; since that macro is local to slapd, if it changes the whole slapd will see it. The only issue could be with redefinition of the macro across module compilation, if you use dynamic modules. Also in that case things shouldn't be critical, as slapd never relies on that macro for accessing buffers, but rather on actual buffer size. The only potentia issue I see is with spurious syntax errors if a module with larger SLAP_LDAPDN_MAXLEN calls a DN-related validation/normalization function passing a DN whose length is larger than the value of SLAP_LDAPDN_MAXLEN slapd was built with. No buffer overflow risk, though; at most, DoS on uncommonly long DNs. 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 ----------------------------------- --===============6919089260411713108==-- From ando@sys-net.it Tue Sep 9 16:12:11 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5691) Re: malloc without check Date: Tue, 09 Sep 2008 16:12:11 +0000 Message-ID: <200809091612.m89GCBtD072079@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7271426706142012311==" --===============7271426706142012311== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Actually, I see plenty of places where it occurs. I vaguely recall that malloc used to be #defined as ch_malloc within slapd, although I believe it is no longer. In any case, I'm in favor of avoiding those redefinitions, for the sake of clarity. The correct solution should be to replace them with ch_malloc() (same for other memory-related functions, like calloc(), realloc(), strdup() and free(), although the latter is not strictly needed). 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 ----------------------------------- --===============7271426706142012311==-- From quanah@zimbra.com Tue Sep 9 16:41:59 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5690) cn=config cannot be rootdn Date: Tue, 09 Sep 2008 16:41:58 +0000 Message-ID: <200809091641.m89GfwJd074054@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1508841765728856000==" --===============1508841765728856000== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >> it should be valid to me. > > ... > >> cn=config is *clearly* under "" > > No, cn=config is *clearly* under cn=config, which comes earlier than "". > But then you don't need to set rootpw. Ah, I see. So this is more just a behavior change between 2.3 and 2.4. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============1508841765728856000==-- From ando@sys-net.it Tue Sep 9 16:52:22 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5690) cn=config cannot be rootdn Date: Tue, 09 Sep 2008 16:52:21 +0000 Message-ID: <200809091652.m89GqLsx075115@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2967870688075828605==" --===============2967870688075828605== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Quanah Gibson-Mount wrote: > --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)zimbra.com wrote: >> >>> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >>> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >>> it should be valid to me. >> >> ... >> >>> cn=config is *clearly* under "" >> >> No, cn=config is *clearly* under cn=config, which comes earlier than "". >> But then you don't need to set rootpw. > > Ah, I see. So this is more just a behavior change between 2.3 and 2.4. > Thanks! Well, I don't think they changed that much. If you expose cn=config then any DN in that namespace will belong to the back-config; if you don't expose it, then it will belong to "". I think you weren't using the same slapd.conf with 2.3 and 2.4, if you noticed a different behavior. 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 ----------------------------------- --===============2967870688075828605==-- From quanah@zimbra.com Tue Sep 9 16:54:31 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5690) cn=config cannot be rootdn Date: Tue, 09 Sep 2008 16:54:30 +0000 Message-ID: <200809091654.m89GsUbd075810@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5375746611288457462==" --===============5375746611288457462== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, September 09, 2008 4:52 PM +0000 ando(a)sys-net.it wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: >> >>> quanah(a)zimbra.com wrote: >>> >>>> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >>>> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >>>> it should be valid to me. >>> >>> ... >>> >>>> cn=config is *clearly* under "" >>> >>> No, cn=config is *clearly* under cn=config, which comes earlier than "". >>> But then you don't need to set rootpw. >> >> Ah, I see. So this is more just a behavior change between 2.3 and 2.4. >> Thanks! > > Well, I don't think they changed that much. If you expose cn=config > then any DN in that namespace will belong to the back-config; if you > don't expose it, then it will belong to "". I think you weren't using > the same slapd.conf with 2.3 and 2.4, if you noticed a different behavior. Hm, you're right, I mixed parts of a stock 2.4 slapd.conf with my 2.3 slapd.conf. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============5375746611288457462==-- From quanah@zimbra.com Tue Sep 9 18:27:41 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 18:27:41 +0000 Message-ID: <200809091827.m89IRfwb083895@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1315862377562260231==" --===============1315862377562260231== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Quanah Gibson-Mount Version: RE24 9/7/2008 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As reported by David Hawes: http://www.openldap.org/lists/openldap-software/200808/msg00163.html If you load a server that will become the delta-syncrepl master using slapadd -w, the slave will not see changes that occur after the accesslog expires. To confirm this, I did the following: (a) Created a base LDIF file that set up the suffix, a people tree, and a replica user (b) slapadded this LDIF file WITHOUT -w on the master (c) started the master (d) started the replica All data was replicated correctly (e) Stopped the replica (f) Added 6 users, and then deleted one (g) waited for the accesslog to expire (h) started the replica All data was replicated correctly (i) did a slapcat of the master (j) stopped the master and replica (k) deleted the database on the master and replica (l) Used slapadd -w to restore my slapcat of 5 users (m) started the replica, verified the contents were the same (n) stopped the replica (o) added a user on the master (p) waited for the accesslog to expire (q) started the replica The user I added was not replicated, and now the databases are inconsistent. --===============1315862377562260231==-- From quanah@zimbra.com Tue Sep 9 18:49:53 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 18:49:53 +0000 Message-ID: <200809091849.m89Inr9x086997@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6290375693938442788==" --===============6290375693938442788== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, September 09, 2008 6:27 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 9/7/2008 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > As reported by David Hawes: > > http://www.openldap.org/lists/openldap-software/200808/msg00163.html > > If you load a server that will become the delta-syncrepl master using > slapadd -w, the slave will not see changes that occur after the accesslog > expires. Additionally did the following: Stopped the replica again, purged its db, restarted it so it got a fresh sync from the master (all users present). stopped the replica, added a new user on the master, let it expire from the accesslog db. started the replica. New user is not replicated. So it essentially appears that once -w is used to slapadd a master, no replica will be consistent if changes occur that are purged before the replica gets them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============6290375693938442788==-- From ando@sys-net.it Tue Sep 9 18:51:22 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 18:51:22 +0000 Message-ID: <200809091851.m89IpMOs087485@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7929428597141230641==" --===============7929428597141230641== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I thuink the issue is related to the fact that slapadd -w uses bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) does not implement those hooks. As a consequence, any modification to the context entry is not reflected in slapo-accesslog(5). However, I don't see how this should affect replication, since a consistent database, after slapcatt'ing, should generate a ldif with the correct contextCSN. However, if you slapcat before stopping the producer, the resulting ldif will not contain the contextCSN, because after a fresh slapadd without -w it's kept in memory until the producer is stopped. You should try (i) stop the master and replica (j) do a slapcat of the master (k) delete the database on the master and replica (l) Use slapadd -w to restore your slapcat of 5 users (m) start the replica, verify the contents are the same (n) stop the replica (o) add a user on the master (p) wait for the accesslog to expire (q) start the replica In the meanwhile, you should check what contextCSN your consumers have after syncing from a producer loaded without -w. 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 ----------------------------------- --===============7929428597141230641==-- From quanah@zimbra.com Tue Sep 9 18:55:45 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 18:55:45 +0000 Message-ID: <200809091855.m89ItjOC088513@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2113692153493017487==" --===============2113692153493017487== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati wrote: > I thuink the issue is related to the fact that slapadd -w uses > bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) > does not implement those hooks. As a consequence, any modification to > the context entry is not reflected in slapo-accesslog(5). > > However, I don't see how this should affect replication, since a > consistent database, after slapcatt'ing, should generate a ldif with the > correct contextCSN. However, if you slapcat before stopping the > producer, the resulting ldif will not contain the contextCSN, because > after a fresh slapadd without -w it's kept in memory until the producer > is stopped. You should try It should be possible to restore a working provider/slave relationship from a hot slapcat taken at any point in time. I'll give what you suggested a try, but this is still a serious bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============2113692153493017487==-- From ando@sys-net.it Tue Sep 9 19:00:05 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 19:00:05 +0000 Message-ID: <200809091900.m89J05Se089289@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5046599325661355528==" --===============5046599325661355528== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Quanah Gibson-Mount wrote: > --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati > wrote: > >> I thuink the issue is related to the fact that slapadd -w uses >> bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) >> does not implement those hooks. As a consequence, any modification to >> the context entry is not reflected in slapo-accesslog(5). >> >> However, I don't see how this should affect replication, since a >> consistent database, after slapcatt'ing, should generate a ldif with the >> correct contextCSN. However, if you slapcat before stopping the >> producer, the resulting ldif will not contain the contextCSN, because >> after a fresh slapadd without -w it's kept in memory until the producer >> is stopped. You should try > > It should be possible to restore a working provider/slave relationship > from a hot slapcat taken at any point in time. Well, actually slapadd -w should suffice. As an alternative, slapcat could support -w as well, for symmetry, so that consistent ldifs can be generated. > I'll give what you suggested a try, but this is still a serious bug. There's something I don't clearly get. As far as I understand, you are saying that consumers lose sync when the log database is purged before they have a chance to sync (because they were down). I don't see how they could sync, then. Of course, there should be a means for slapo-syncprov(5) to tell that, and force a refresh. 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 ----------------------------------- --===============5046599325661355528==-- From quanah@zimbra.com Tue Sep 9 19:09:14 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 19:09:13 +0000 Message-ID: <200809091909.m89J9DD2090429@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9013882325793713739==" --===============9013882325793713739== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati wrote: >> I'll give what you suggested a try, but this is still a serious bug. > > There's something I don't clearly get. As far as I understand, you are > saying that consumers lose sync when the log database is purged before > they have a chance to sync (because they were down). I don't see how > they could sync, then. Of course, there should be a means for > slapo-syncprov(5) to tell that, and force a refresh. Because the consumer is supposed to do a full refresh if they find their context CSN doesn't match the contextCSN of the master. See ITS#5376, ITS#5378, ITS#5465, ITS#5493, ITS#5282 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============9013882325793713739==-- From hyc@symas.com Tue Sep 9 19:19:28 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 19:19:27 +0000 Message-ID: <200809091919.m89JJRQu091610@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0948701610836658227==" --===============0948701610836658227== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit quanah(a)zimbra.com wrote: > --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati > wrote: > > >>> I'll give what you suggested a try, but this is still a serious bug. >> There's something I don't clearly get. As far as I understand, you are >> saying that consumers lose sync when the log database is purged before >> they have a chance to sync (because they were down). I don't see how >> they could sync, then. Of course, there should be a means for >> slapo-syncprov(5) to tell that, and force a refresh. > > Because the consumer is supposed to do a full refresh if they find their > context CSN doesn't match the contextCSN of the master. Not quite. More precisely, the provider is supposed to tell the consumer that the consumer's cookie is out of date if the cookie is older than anything in the provider, and the consumer asked for the reload Hint. Otherwise the provider just sees the consumer is stale and returns a full dump implicitly. In plain syncrepl the consumer never asks for the reload hint. In delta-sync the consumer does ask for a reload hint, because that tells it to do a sync from the main DB instead of the log DB. It sounds like if there's a bug here, it's caused by the logdb's provider not sending a reload hint when it should. > See ITS#5376, ITS#5378, ITS#5465, ITS#5493, ITS#5282 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============0948701610836658227==-- From quanah@zimbra.com Tue Sep 9 19:29:03 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 19:29:02 +0000 Message-ID: <200809091929.m89JT2GG092932@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0350464379756579967==" --===============0350464379756579967== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, September 09, 2008 12:19 PM -0700 Howard Chu wrote: > quanah(a)zimbra.com wrote: >> --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati >> wrote: >> >> >>>> I'll give what you suggested a try, but this is still a serious bug. >>> There's something I don't clearly get. As far as I understand, you are >>> saying that consumers lose sync when the log database is purged before >>> they have a chance to sync (because they were down). I don't see how >>> they could sync, then. Of course, there should be a means for >>> slapo-syncprov(5) to tell that, and force a refresh. >> >> Because the consumer is supposed to do a full refresh if they find their >> context CSN doesn't match the contextCSN of the master. > > Not quite. More precisely, the provider is supposed to tell the consumer > that the consumer's cookie is out of date if the cookie is older than > anything in the provider, and the consumer asked for the reload Hint. > Otherwise the provider just sees the consumer is stale and returns a full > dump implicitly. Well, the consumer's definitely not acting on a full dump in either case. :/ In my latest test, after the purge, I have: # accesslog dn: cn=accesslog contextCSN: 20080909190440.484524Z#000000#000#000000 dn: contextCSN: 20080909190440.484524Z#000000#000#000000 on the master and contextCSN: 20080909183254.258851Z#000000#000#000000 on the replica prior to starting it. SO the replica is clearly behind. The new entry on the master is: dn: uid=qtest7,cn=admins,cn=zimbra entryCSN: 20080909190440.484524Z#000000#000#000000 which matches the CSN on both the main DB and accesslog DB. now, staring the replica, we find: contextCSN: 20080909190440.484524Z#000000#000#000000 So, it believes it has sync'd now, but uid=qtest7 doesn't exist! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============0350464379756579967==-- From quanah@zimbra.com Tue Sep 9 20:19:57 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 20:19:57 +0000 Message-ID: <200809092019.m89KJvsl096235@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3714731525594212835==" --===============3714731525594212835== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati >> wrote: >> >>> I thuink the issue is related to the fact that slapadd -w uses >>> bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) >>> does not implement those hooks. As a consequence, any modification to >>> the context entry is not reflected in slapo-accesslog(5). >>> >>> However, I don't see how this should affect replication, since a >>> consistent database, after slapcatt'ing, should generate a ldif with the >>> correct contextCSN. However, if you slapcat before stopping the >>> producer, the resulting ldif will not contain the contextCSN, because >>> after a fresh slapadd without -w it's kept in memory until the producer >>> is stopped. You should try Just to be clear here, I'm slapcating a provider while it is running, then stopping the provider and the replica, wiping both their dbs, then using slapadd -w to reload the *provider* and syncrepl to load the consumer. Thus I don't see whether or not the CSN is in memory at the time on the *provider* matters much. Particularly given that if I stop the reloaded provider and restart it (i.e., flushing the context CSN), I still get the same behavior problems on the replica. I.e., the replica has never been loaded via slapadd, only the provider, and the provider has been stopped started since the slapadd. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3714731525594212835==-- From ando@sys-net.it Tue Sep 9 20:22:29 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl Date: Tue, 09 Sep 2008 20:22:29 +0000 Message-ID: <200809092022.m89KMTiP096998@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4223677362781263425==" --===============4223677362781263425== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Quanah Gibson-Mount wrote: > Just to be clear here, I'm slapcating a provider while it is running, > then stopping the provider and the replica, wiping both their dbs, then > using slapadd -w to reload the *provider* and syncrepl to load the > consumer. Thus I don't see whether or not the CSN is in memory at the > time on the *provider* matters much. Right, it shouldn't matter, since either it is equal to what -w would generate, or -w would overwrite it with the correct value anyway. The only case I see is if the last operation was a delete, then the contextCSN on the provider would be greater than what a slapadd -w would generate. > Particularly given that if I stop > the reloaded provider and restart it (i.e., flushing the context CSN), I > still get the same behavior problems on the replica. I.e., the replica > has never been loaded via slapadd, only the provider, and the provider > has been stopped started since the slapadd. In fact, I could easily reproduce the behavior you pointed out. 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 ----------------------------------- --===============4223677362781263425==-- From ando@sys-net.it Wed Sep 10 10:19:37 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5694) Date: Wed, 10 Sep 2008 10:19:37 +0000 Message-ID: <200809101019.m8AAJbGa074370@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5884933843990623495==" --===============5884933843990623495== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Works for me, after Howard's fix. 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 ----------------------------------- --===============5884933843990623495==-- From hyc@symas.com Wed Sep 10 23:10:39 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5668) Invalid entryCSN generated, and slapd will not restart Date: Wed, 10 Sep 2008 23:10:39 +0000 Message-ID: <200809102310.m8ANAdGP032722@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2857683614823834961==" --===============2857683614823834961== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit emmanuel.duru(a)atosorigin.com wrote: > I am running windows 32 bits. > Here is what I get from my debugging session: > After QueryPerformanceCounter(&count ), count.QuadPart is worth > 4243738405535005 > So the overflow comes from count.QuadPart *= 1000000; I see. There's no reason we should be computing against the full value of the count; since we're only looking for the microsecond portion we should have stripped off everything greater. (E.g., count.QuadPart %= cFreq.QuadPart). I'll have to play with this code a bit more, there's probably a better way to isolate the microseconds. PS: I guess that means your Windows machine had an uptime of several days. Quite impressive, for Windows... ;) > > >> -----Message d'origine----- >> De : Howard Chu [mailto:hyc(a)symas.com] >> Envoyé : mercredi 27 août 2008 13:08 >> À : openldap-its(a)openldap.org; Emmanuel Duru >> Objet : Re: (ITS#5668) Invalid entryCSN generated, and slapd will not >> restart >> >> ando(a)sys-net.it wrote: >>> emmanuel.duru(a)atosorigin.com wrote: >>>> I see that tm->tm_usub is negative, there seems to be overflows between >>>> LARGE_INTEGER and int variables. >> It would take over 4 billion operations in a single timer tick (on the >> order >> of nanoseconds) to make tm_usub overflow. That seems pretty unlikely. >> >>> If the problem disappears by initializing the static variables in >>> lutil_gettime(), then it might be a compiler issue. >> I suppose that's always possible... >> >> The original post shows that the tm_usec field is negative. That could >> happen >> if the offset we computed between the SYSTEMTIME and the >> PerformanceCounter >> was wrong, or if the SYSTEMTIME was adjusted while the process was >> running. >> >> What version of Windows are you running? 32 or 64 bit? Can you singlestep >> through this function with a debugger and verify all of the values? I >> haven't >> run this code on Windows in a long time, would take a bit of effort to >> resurrect my build environment. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============2857683614823834961==-- From h.b.furuseth@usit.uio.no Thu Sep 11 10:42:04 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5668) Invalid entryCSN generated, and slapd will not restart Date: Thu, 11 Sep 2008 10:42:04 +0000 Message-ID: <200809111042.m8BAg4xv029510@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7254163447612940694==" --===============7254163447612940694== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Looking at liblutil/utils.c:lutil_gettime() led me to Beware of QueryPerformanceCounter() http://www.virtualdub.org/blog/pivot/entry.php?id=106 Is warning relevant to slapd? I don't know Windows programming at all. -- Hallvard --===============7254163447612940694==-- From emmanuel.duru@atosorigin.com Thu Sep 11 11:43:39 2008 From: emmanuel.duru@atosorigin.com To: openldap-bugs@openldap.org Subject: RE: (ITS#5668) Invalid entryCSN generated, and slapd will not restart Date: Thu, 11 Sep 2008 11:43:39 +0000 Message-ID: <200809111143.m8BBhdsm048900@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3232988499276464585==" --===============3232988499276464585== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit OK, it works. --===============3232988499276464585==-- From tamburo@studenti.unina.it Thu Sep 11 14:54:04 2008 From: tamburo@studenti.unina.it To: openldap-bugs@openldap.org Subject: (ITS#5695) AC syntax in OpenLDAP Date: Thu, 11 Sep 2008 14:54:03 +0000 Message-ID: <200809111454.m8BEs3Pw003191@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7308421773681600075==" --===============7308421773681600075== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Tamburo Luca Version: cvs OS: URL: ftp://ftp.openldap.org/incoming/Tamburo-Luca-AC-08-09-11.tgz Submission from: (NULL) (82.51.134.108) Hi, I'm a student at University "Federico II" (Napoli, Italy). For my bachelor degree I have worked on LDAP and Attribute Certicates. My main source has been Standard X.509 (2000). More precisely I have implemented a function to validate AC syntax, and the equality matching rule "attribute Certificate Exact Match" as defined in Internet Draft: "Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PMIs" (by D. Chadwick and S.Legg, 27 June 2002). I have changed the file servers/slapd/schema_init.c; I needed to create a new schema file called guest.schema which contains the definitions of objectclass pmiUser and the attribute type attributeCertificateAttribute. Link for the archive is ftp://ftp.openldap.org/incoming/Tamburo-Luca-AC-08-09-11.tgz Thanks in advance for your attention. Best regards, Luca Tamburo --===============7308421773681600075==-- From rmeggins@redhat.com Thu Sep 11 15:18:51 2008 From: rmeggins@redhat.com To: openldap-bugs@openldap.org Subject: (ITS#5696) Patch - support Mozilla NSS for crypto operations Date: Thu, 11 Sep 2008 15:18:51 +0000 Message-ID: <200809111518.m8BFIpjx008505@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6069985056175728609==" --===============6069985056175728609== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Rich Megginson Version: 2.4.11 and current HEAD OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch Submission from: (NULL) (76.113.59.19) This patch allows OpenLDAP to use Mozilla NSS for crypto. The approach uses = the nss_compat_ossl library. This library allows the code to use the current OpenSSL API so that the changes to the actual OpenLDAP code are minimized. T= his is the same approach that has been used to port several other packages to use NSS instead of OpenSSL as part of the Fedora Crypto Consolidation project. The nss_compat_ossl library is here - http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ - it is also included with Fedora --===============6069985056175728609==-- From ando@sys-net.it Thu Sep 11 17:58:33 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5695) AC syntax in OpenLDAP Date: Thu, 11 Sep 2008 17:58:32 +0000 Message-ID: <200809111758.m8BHwWcP043387@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7629239293308144131==" --===============7629239293308144131== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit bash-3.2$ wget ftp://ftp.openldap.org/incoming/Tamburo-Luca-AC-08-09-11.tgz --19:53:57-- ftp://ftp.openldap.org/incoming/Tamburo-Luca-AC-08-09-11.tgz => `Tamburo-Luca-AC-08-09-11.tgz' Resolving ftp.openldap.org... 204.152.186.57, 2001:4f8:3:ba:2e0:18ff:fe02:efec Connecting to ftp.openldap.org|204.152.186.57|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /incoming ... done. ==> SIZE Tamburo-Luca-AC-08-09-11.tgz ... done. ==> PASV ... done. ==> RETR Tamburo-Luca-AC-08-09-11.tgz ... No such file `Tamburo-Luca-AC-08-09-11.tgz'. Could you please provide a pointer to the exact link? 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 ----------------------------------- --===============7629239293308144131==-- From hyc@symas.com Thu Sep 11 19:14:47 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5668) Invalid entryCSN generated, and slapd will not restart Date: Thu, 11 Sep 2008 19:14:47 +0000 Message-ID: <200809111914.m8BJElh4060703@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8503571856269928762==" --===============8503571856269928762== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hallvard B Furuseth wrote: > Looking at liblutil/utils.c:lutil_gettime() led me to > > Beware of QueryPerformanceCounter() > http://www.virtualdub.org/blog/pivot/entry.php?id=3D106 > > Is warning relevant to slapd? I don't know Windows programming at all. > Yes, it's relevant. People running on Windows should probably boot with=20 /usepmtimer to make sure the ACPI timer is used (which runs at 3.5MHz). Then = again, the simplest solution is "don't run mission-critical servers on=20 Windows" because the platform is so completely inadequate, for this and many = other reasons. Probably should read this as well http://support.microsoft.com/kb/895980 Of course, not all of this uncertainty is Microsoft's fault - AMD documented = that their dual-core processors would keep their TSCs in sync between both=20 cores, but in reality the TSCs never stay in sync. So if you happen to be=20 running an old-enough Windows release, written when the TSC was still believe= d=20 to be a reliable clock source, you may have problems unless you explicitly=20 tell Windows to use the ACPI PM timer. If you're running on a very old motherboard that doesn't support ACPI, you=20 won't have a PM timer to use; but in that case you're probably also running=20 with a processor that doesn't have TSC issues. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============8503571856269928762==-- From hyc@symas.com Thu Sep 11 20:55:07 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations Date: Thu, 11 Sep 2008 20:55:07 +0000 Message-ID: <200809112055.m8BKt7oV073790@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6105652125299407160==" --===============6105652125299407160== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.11 and current HEAD > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch > Submission from: (NULL) (76.113.59.19) > > > This patch allows OpenLDAP to use Mozilla NSS for crypto. The approach use= s the > nss_compat_ossl library. This library allows the code to use the current > OpenSSL API so that the changes to the actual OpenLDAP code are minimized. = This > is the same approach that has been used to port several other packages to u= se > NSS instead of OpenSSL as part of the Fedora Crypto Consolidation project. > > The nss_compat_ossl library is here - > http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ - it= is > also included with Fedora Thanks for the patch. Some notes - for future reference, don't include diffs = to generated files (e.g. configure), just include the diffs to the source=20 (e.g. configure.in). Since "NSS" already has a well-established meaning in=20 POSIX environments (Name Service Switch), I've been referring to this as=20 MozNSS (Mozilla NSS) to avoid confusion. Also, there's already a working implementation of Mozilla NSS support in HEAD= ,=20 but your patch covers a lot of areas I didn't look at yet (SHA1 hashing, etc)= =20 so we'll probably cherrypick pieces of your patch to merge. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6105652125299407160==-- From hyc@symas.com Thu Sep 11 20:59:25 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations Date: Thu, 11 Sep 2008 20:59:24 +0000 Message-ID: <200809112059.m8BKxOIu074474@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7086799616196234967==" --===============7086799616196234967== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.11 and current HEAD >> OS: Fedora >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch >> Submission from: (NULL) (76.113.59.19) >> This patch allows OpenLDAP to use Mozilla NSS for crypto. The approach us= es the >> nss_compat_ossl library. This library allows the code to use the current >> OpenSSL API so that the changes to the actual OpenLDAP code are minimized.= This >> is the same approach that has been used to port several other packages to = use >> NSS instead of OpenSSL as part of the Fedora Crypto Consolidation project. > Thanks for the patch. Some notes - for future reference, don't include diffs > to generated files (e.g. configure), just include the diffs to the source > (e.g. configure.in). Since "NSS" already has a well-established meaning in > POSIX environments (Name Service Switch), I've been referring to this as > MozNSS (Mozilla NSS) to avoid confusion. Also please read http://www.openldap.org/devel/contributing.html ; you haven'= t=20 provided any of the required IPR notices. We can't touch the submission=20 without them. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7086799616196234967==-- From hyc@OpenLDAP.org Thu Sep 11 21:03:30 2008 From: hyc@OpenLDAP.org To: openldap-bugs@openldap.org Subject: (ITS#5697) Typo on contributing guidelines Date: Thu, 11 Sep 2008 21:03:29 +0000 Message-ID: <200809112103.m8BL3Thu075224@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4851578373494382146==" --===============4851578373494382146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Howard Chu Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc On http://www.openldap.org/devel/contributing.html Index: contributing.wml =================================================================== RCS file: /repo/OpenLDAP/www/pages/devel/contributing.wml,v retrieving revision 1.30 diff -u -r1.30 contributing.wml --- contributing.wml 3 Apr 2008 21:59:54 -0000 1.30 +++ contributing.wml 11 Sep 2008 21:02:23 -0000 @@ -195,7 +195,7 @@ If you have assigned rights and/or interest in this work to another party, such as your employer (possibly through your employment agreement), you must state which rights you have assigned and to -whom. For instance, "By virtual of my employment agreement with +whom. For instance, "By virtue of my employment agreement with EMPLOYER-NAME, I have assigned my rights and interest in this work to EMPLOYER-NAME." --===============4851578373494382146==-- From rmeggins@redhat.com Thu Sep 11 21:04:16 2008 From: rmeggins@redhat.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations Date: Thu, 11 Sep 2008 21:04:16 +0000 Message-ID: <200809112104.m8BL4GZ7075865@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5356746912270129489==" --===============5356746912270129489== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is a cryptographically signed message in MIME format. --------------ms030000020803000108060801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.11 and current HEAD >> OS: Fedora >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch >> Submission from: (NULL) (76.113.59.19) >> >> >> This patch allows OpenLDAP to use Mozilla NSS for crypto. The >> approach uses the >> nss_compat_ossl library. This library allows the code to use the >> current >> OpenSSL API so that the changes to the actual OpenLDAP code are >> minimized. This >> is the same approach that has been used to port several other >> packages to use >> NSS instead of OpenSSL as part of the Fedora Crypto Consolidation >> project. >> >> The nss_compat_ossl library is here - >> http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ >> - it is >> also included with Fedora > > Thanks for the patch. Some notes - for future reference, don't include > diffs to generated files (e.g. configure), just include the diffs to > the source (e.g. configure.in). Ok. Sorry about that. I've just been applying this patch for testing, but yeah, you will just regenerate configure. > Since "NSS" already has a well-established meaning in POSIX > environments (Name Service Switch), I've been referring to this as > MozNSS (Mozilla NSS) to avoid confusion. Ok. Yeah, it's very confusing. The nss developers haven't run into this problem that much yet - but nss is used quite heavily in the ldap space (nss_ldap etc.) > > Also, there's already a working implementation of Mozilla NSS support > in HEAD, but your patch covers a lot of areas I didn't look at yet > (SHA1 hashing, etc) so we'll probably cherrypick pieces of your patch > to merge. Ok. Sounds good. --------------ms030000020803000108060801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEFcdcRwRB8xs7lDIZBO/bfowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTIwNDE2MzM1OVoX DTA4MTIwMzE2MzM1OVowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANpEUJJ++jpsDRmNt7cla8gygzXXoOHCPCubSxG0juJoxS/4F1UiyVSy0Gzb C5lVZemRenB+G389Ai11jLKp97S1abeQII26poIkjvYJCjyO92SJNFvb8mz6bkBW9NcH2zBt odjoeCvdlKuwxg1IX/kYsmz4lirjIVPFPSyqx7jgYhuNpjfR3oUuNRLx5Y6i9Ep+1AmTkoWx NNwMNFwRUOh78z/Gvh9exCB8Xldd58egHfYluBraFi5IgkGQneI4+VyFrNwwX1XtjI2EmDrO HnMTZGnkYBH5L6b54bMkIKxMmZrmdzcyQ0JLbz2GZqKo5BUaN4M1M2kTCy0HbKOlhZECAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAELh1VaZchhZmlX93Wmbu8loeXNOP5/RRJVHCgom1N7g4YZBcBwM 1bmoo5b9gK3IPrPxZu2zYuyxwveNM0KdmaYtLzWiStJyifMDb8FtMNvVc5oewQK5tnDUw3dG MH/TxiE/hEZiRjAVylPiwzq47PjVPIM87Rek8hROvCkaEO6hMIIC4DCCAkmgAwIBAgIQVx1x HBEHzGzuUMhkE79t+jANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDcxMjA0MTYzMzU5WhcNMDgxMjAzMTYzMzU5WjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kRQkn76 OmwNGY23tyVryDKDNdeg4cI8K5tLEbSO4mjFL/gXVSLJVLLQbNsLmVVl6ZF6cH4bfz0CLXWM sqn3tLVpt5AgjbqmgiSO9gkKPI73ZIk0W9vybPpuQFb01wfbMG2h2Oh4K92Uq7DGDUhf+Riy bPiWKuMhU8U9LKrHuOBiG42mN9HehS41EvHljqL0Sn7UCZOShbE03Aw0XBFQ6HvzP8a+H17E IHxeV13nx6Ad9iW4GtoWLkiCQZCd4jj5XIWs3DBfVe2MjYSYOs4ecxNkaeRgEfkvpvnhsyQg rEyZmuZ3NzJDQktvPYZmoqjkFRo3gzUzaRMLLQdso6WFkQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA QuHVVplyGFmaVf3daZu7yWh5c04/n9FElUcKCibU3uDhhkFwHAzVuaijlv2Arcg+s/Fm7bNi 7LHC940zQp2Zpi0vNaJK0nKJ8wNvwW0w29Vzmh7BArm2cNTDd0Ywf9PGIT+ERmJGMBXKU+LD Orjs+NU8gzztF6TyFE68KRoQ7qEwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFcd cRwRB8xs7lDIZBO/bfowCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDgwOTExMjEwMjU3WjAjBgkqhkiG9w0BCQQxFgQUgrlU70hz emgL9UroY5tdya2gFvQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQVx1xHBEHzGzuUMhkE79t+jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVx1xHBEHzGzu UMhkE79t+jANBgkqhkiG9w0BAQEFAASCAQAd2tnYv6GJIgrUuiqErc/NxB904FghsimijiCx jd4WqQ6hK4rJMvq39V8ZYThQoSHhp+w6SjztTwjv6PIMibDl9ZyIIp2d8GexMsxemIRWMMp4 K955F5ZcyB9skETGGOV77adbPebwdLHAk8//oNx75bSw786gr8vxaxu9iYR79fuZNsgzQewS 4u/+9vOxAROy6VMQ+2ZW0hcca/gZLGkIjKL16GRVVAdkHmhHSu3zIOQsmrtX9uzuDyPl+Nrj nKySb2vCjn+G/VDeKmtWOHfV0aBbBOUBzdLBG8qvNS2HvNZrAJPxIwv+RTn5sHREGjDe8KWO EOPq+KbmlM06Ccy4AAAAAAAA --------------ms030000020803000108060801-- --===============5356746912270129489==-- From rmeggins@redhat.com Fri Sep 12 01:59:59 2008 From: rmeggins@redhat.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations Date: Fri, 12 Sep 2008 01:59:58 +0000 Message-ID: <200809120159.m8C1xwWm084372@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0301733567921915525==" --===============0301733567921915525== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is a cryptographically signed message in MIME format. --------------ms030502050400050400000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The following is from the person who developed the patch: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Robert Relyea am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --------------ms030502050400050400000609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEFcdcRwRB8xs7lDIZBO/bfowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTIwNDE2MzM1OVoX DTA4MTIwMzE2MzM1OVowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANpEUJJ++jpsDRmNt7cla8gygzXXoOHCPCubSxG0juJoxS/4F1UiyVSy0Gzb C5lVZemRenB+G389Ai11jLKp97S1abeQII26poIkjvYJCjyO92SJNFvb8mz6bkBW9NcH2zBt odjoeCvdlKuwxg1IX/kYsmz4lirjIVPFPSyqx7jgYhuNpjfR3oUuNRLx5Y6i9Ep+1AmTkoWx NNwMNFwRUOh78z/Gvh9exCB8Xldd58egHfYluBraFi5IgkGQneI4+VyFrNwwX1XtjI2EmDrO HnMTZGnkYBH5L6b54bMkIKxMmZrmdzcyQ0JLbz2GZqKo5BUaN4M1M2kTCy0HbKOlhZECAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAELh1VaZchhZmlX93Wmbu8loeXNOP5/RRJVHCgom1N7g4YZBcBwM 1bmoo5b9gK3IPrPxZu2zYuyxwveNM0KdmaYtLzWiStJyifMDb8FtMNvVc5oewQK5tnDUw3dG MH/TxiE/hEZiRjAVylPiwzq47PjVPIM87Rek8hROvCkaEO6hMIIC4DCCAkmgAwIBAgIQVx1x HBEHzGzuUMhkE79t+jANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDcxMjA0MTYzMzU5WhcNMDgxMjAzMTYzMzU5WjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kRQkn76 OmwNGY23tyVryDKDNdeg4cI8K5tLEbSO4mjFL/gXVSLJVLLQbNsLmVVl6ZF6cH4bfz0CLXWM sqn3tLVpt5AgjbqmgiSO9gkKPI73ZIk0W9vybPpuQFb01wfbMG2h2Oh4K92Uq7DGDUhf+Riy bPiWKuMhU8U9LKrHuOBiG42mN9HehS41EvHljqL0Sn7UCZOShbE03Aw0XBFQ6HvzP8a+H17E IHxeV13nx6Ad9iW4GtoWLkiCQZCd4jj5XIWs3DBfVe2MjYSYOs4ecxNkaeRgEfkvpvnhsyQg rEyZmuZ3NzJDQktvPYZmoqjkFRo3gzUzaRMLLQdso6WFkQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA QuHVVplyGFmaVf3daZu7yWh5c04/n9FElUcKCibU3uDhhkFwHAzVuaijlv2Arcg+s/Fm7bNi 7LHC940zQp2Zpi0vNaJK0nKJ8wNvwW0w29Vzmh7BArm2cNTDd0Ywf9PGIT+ERmJGMBXKU+LD Orjs+NU8gzztF6TyFE68KRoQ7qEwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFcd cRwRB8xs7lDIZBO/bfowCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDgwOTEyMDE1ODU5WjAjBgkqhkiG9w0BCQQxFgQUia3iQGIt gUDrIWJABkXGXDP2uO0wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQVx1xHBEHzGzuUMhkE79t+jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVx1xHBEHzGzu UMhkE79t+jANBgkqhkiG9w0BAQEFAASCAQCxIfkCUbjvfwVycRf8HdSbkjTeYjkd18E9+gHw 6Lvbs3UYzlWj8yZSynu15jPPg6KhqwX3kG7mVJybQtGpVLt5PMjp+OgIspDWIHOk5bhw/CW7 0OqtZwEVHH1tCIPKIeCHWlRq367W6DKy0SUs843IRpPa8o1YgxLGIIhp4BBxrdx6/Ep7WUtk PvA1mDRcrVQceTzJoHnwe56bSNXnkCrsYA94NAd4NFmRSoE8JVeWWgBBbgI3IEEvINTC+pM3 nbh1gOxxBMFtw2JFufrWnCGnXyVKy5rfPL8BPI3ul6N1AurDhTNbAXOHJkz+OZLOlMxyKJA9 s7ua54QILncIuSWzAAAAAAAA --------------ms030502050400050400000609-- --===============0301733567921915525==-- From rhafer@suse.de Fri Sep 12 07:46:33 2008 From: rhafer@suse.de To: openldap-bugs@openldap.org Subject: (ITS#5698) slapd crashes after trying to add an invalid database entry Date: Fri, 12 Sep 2008 07:46:32 +0000 Message-ID: <200809120746.m8C7kWJB005604@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8900488779365963310==" --===============8900488779365963310== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.152.188) slapd segfaults after trying to add an invalid database entry to cn=3Dconfig.= E.g. I used this one to reproduce the problem (substring index is not allowed for objectclass): dn: olcdatabase=3Dhdb,cn=3Dconfig objectclass: olchdbconfig olcdatabase: hdb olcsuffix: cn=3Dtest olcdbdirectory: /tmp olcdbcheckpoint: 3 5 olcdbindex: objectclass sub It crashes in the checkpoint runqueue task, which it seems has not be removed after the failed ADD operation: #0 0x000000000052303e in hdb_checkpoint (ctx=3D0x41f81dd0, arg=3D0xb1bfb0) at config.c:181 #1 0x00007f3cbcdd502f in ldap_int_thread_pool_wrapper (xpool=3D0x8ec640) at ../../../libraries/libldap_r/tpool.c:663 #2 0x00007f3cb9d73040 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f3cb9ae60cd in clone () from /lib64/libc.so.6 A fix is on the way to HEAD. --===============8900488779365963310==-- From tamburo@studenti.unina.it Fri Sep 12 13:33:51 2008 From: tamburo@studenti.unina.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5695) AC syntax in OpenLDAP Date: Fri, 12 Sep 2008 13:33:51 +0000 Message-ID: <200809121333.m8CDXp8o028573@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0125445422197362229==" --===============0125445422197362229== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry for error the correct link is http://www.studenti.unina.it/~tamburo/tesi/openldap/Luca-Tamburo-AC-08-09-11.= tgz I have a problem with public ftp. Luca Tamburo ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. --===============0125445422197362229==-- From ando@sys-net.it Sat Sep 13 14:47:53 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5699) lutil_str2bin fails for certain hex values Date: Sat, 13 Sep 2008 14:47:52 +0000 Message-ID: <200809131447.m8DElqD1001667@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5559915530303809627==" --===============5559915530303809627== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pierangelo Masarati Version: HEAD OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When passed "'E31ED28BA060532F'H", lutil_str2bin() fails because calls strtol= () passing it the first 8 hex digits ("E31ED28B"), which is larger than the larg= est long it can handle. Not sure about how to fix it (probably, it should use strtoul instead). p. --===============5559915530303809627==-- From ando@sys-net.it Sat Sep 13 16:45:25 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5695) AC syntax in OpenLDAP Date: Sat, 13 Sep 2008 16:45:25 +0000 Message-ID: <200809131645.m8DGjPXi006312@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4213369481077763234==" --===============4213369481077763234== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable tamburo(a)studenti.unina.it wrote: > Sorry for error the correct link is=20 > http://www.studenti.unina.it/~tamburo/tesi/openldap/Luca-Tamburo-AC-08-09-1= 1.tgz >=20 Thanks for the contribution. I gave a look at it, and seems to be fine, although I need to check something with X.509. I wonder if and how much you tested it, since while playing with it I found what I believe is a severe issue in lutil_str2bin(), which is used also in your code... (see ITS#5699). I also have a concern with respect to the IPR declaration on top of your patch, though. You state: > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Luca Tamburo at ICAR, Branch of Naples, > Italy. Luca Tamburo has not assigned rights and/or interest in this > work to any party. I, Giovanni Schmid, project manager at ICAR, am > authorized by Luca Tamburo, my employer, to release this work under > the following terms. It sounds like you are authorizing Giovanni Schmid, project manager at=20 ICAR, to release your work, or something like that? I think you should=20 clarify it a little bit. In any case, I'd leave all issues about IPR to=20 the OpenLDAP foundation; as soon as it's clarified, I'll commit your=20 patch (with some modifications). 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 ----------------------------------- --===============4213369481077763234==-- From ando@sys-net.it Sun Sep 14 22:15:33 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5695) AC syntax in OpenLDAP Date: Sun, 14 Sep 2008 22:15:32 +0000 Message-ID: <200809142215.m8EMFW1E062411@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6523039362495154327==" --===============6523039362495154327== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Other comments: - you seem to have hijacked the OIDs for the AttributeCertificate and attributeCertificateExactAssertion syntaxes. I'll generate two under the OpenLDAP experimental arc, unless anyone can point me to any officially assigned. I don't think so, as the only document I could locate on the topic is a draft expired in 2001 (draft-ietf-pkix-ldap-schema), with no OID assigned by IANA. - as far as I can understand, the attributeCertificateExactAssertion allows more options; a fairly generic case would be { serialNumber 'dd'H, issuer { issuerName { directoryName:rdnSequence:"cn=y" }, -- optional baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" }, issuerUID "" -- optional }, -- optional objectDigestInfo { ... } -- optional } } while your implementation requires { serialNumber 'dd'H, issuer { baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" } } } } nothing more and nothing less. If I'm correct, your implementation would pose some interoperability issues; yet, it represents a good starting point, given the absence of any standard track specification of PMI. 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 ----------------------------------- --===============6523039362495154327==-- From ando@sys-net.it Sun Sep 14 22:32:41 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5700) [enhancement] add support for certificateListExactMatch (RFC4523) Date: Sun, 14 Sep 2008 22:32:41 +0000 Message-ID: <200809142232.m8EMWeLE063937@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2173474320741486258==" --===============2173474320741486258== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando About to commit... p. --===============2173474320741486258==-- From ghenry@OpenLDAP.org Mon Sep 15 11:17:13 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5673) Replication delete problem Date: Mon, 15 Sep 2008 11:17:12 +0000 Message-ID: <200809151117.m8FBHCU6016040@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1074823552770280769==" --===============1074823552770280769== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Miguel Jinez wrote: > I was making a test deleting 8600 users in my ldap DIT, but I think > meanwhile Master A perform the actions the synchronization doesn't > respect the hierachy and deletes fathers but not his sons. > Why I said that, because I try to upload again the users and in some > cases they alredy exist I think I recall an ITS for this. Will check. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============1074823552770280769==-- From ando@sys-net.it Mon Sep 15 13:00:22 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5695) AC syntax in OpenLDAP Date: Mon, 15 Sep 2008 13:00:21 +0000 Message-ID: <200809151300.m8FD0LM4037451@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6845584451206317483==" --===============6845584451206317483== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have uploaded a patch that incorporates yours into the code as after applying my fixes to certificate stuff and the implementation of certificateList matching as of last night (ITS#5700). I have modified your contribution to reflect the functionalities I have added to certificate handling in order to minimize code duplication. Note that the OIDs used in the above patch are from OpenLDAP's development arc, but I didn't register them yet, because I first want to be sure there are no official OIDs for those syntaxes yet. The patch also includes the complete schema (objectClasses and attributeTypes) concerning PMI as of X.509. I'll commit it as soon as I get some feedback about your copyright notice and OID registration. In the meanwhile, please test. 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 ----------------------------------- --===============6845584451206317483==-- From richton@nbcs.rutgers.edu Mon Sep 15 20:36:21 2008 From: richton@nbcs.rutgers.edu To: openldap-bugs@openldap.org Subject: (ITS#5701) connection.c asserting during test008 Date: Mon, 15 Sep 2008 20:36:20 +0000 Message-ID: <200809152036.m8FKaKiO097838@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4835773732679748175==" --===============4835773732679748175== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) Rare connection.c assertion during test008s of RE24. Here are three different examples: t(a)6 (l(a)6) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state =3D=3D SLAP_C_INVALID ); current thread: t(a)6 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff76bfeb30, 0x0, 0x0, 0x0), at 0xffffffff7f058d= c0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x100427478, 0x100427480= ), at 0xffffffff7f03e98c =3D>[5] connection_next(c =3D (nil), index =3D 0xffffffff76bfefec), line 871 = in "connection.c" [6] monitor_subsys_conn_create(op =3D 0x103a359b0, rs =3D 0xffffffff76bff99= 8, ndn =3D (nil), e_parent =3D 0x1005c03d8, ep =3D 0xffffffff76bff230), line 500 in = "conn.c" [7] monitor_entry_create(op =3D 0x103a359b0, rs =3D 0xffffffff76bff998, ndn= =3D (nil), e_parent =3D 0x1005c03d8, ep =3D 0xffffffff76bff230), line 90 in "entr= y.c" [8] monitor_send_children(op =3D 0x103a359b0, rs =3D 0xffffffff76bff998, e_= parent =3D 0x1005c03d8, sub =3D 1), line 53 in "search.c" [9] monitor_send_children(op =3D 0x103a359b0, rs =3D 0xffffffff76bff998, e_= parent =3D 0x1005c0338, sub =3D 1), line 123 in "search.c" [10] monitor_back_search(op =3D 0x103a359b0, rs =3D 0xffffffff76bff998), li= ne 245 in "search.c" [11] fe_op_search(op =3D 0x103a359b0, rs =3D 0xffffffff76bff998), line 366 = in "search.c" [12] do_search(op =3D 0x103a359b0, rs =3D 0xffffffff76bff998), line 217 in "search.c" [13] connection_operation(ctx =3D 0xffffffff76bffc20, arg_v =3D 0x103a359b0= ), line 1084 in "connection.c" [14] connection_read_thread(ctx =3D 0xffffffff76bffc20, argv =3D 0xe), line= 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool =3D 0x100502250), line 663 in "tpoo= l.c" t(a)18 (l(a)18) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state =3D=3D SLAP_C_INVALID ); current thread: t(a)18 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff6dbfeb20, 0x0, 0x0, 0x0), at 0xffffffff7f058d= c0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x16, 0x1006b9cd8, 0x0), at 0xffffffff7f03e98c =3D>[5] connection_next(c =3D (nil), index =3D 0xffffffff6dbff02c), line 871 = in "connection.c" [6] monitor_subsys_rww_update(op =3D 0x102c3dd70, rs =3D 0xffffffff6dbff998= , e =3D 0x1005c1b98), line 187 in "rww.c" [7] monitor_entry_update(op =3D 0x102c3dd70, rs =3D 0xffffffff6dbff998, e = =3D 0x1005c1b98), line 59 in "entry.c" [8] monitor_send_children(op =3D 0x102c3dd70, rs =3D 0xffffffff6dbff998, e_= parent =3D 0x1005c0748, sub =3D 1), line 88 in "search.c" [9] monitor_send_children(op =3D 0x102c3dd70, rs =3D 0xffffffff6dbff998, e_= parent =3D 0x1005c0338, sub =3D 1), line 123 in "search.c" [10] monitor_back_search(op =3D 0x102c3dd70, rs =3D 0xffffffff6dbff998), li= ne 245 in "search.c" [11] fe_op_search(op =3D 0x102c3dd70, rs =3D 0xffffffff6dbff998), line 366 = in "search.c" [12] do_search(op =3D 0x102c3dd70, rs =3D 0xffffffff6dbff998), line 217 in "search.c" [13] connection_operation(ctx =3D 0xffffffff6dbffc20, arg_v =3D 0x102c3dd70= ), line 1084 in "connection.c" [14] connection_read_thread(ctx =3D 0xffffffff6dbffc20, argv =3D 0x1e), lin= e 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool =3D 0x100502250), line 663 in "tpoo= l.c" t(a)3 (l(a)3) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state =3D=3D SLAP_C_INVALID ); current thread: t(a)3 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff78ffea50, 0x0, 0x0, 0x0), at 0xffffffff7f058d= c0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x0, 0x0), at 0xffffffff7f03e98c =3D>[5] connection_next(c =3D (nil), index =3D 0xffffffff78fff02c), line 871 = in "connection.c" [6] connection_first(index =3D 0xffffffff78fff02c), line 829 in "connection= .c" [7] monitor_subsys_rww_update(op =3D 0x100922640, rs =3D 0xffffffff78fff998= , e =3D 0x1005c1b98), line 185 in "rww.c" [8] monitor_entry_update(op =3D 0x100922640, rs =3D 0xffffffff78fff998, e = =3D 0x1005c1b98), line 59 in "entry.c" [9] monitor_send_children(op =3D 0x100922640, rs =3D 0xffffffff78fff998, e_= parent =3D 0x1005c0748, sub =3D 1), line 88 in "search.c" [10] monitor_send_children(op =3D 0x100922640, rs =3D 0xffffffff78fff998, e= _parent =3D 0x1005c0338, sub =3D 1), line 123 in "search.c" [11] monitor_back_search(op =3D 0x100922640, rs =3D 0xffffffff78fff998), li= ne 245 in "search.c" [12] fe_op_search(op =3D 0x100922640, rs =3D 0xffffffff78fff998), line 366 = in "search.c" [13] do_search(op =3D 0x100922640, rs =3D 0xffffffff78fff998), line 217 in "search.c" [14] connection_operation(ctx =3D 0xffffffff78fffc20, arg_v =3D 0x100922640= ), line 1084 in "connection.c" [15] connection_read_thread(ctx =3D 0xffffffff78fffc20, argv =3D 0x22), lin= e 1211 in "connection.c" [16] ldap_int_thread_pool_wrapper(xpool =3D 0x100502250), line 663 in "tpoo= l.c" I have the testrun directories from each of these runs, if desired. --===============4835773732679748175==-- From ando@sys-net.it Mon Sep 15 22:24:57 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5663) Declaring substitute syntax as LDAP syntax Date: Mon, 15 Sep 2008 22:24:57 +0000 Message-ID: <200809152224.m8FMOvC0007037@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8318399427811472054==" --===============8318399427811472054== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Michael, I have a patch=20 =20 that implements support for "ldapsyntax" (slapd.conf) and=20 "olcLdapSyntaxes" (back-config) in order to allow run-time configuration=20 of syntaxes that have NULL handlers and thus need to have the X-SUBST=20 extension in place. The patch is very intrusive, that's why I didn't=20 commit it right now, as I'd like someone to give it a look first. It=20 applies to HEAD as of right now. Please test and report. My current=20 test configuration is something like ldapsyntax ( NAME 'MySyntax' DESC 'this is the description' X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) followed by attributeType ( NAME 'MyAttr' SYNTAX ) It seems to work just fine, although I didn't check many features like=20 deletion of schema via back-config and so. 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 ----------------------------------- --===============8318399427811472054==-- From hyc@symas.com Tue Sep 16 07:34:15 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5701) connection.c asserting during test008 Date: Tue, 16 Sep 2008 07:34:14 +0000 Message-ID: <200809160734.m8G7YEFa048210@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0736362284064951971==" --===============0736362284064951971== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > Rare connection.c assertion during test008s of RE24. Here are three differe= nt > examples: > > t(a)6 (l(a)6) terminated by signal ABRT (Abort) > 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! > 0xffffffff7f0a8d5c > Current function is connection_next > 871 assert( connections[*index].c_conn_state =3D=3D > SLAP_C_INVALID ); What is the value of c_conn_state in each of these occurrences? > I have the testrun directories from each of these runs, if desired. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============0736362284064951971==-- From richton@nbcs.rutgers.edu Tue Sep 16 13:12:36 2008 From: richton@nbcs.rutgers.edu To: openldap-bugs@openldap.org Subject: Re: (ITS#5701) connection.c asserting during test008 Date: Tue, 16 Sep 2008 13:12:35 +0000 Message-ID: <200809161312.m8GDCZRs078361@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1290582040912534060==" --===============1290582040912534060== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 16 Sep 2008, Howard Chu wrote: > What is the value of c_conn_state in each of these occurrences? In case 1 and 2, connections[*index].c_conn_state = 2 (SLAP_C_ACTIVE). In case 3, connections[*index].c_conn_state = 1 (SLAP_C_INACTIVE). --===============1290582040912534060==-- From michael@stroeder.com Tue Sep 16 18:17:52 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5663) Declaring substitute syntax as LDAP syntax Date: Tue, 16 Sep 2008 18:17:51 +0000 Message-ID: <200809161817.m8GIHpcs009893@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6094388909483965852==" --===============6094388909483965852== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Pierangelo Masarati wrote: >=20 > I have a patch > > that implements support for "ldapsyntax" (slapd.conf) and > "olcLdapSyntaxes" (back-config) in order to allow run-time configuration > of syntaxes that have NULL handlers and thus need to have the X-SUBST > extension in place. You rock! I'll give it a try. > ldapsyntax ( NAME 'MySyntax' > DESC 'this is the description' > X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) Looking at RFC 4512 the SyntaxDescription does not mention NAME (although I'd appreciate it would). Ciao, Michael. --===============6094388909483965852==-- From ando@sys-net.it Tue Sep 16 18:30:37 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5663) Declaring substitute syntax as LDAP syntax Date: Tue, 16 Sep 2008 18:30:36 +0000 Message-ID: <200809161830.m8GIUaca010874@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4660447984416335482==" --===============4660447984416335482== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Michael Str=C3=B6der wrote: > Pierangelo Masarati wrote: >> I have a patch >> >> that implements support for "ldapsyntax" (slapd.conf) and >> "olcLdapSyntaxes" (back-config) in order to allow run-time configuration >> of syntaxes that have NULL handlers and thus need to have the X-SUBST >> extension in place. >=20 > You rock! I'll give it a try. >=20 >> ldapsyntax ( NAME 'MySyntax' >> DESC 'this is the description' >> X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) >=20 > Looking at RFC 4512 the SyntaxDescription does not mention NAME > (although I'd appreciate it would). Correct. I was mistaken by the presence of the field in the schema=20 stucture of include/ldap_schema.h: typedef struct ldap_syntax { char *syn_oid; /* REQUIRED */ char **syn_names; /* OPTIONAL */ char *syn_desc; /* OPTIONAL */ LDAPSchemaExtensionItem **syn_extensions; /* OPTIONAL */ } LDAPSyntax; We should probably trim it, although it could (would) break binary=20 interoperability at the libldap level. I'd note rfc4517 does not=20 mention extensions, either... 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 ----------------------------------- --===============4660447984416335482==-- From ando@sys-net.it Tue Sep 16 18:33:14 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5663) Declaring substitute syntax as LDAP syntax Date: Tue, 16 Sep 2008 18:33:13 +0000 Message-ID: <200809161833.m8GIXDkB011594@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2495390915498301249==" --===============2495390915498301249== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit michael(a)stroeder.com wrote: > You rock! I'll give it a try. BTW: there are some minor bugs in that patch; for example, don't start slapd with -F :). I should either submit a new one, or commit the whole stuff, but perhaps I'd wait for 2.4.12 to be out. 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 ----------------------------------- --===============2495390915498301249==-- From hyc@symas.com Tue Sep 16 18:45:11 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5663) Declaring substitute syntax as LDAP syntax Date: Tue, 16 Sep 2008 18:45:10 +0000 Message-ID: <200809161845.m8GIjAtf012790@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5052395733539981643==" --===============5052395733539981643== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ando(a)sys-net.it wrote: > I'd note rfc4517 does not > mention extensions, either... RFC4512 does. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5052395733539981643==-- From ando@sys-net.it Tue Sep 16 19:43:56 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5663) Declaring substitute syntax as LDAP syntax Date: Tue, 16 Sep 2008 19:43:55 +0000 Message-ID: <200809161943.m8GJhtRK027690@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8407850150576530327==" --===============8407850150576530327== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ando(a)sys-net.it wrote: > BTW: there are some minor bugs in that patch; for example, don't start=20 > slapd with -F :). Michael, please try this one instead: . I won't probably be able to work at this stuff for a few days. Cheers, 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 ----------------------------------- --===============8407850150576530327==-- From rein@OpenLDAP.org Tue Sep 16 20:02:47 2008 From: Rein Tollevik To: openldap-bugs@openldap.org Subject: Re: Issue in syncprov findcsn code Date: Tue, 16 Sep 2008 22:02:09 +0200 Message-ID: <48D010C1.807@OpenLDAP.org> In-Reply-To: <48BD7663.7090504@sys-net.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4075706550774806902==" --===============4075706550774806902== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Pierangelo Masarati wrote: > 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): [code and discussion removed] > - make syncprov_findcsn() search the newest contextCSN instead of the > one with its SID Only looking for contextCSN values with sid matching the serverID was introduced in revision 1.240 to fix ITS#5537. > - initialize slapd_serverID with some SID_UNDEFINED in order to take the > action above only when SID is not defined I agree, although I would prefer to take it one step further and reserve serverID==0 for the tools case. In ITS#5536 I tried to distinguish between a defaulted and configured serverID==0, but it didn't quite slip through and was closed without being properly fixed. It should probably be reopened. Btw, the ITS#5675 fix to syncrepl.c improves the contextCSN propagation from syncrepl to syncprov, but the csn queue isn't really suitable for that. Syncrepl may update more than one contextCSN value at the same time, but the queue can only pass one around. I'm currently testing a patch that fixes the contextCSN propagation problems we have seen, it should fix this as well. Rein --===============4075706550774806902==-- From ando@sys-net.it Tue Sep 16 22:39:34 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5702) [enhancement] allow cross-attribute constraints in slapo-constraint(5) Date: Tue, 16 Sep 2008 22:39:33 +0000 Message-ID: <200809162239.m8GMdX2Y085714@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4945897527967622153==" --===============4945897527967622153== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I've added a "set" type to slapo-constraint(5) that allows to write complex constraints like constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" forcing a relationship between the values of cn, sn and givenName. The possibility to enforce the same constraint on multiple attributes separat= ed by commas is given to all constraint types, as a side-effect. The check is passed the entry during add operations, while it attempts to bui= ld the entry resulting from a set of modifications during modify operations. p. --===============4945897527967622153==-- From hyc@symas.com Wed Sep 17 02:11:36 2008 From: Howard Chu To: openldap-bugs@openldap.org Subject: Re: Issue in syncprov findcsn code Date: Tue, 16 Sep 2008 19:07:53 -0700 Message-ID: <48D06679.2090905@symas.com> In-Reply-To: <48D010C1.807@OpenLDAP.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2991681901127376814==" --===============2991681901127376814== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Rein Tollevik wrote: > Pierangelo Masarati wrote: > >> 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): > > [code and discussion removed] > >> - make syncprov_findcsn() search the newest contextCSN instead of the >> one with its SID > > Only looking for contextCSN values with sid matching the serverID was > introduced in revision 1.240 to fix ITS#5537. > >> - initialize slapd_serverID with some SID_UNDEFINED in order to take the >> action above only when SID is not defined > > I agree, although I would prefer to take it one step further and reserve > serverID==0 for the tools case. In ITS#5536 I tried to distinguish > between a defaulted and configured serverID==0, but it didn't quite slip > through and was closed without being properly fixed. It should probably > be reopened. Well, a serverID of 0 is basically the same as no serverID. For mirrormode/multimaster the serverID must be non-zero. For single-master the serverID must be zero. By the way, re: the current test050 failures in RE24, I saw the failure occur again even with the latest syncrepl.c patch reverted, so it appears that was just coincidental the last time. > Btw, the ITS#5675 fix to syncrepl.c improves the contextCSN propagation > from syncrepl to syncprov, but the csn queue isn't really suitable for > that. Syncrepl may update more than one contextCSN value at the same > time, but the queue can only pass one around. I'm currently testing a > patch that fixes the contextCSN propagation problems we have seen, it > should fix this as well. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============2991681901127376814==-- From ando@sys-net.it Wed Sep 17 07:58:02 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5703) slapo-constraint(5) rename issue Date: Wed, 17 Sep 2008 07:58:02 +0000 Message-ID: <200809170758.m8H7w2lQ018965@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6202691136815921335==" --===============6202691136815921335== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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. --===============6202691136815921335==-- From ando@sys-net.it Wed Sep 17 18:59:27 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5704) [enhancement] allow restrictions in slapo-constraint(5) Date: Wed, 17 Sep 2008 18:59:26 +0000 Message-ID: <200809171859.m8HIxQYK083111@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8650641780665053721==" --===============8650641780665053721== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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. --===============8650641780665053721==-- From liandrosg@gmail.com Wed Sep 17 19:09:37 2008 From: liandro sg To: openldap-bugs@openldap.org Subject: syncrepl failed without errors when a put a TAB character in slapd.conf Date: Wed, 17 Sep 2008 16:09:23 -0300 Message-ID: <10126fbc0809171209g3c98a13co8a7f69426b94b8a1@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8720751798488727248==" --===============8720751798488727248== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============8720751798488727248== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.htm" MIME-Version: 1.0 PGRpdiBkaXI9Imx0ciI+UnVubmluZyZuYnNwOyBzbGFwZCAyLjQuMTAtMyB2ZXJzaW9uIG9uIGRl YmlhbiAyLjYuMjUtMi02ODY8YnI+PGJyPklmIEkgcHV0IGEgVEFCIChhc2NpaSBjaGFyYWN0ZXIg ZGVjaW1hbCA5KSZuYnNwOyBzdGFydGluZyBhIGxpbmUgaW4gc2xhcGQuY29uZiAsJm5ic3A7IDxk aXYgaWQ9InJlc3VsdF9ib3giIGRpcj0ibHRyIj5pbiBmcm9udCBvZiZuYnNwOyBzeW5jcmVwbCBj b25maWd1cmF0aW9uIG9wdGlvbiwgdGhlIHN5bmNyZXBsIGZ1bmNpb25saXR5IGRvbiYjMzk7dCBz dGFydHMgLjxicj4KVGhlIGZvbmZpZ3VyYXRpb24gdGVzdCAoIHNsYXB0ZXN0KSByZXR1cm4gc3Vj Y2Vzcy48YnI+SWYgSSBkZWxldGUgdGhlIFRBQiBjaGFyYWN0ZXIsIHN5bmNyZXBsIHJ1biBvazxi cj48YnI+PC9kaXY+PC9kaXY+Cg== --===============8720751798488727248==-- From ando@sys-net.it Wed Sep 17 19:17:42 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5704) [enhancement] allow restrictions in slapo-constraint(5) Date: Wed, 17 Sep 2008 19:17:41 +0000 Message-ID: <200809171917.m8HJHfZ5086046@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4683714578110980320==" --===============4683714578110980320== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 ----------------------------------- --===============4683714578110980320==-- From rein@OpenLDAP.org Wed Sep 17 19:30:08 2008 From: Rein Tollevik To: openldap-bugs@openldap.org Subject: Re: Issue in syncprov findcsn code Date: Wed, 17 Sep 2008 21:29:25 +0200 Message-ID: <48D15A95.6050300@OpenLDAP.org> In-Reply-To: <48D06679.2090905@symas.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8899542408353197864==" --===============8899542408353197864== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Howard Chu skrev: > Rein Tollevik wrote: >> Pierangelo Masarati wrote: >>> - initialize slapd_serverID with some SID_UNDEFINED in order to take the >>> action above only when SID is not defined >> >> I agree, although I would prefer to take it one step further and reserve >> serverID==0 for the tools case. In ITS#5536 I tried to distinguish >> between a defaulted and configured serverID==0, but it didn't quite slip >> through and was closed without being properly fixed. It should probably >> be reopened. > > Well, a serverID of 0 is basically the same as no serverID. For > mirrormode/multimaster the serverID must be non-zero. For single-master > the serverID must be zero. This is not how I read the doc nor the source. But if it was like this then it should be what I need :-) To enforce it syncprov must be changed so that: If serverID is 0 it should only allow one contextCSN value, and it should have 0 in the sid field. Maybe not required to enforce, but it should help to quickly identify incorrectly configured servers. If serverID is not 0 it should not accept contextCSN values from syncrepl with 0 in the sid field, to make sure it don't receives updates from a single-master configured server. If serverID is not 0 it must ignore contextCSN values with 0 in the sid field read from the database. This is to allow a single-master server to be promoted to a multi-master without leaving the old sid=0 csn around forever. Hmm, if a csn with sid=0 is found, but none with the serverID value, then it could maybe be better to replace the sid in that csn? More hmm, when starting up it would probably be correct to include entries with 0 in the sid fields of their entryCSN value in those that could cause the current servers contextCSN to be updated? I expect I'm not the only one that forgets to add the -S argument to slapadd... The serverID in existing mirrormode/multimaster configurations that uses 0 as the value must be changed, but this should be all that is needed when upgrading to this version. What would be the correct action if a contextCSN with an invalid sid value is received from syncrepl? Asserting it could be a bit too strict, better to ignore the value and complain loudly in the logs? Does this make any sense? If so, I'll volunteer to implement. Rein --===============8899542408353197864==-- From ando@sys-net.it Wed Sep 17 19:47:21 2008 From: Pierangelo Masarati To: openldap-bugs@openldap.org Subject: Re: Issue in syncprov findcsn code Date: Wed, 17 Sep 2008 21:46:38 +0200 Message-ID: <48D15E9E.3060603@sys-net.it> In-Reply-To: <48D15A95.6050300@OpenLDAP.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2395676547085580893==" --===============2395676547085580893== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Rein Tollevik wrote: >> Well, a serverID of 0 is basically the same as no serverID. For >> mirrormode/multimaster the serverID must be non-zero. For >> single-master the serverID must be zero. > > This is not how I read the doc nor the source. But if it was like this > then it should be what I need :-) To enforce it syncprov must be changed > so that: > > If serverID is 0 it should only allow one contextCSN value, and it > should have 0 in the sid field. Maybe not required to enforce, but it > should help to quickly identify incorrectly configured servers. > > If serverID is not 0 it should not accept contextCSN values from > syncrepl with 0 in the sid field, to make sure it don't receives updates > from a single-master configured server. > > If serverID is not 0 it must ignore contextCSN values with 0 in the sid > field read from the database. This is to allow a single-master server > to be promoted to a multi-master without leaving the old sid=0 csn > around forever. Hmm, if a csn with sid=0 is found, but none with the > serverID value, then it could maybe be better to replace the sid in that > csn? More hmm, when starting up it would probably be correct to include > entries with 0 in the sid fields of their entryCSN value in those that > could cause the current servers contextCSN to be updated? I expect I'm > not the only one that forgets to add the -S argument to slapadd... > > The serverID in existing mirrormode/multimaster configurations that uses > 0 as the value must be changed, but this should be all that is needed > when upgrading to this version. > > What would be the correct action if a contextCSN with an invalid sid > value is received from syncrepl? Asserting it could be a bit too > strict, better to ignore the value and complain loudly in the logs? > > Does this make any sense? If so, I'll volunteer to implement. To me, it makes a lot of sense and, well explained in the docs, would greatly help troubleshooting (or even better, set up things the right way right away). My concerns are: - do we need to consider all those cases and try to repair them? I'd say: no. Just complain (and refuse to start) if the problem can be solved by running "slapadd -S " or "slapcat | sed | slapadd". - the problem should not occur run-time in a homogeneous, well-configured system (== same versions, consistent configuration). If it happens, just give up replication and/or commence a full refresh (agree that assert'ing would be bad). - slapadd could detect from the configuration whether -S is needed (don't think it could determine the right SID, but at least it could complain, and require a --force (to be implemented) if one retains to know what he's doing). 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 ----------------------------------- --===============2395676547085580893==-- From quanah@zimbra.com Wed Sep 17 20:29:32 2008 From: Quanah Gibson-Mount To: openldap-bugs@openldap.org Subject: Re: syncrepl failed without errors when a put a TAB character in slapd.conf Date: Wed, 17 Sep 2008 13:29:10 -0700 Message-ID: In-Reply-To: <10126fbc0809171209g3c98a13co8a7f69426b94b8a1@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3449432928195732768==" --===============3449432928195732768== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Wednesday, September 17, 2008 4:09 PM -0300 liandro sg wrote: > > 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 Software usage questions should be sent to openldap-software(a)openldap.org I advise closely reading the slapd.conf(5) man page, in particular: If a line begins with white space, it is considered a continuation of the previous line. No physical line should be over 2000 bytes long. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3449432928195732768==-- From ghenry@OpenLDAP.org Wed Sep 17 21:40:36 2008 From: Gavin Henry To: openldap-bugs@openldap.org Subject: Re: Issue in syncprov findcsn code Date: Wed, 17 Sep 2008 22:39:51 +0100 Message-ID: <28475237.941221687591634.JavaMail.root@mail> In-Reply-To: <48D15E9E.3060603@sys-net.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8757925463568276039==" --===============8757925463568276039== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > say: no. Just complain (and refuse to start) if the problem can be > solved by running "slapadd -S " or "slapcat | sed | slapadd". > > - the problem should not occur run-time in a homogeneous, > well-configured system (== same versions, consistent configuration). > If > it happens, just give up replication and/or commence a full refresh > (agree that assert'ing would be bad). > > - slapadd could detect from the configuration whether -S is needed > (don't think it could determine the right SID, but at least it could > complain, and require a --force (to be implemented) if one retains to > > know what he's doing). Can I confirm the use case here? I've not used the -S option and it sounds very important. According to Ando it should be clearly documented too. Is it used in a MM/N-Way when exporting via slapcat and then importing to another server that will have its own serverID, hence the -S to override the currently exported serverID from the first server? Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============8757925463568276039==-- From ando@sys-net.it Wed Sep 17 21:50:15 2008 From: Pierangelo Masarati To: openldap-bugs@openldap.org Subject: Re: Issue in syncprov findcsn code Date: Wed, 17 Sep 2008 23:49:33 +0200 Message-ID: <48D17B6D.4090708@sys-net.it> In-Reply-To: <28475237.941221687591634.JavaMail.root@mail> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4273588579090911739==" --===============4273588579090911739== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Gavin Henry wrote: > Can I confirm the use case here? I've not used the -S option and it sounds > very important. According to Ando it should be clearly documented too. > > Is it used in a MM/N-Way when exporting via slapcat and then importing to > another server that will have its own serverID, hence the -S to override the > currently exported serverID from the first server? As far as I know, you don't need it unless you're initializing a MM/N-Way from a clean LDIF (i.e. without entryCSN). Usually, when you restore from a backup, you want existing entryCSN to be preserved. -S only affects the SID portion of entryCSN *generated* by slapadd, i.e. those that were missing in the source LDIF. I added that option some time ago, when I needed to generate a database for a N-Way by importing an LDIF obtained from SunONE. The procedure then was: - slapadd -w -S 001 -l plain.ldif - slapcat -l full.ldif - scp full.ldif other-n-way: on other-n-way: - slapadd -l full.ldif This way, all N-Way would get the same database with the SID of the first one, "001". As an alternative, I could have fired up the first one and let the others sync. 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 ----------------------------------- --===============4273588579090911739==-- From ghenry@OpenLDAP.org Wed Sep 17 21:56:05 2008 From: Gavin Henry To: openldap-bugs@openldap.org Subject: Re: Issue in syncprov findcsn code Date: Wed, 17 Sep 2008 22:55:25 +0100 Message-ID: <7095783.1051221688525608.JavaMail.root@mail> In-Reply-To: <48D17B6D.4090708@sys-net.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8463741608520175308==" --===============8463741608520175308== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ----- "Pierangelo Masarati" wrote: > Gavin Henry wrote: > > > Can I confirm the use case here? I've not used the -S option and it > sounds > > very important. According to Ando it should be clearly documented > too. > > > > Is it used in a MM/N-Way when exporting via slapcat and then > importing to > > another server that will have its own serverID, hence the -S to > override the > > currently exported serverID from the first server? > > As far as I know, you don't need it unless you're initializing a > MM/N-Way from a clean LDIF (i.e. without entryCSN). Usually, when you > > restore from a backup, you want existing entryCSN to be preserved. -S > > only affects the SID portion of entryCSN *generated* by slapadd, i.e. > > those that were missing in the source LDIF. I added that option some > > time ago, when I needed to generate a database for a N-Way by > importing > an LDIF obtained from SunONE. The procedure then was: > > - slapadd -w -S 001 -l plain.ldif > - slapcat -l full.ldif > - scp full.ldif other-n-way: > > on other-n-way: > > - slapadd -l full.ldif OK, that's perfectly clear. > > This way, all N-Way would get the same database with the SID of the > first one, "001". As an alternative, I could have fired up the first > > one and let the others sync. Yes, the later way is done by most folks except by the ones who have massive data sets and can't/won't sync online. Thanks for the clear up. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============8463741608520175308==-- From ando@sys-net.it Thu Sep 18 18:35:25 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5705) [enhancement] slapo-constraint could honor "relax" by not checking for constraints Date: Thu, 18 Sep 2008 18:35:24 +0000 Message-ID: <200809181835.m8IIZObO063492@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5981501852844407710==" --===============5981501852844407710== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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. --===============5981501852844407710==-- From ando@sys-net.it Thu Sep 18 19:51:00 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 19:51:00 +0000 Message-ID: <200809181951.m8IJp03P069084@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0865721266799396910==" --===============0865721266799396910== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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. --===============0865721266799396910==-- From ando@sys-net.it Thu Sep 18 20:12:47 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:12:47 +0000 Message-ID: <200809182012.m8IKClj7071015@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2875004492371655032==" --===============2875004492371655032== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 ----------------------------------- --===============2875004492371655032==-- From quanah@zimbra.com Thu Sep 18 20:17:54 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:17:53 +0000 Message-ID: <200809182017.m8IKHraD071820@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4316371825825712632==" --===============4316371825825712632== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --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 --===============4316371825825712632==-- From ando@sys-net.it Thu Sep 18 20:23:19 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:23:18 +0000 Message-ID: <200809182023.m8IKNI47072655@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1964674079948301443==" --===============1964674079948301443== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 ----------------------------------- --===============1964674079948301443==-- From hyc@symas.com Thu Sep 18 20:25:07 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:25:06 +0000 Message-ID: <200809182025.m8IKP6ws073336@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4883783282795412616==" --===============4883783282795412616== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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;=20 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= =20 worked with, plus a lot of expedience - something quick and easy to implement= .=20 Note that subentries cannot have children, and the premise of this overlay is= =20 to propagate attributes from a parent entry (not subentry) to all of its chil= dren. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============4883783282795412616==-- From ando@sys-net.it Thu Sep 18 20:26:28 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:26:27 +0000 Message-ID: <200809182026.m8IKQR3l074462@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7689003322992765026==" --===============7689003322992765026== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 ----------------------------------- --===============7689003322992765026==-- From ghenry@OpenLDAP.org Thu Sep 18 20:28:50 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:28:49 +0000 Message-ID: <200809182028.m8IKSnMH075803@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4018578751333847547==" --===============4018578751333847547== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ----- 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/ --===============4018578751333847547==-- From ando@sys-net.it Thu Sep 18 20:33:07 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:33:06 +0000 Message-ID: <200809182033.m8IKX6ng077864@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5750353016835589482==" --===============5750353016835589482== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 ----------------------------------- --===============5750353016835589482==-- From ghenry@suretecsystems.com Thu Sep 18 20:43:17 2008 From: ghenry@suretecsystems.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:43:17 +0000 Message-ID: <200809182043.m8IKhHrf081867@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3936374643788912844==" --===============3936374643788912844== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ----- ando(a)sys-net.it wrote: > ghenry(a)OpenLDAP.org wrote: > > ----- ando(a)sys-net.it wrote: > >=20 > >> ando(a)sys-net.it wrote: > >> > >>> Slapo-collect is now in re24, but no man page is available. > >> Added to HEAD; please review. > >=20 > > If it supports cn=3Dconfig, that should be mentioned in the man page. >=20 > It does. Fixed, thanks. I'd note that only few man pages mention > this=20 > 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=3Dconfi= g example to each as well as the slapd.conf examples. --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============3936374643788912844==-- From hyc@symas.com Thu Sep 18 20:51:15 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5706) slapo-collect(5) is missing Date: Thu, 18 Sep 2008 20:51:15 +0000 Message-ID: <200809182051.m8IKpFxq085770@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1713647664405888309==" --===============1713647664405888309== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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/ --===============1713647664405888309==-- From ando@sys-net.it Sat Sep 20 13:05:47 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Sat, 20 Sep 2008 13:05:46 +0000 Message-ID: <200809201305.m8KD5kdT089675@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8955147371794431102==" --===============8955147371794431102== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 ----------------------------------- --===============8955147371794431102==-- From ando@sys-net.it Sat Sep 20 16:28:52 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5654) memberof syntax clunky Date: Sat, 20 Sep 2008 16:28:52 +0000 Message-ID: <200809201628.m8KGSql5002673@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3151349234177522964==" --===============3151349234177522964== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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) >=20 >=20 > As instructed by Howard: >=20 > From: Howard Chu > 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) >=20 >=20 >=20 >> # Generated from schema in /usr/local/samba/private/ldap/schema-tmp.ldb >> overlay memberof >> memberof-dn cn=3Dsamba-admin,cn=3Dsamba >> memberof-dangling error >> memberof-refint TRUE >> memberof-group-oc top >> memberof-member-ad msDS-ObjectReference >> memberof-memberof-ad msDS-ObjectReferenceBL >> memberof-dangling-error 32 >=20 > (repeats once per attribute link) >=20 > ... >=20 > Mmm, that's really clunky. Someone should file an OpenLDAP enhancement requ= est=20 > on the memberof config syntax. You should only need to instantiate the over= lay=20 > once, and then it should just take a list of oc/forward-ad/back-ad config=20 > options. >=20 >> 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),=20 which was designed to deal with *just one* pair of member/reverse-link=20 attribute relationship. Probably the overlay needs to be entirely=20 reworked to provide a many-to-many relationship. At this point, I'd=20 rather design a new one, giving up some of the not so useful extra=20 features implemented in slapo-memberof(5), and focusing on the=20 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 ----------------------------------- --===============3151349234177522964==-- From ando@sys-net.it Sat Sep 20 16:41:11 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5701) connection.c asserting during test008 Date: Sat, 20 Sep 2008 16:41:11 +0000 Message-ID: <200809201641.m8KGfBNJ003593@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2269580388857843753==" --===============2269580388857843753== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable richton(a)nbcs.rutgers.edu wrote: > Rare connection.c assertion during test008s of RE24. Here are three differe= nt > examples: > [6] monitor_subsys_conn_create(op =3D 0x103a359b0, rs =3D 0xffffffff76bff= 998, ndn > =3D (nil), e_parent =3D 0x1005c03d8, ep =3D 0xffffffff76bff230), line 500 i= n "conn.c" > [6] monitor_subsys_rww_update(op =3D 0x102c3dd70, rs =3D 0xffffffff6dbff9= 98, e =3D > 0x1005c1b98), line 187 in "rww.c" > [7] monitor_subsys_rww_update(op =3D 0x100922640, rs =3D 0xffffffff78fff9= 98, e =3D > 0x1005c1b98), line 185 in "rww.c" Sorry, I overlooked the fact that all those issues are occurring from=20 within back-monitor. In all cases, it's within code that loops through=20 the connection array using connection_{first,next,close}(). Apparently,=20 those calls are used in the right way. Can you print more information=20 about those connections? E.g. c->c_struct_state, and *index from within=20 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 ----------------------------------- --===============2269580388857843753==-- From richton@nbcs.rutgers.edu Sat Sep 20 20:03:59 2008 From: richton@nbcs.rutgers.edu To: openldap-bugs@openldap.org Subject: Re: (ITS#5701) connection.c asserting during test008 Date: Sat, 20 Sep 2008 20:03:59 +0000 Message-ID: <200809202003.m8KK3x3w014611@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7059208848868659286==" --===============7059208848868659286== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 "" 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) } --===============7059208848868659286==-- From ghenry@OpenLDAP.org Mon Sep 22 15:17:06 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 22 Sep 2008 15:17:05 +0000 Message-ID: <200809221517.m8MFH5qa028752@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7734902754677318799==" --===============7734902754677318799== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ----- ando(a)sys-net.it wrote: > RFC 3062 password modification extended operation on locally stored=20 > credentials is now in HEAD; please test and report. >=20 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. --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============7734902754677318799==-- From ando@sys-net.it Mon Sep 22 15:29:52 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 22 Sep 2008 15:29:52 +0000 Message-ID: <200809221529.m8MFTqXi031647@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0140678368825524169==" --===============0140678368825524169== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Gavin Henry wrote: > ----- ando(a)sys-net.it wrote: >=20 >> RFC 3062 password modification extended operation on locally stored=20 >> credentials is now in HEAD; please test and report. >> >=20 > I'll hold back adding a note in the Admin Guide about this. I think it's be= st placed in the man page anyway. A note should already be in HEAD's slapo-translucent(5). Perhaps we=20 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 ----------------------------------- --===============0140678368825524169==-- From ghenry@OpenLDAP.org Mon Sep 22 15:56:56 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 22 Sep 2008 15:56:56 +0000 Message-ID: <200809221556.m8MFuu6V034726@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2022189177763320024==" --===============2022189177763320024== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ----- "Pierangelo Masarati" wrote: > Gavin Henry wrote: > > ----- ando(a)sys-net.it wrote: > >=20 > >> RFC 3062 password modification extended operation on locally stored >=20 > >> credentials is now in HEAD; please test and report. > >> > >=20 > > I'll hold back adding a note in the Admin Guide about this. I think > it's best placed in the man page anyway. >=20 > A note should already be in HEAD's slapo-translucent(5). =20 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 pres= ent? My reason for asking is that I thought I might need to update the Upgrading s= ection of the Admin Guide? > Perhaps we want the config statements sorted differently (e.g. lexicographi= cally)? Doesn't bother me. Thanks. --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============2022189177763320024==-- From ando@sys-net.it Mon Sep 22 16:23:35 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 22 Sep 2008 16:23:35 +0000 Message-ID: <200809221623.m8MGNZXb038408@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2853178104923820933==" --===============2853178104923820933== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Gavin Henry wrote: >> A note should already be in HEAD's slapo-translucent(5). =20 >=20 > 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 pr= esent? Not sure what you mean there. The uri directive, afaik, is related to=20 the captive database, and (relatively) transparent to the overlay. If=20 you use translucent on a local instance of back-sql, there would be no=20 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 ----------------------------------- --===============2853178104923820933==-- From ghenry@OpenLDAP.org Mon Sep 22 16:47:29 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 22 Sep 2008 16:47:29 +0000 Message-ID: <200809221647.m8MGlTkE041352@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6528477147895359432==" --===============6528477147895359432== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ----- 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/ --===============6528477147895359432==-- From ando@sys-net.it Mon Sep 22 16:53:03 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 22 Sep 2008 16:53:02 +0000 Message-ID: <200809221653.m8MGr2x3042133@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3102753050593582117==" --===============3102753050593582117== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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= parameter to slapo-constraint, which allows to optionally restrict the entries the constraint would apply to. I have also allowed the 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 ----------------------------------- --===============3102753050593582117==-- From ghenry@OpenLDAP.org Mon Sep 22 19:03:32 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 22 Sep 2008 19:03:31 +0000 Message-ID: <200809221903.m8MJ3Vth048794@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5863800358893678374==" --===============5863800358893678374== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ----- ando(a)sys-net.it wrote: > ghenry(a)OpenLDAP.org wrote: >=20 > > Too tired today :-( For some reason I was talking about > slapo-unique, as I'm > > writing that up just now. >=20 > Just to avoid (or increase :) confusion when you'll be back from > relax,=20 > I don't recall working at slapo-unique recently. AFAIK, the old and > the=20 > new config statements live together in perfect harmony, although=20 > unique_uri is preferable as it is more expressive. OK, thanks. > I have added a restrict=3D parameter to slapo-constraint, which=20 > allows to optionally restrict the entries the constraint would apply > to. > I have also allowed the to actually be an attribute list, in > case=20 > one needs to apply the same constraint to more than one. Finally, the >=20 > "set" type is now available. It uses the ACL sets' syntax, which,=20 > 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%2= 0rights%20based%20on%20relationships --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============5863800358893678374==-- From ando@sys-net.it Mon Sep 22 19:07:17 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5656) Bind operations with translucent overlay Date: Mon, 22 Sep 2008 19:07:16 +0000 Message-ID: <200809221907.m8MJ7Giv049653@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5293862331072157430==" --===============5293862331072157430== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Gavin Henry wrote: > Again, thanks. Sets have been documentated for quite some time now: >=20 > http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting= %20rights%20based%20on%20relationships 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 ----------------------------------- --===============5293862331072157430==-- From michael@stroeder.com Mon Sep 22 21:01:42 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: (ITS#5707) HEAD/RE24 and BDB 4.7.25p1 hanging Date: Mon, 22 Sep 2008 21:01:42 +0000 Message-ID: <200809222101.m8ML1gqa056154@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5578825319809612283==" --===============5578825319809612283== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Michael Str=C3=B6der 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-0= 01 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 mail= ing list posting: http://www.openldap.org/lists/openldap-devel/200809/msg00075.html --===============5578825319809612283==-- From hyc@symas.com Mon Sep 22 23:03:27 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5707) HEAD/RE24 and BDB 4.7.25p1 hanging Date: Mon, 22 Sep 2008 23:03:27 +0000 Message-ID: <200809222303.m8MN3RpY065963@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2337355701220690359==" --===============2337355701220690359== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable michael(a)stroeder.com wrote: > Full_Name: Michael Str=C3=B6der > 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 combinati= on > 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 ma= iling > 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= =20 it on a single-core machine. I've sent a backtrace and other debug info to th= e=20 Oracle folks, will see what they have to say. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============2337355701220690359==-- From hyc@symas.com Mon Sep 22 23:23:10 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5707) HEAD/RE24 and BDB 4.7.25p1 hanging Date: Mon, 22 Sep 2008 23:23:10 +0000 Message-ID: <200809222323.m8MNNAXN067294@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6515459805371444442==" --===============6515459805371444442== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > I was unable to reproduce the problem on my multi-core machines, but I do s= ee > 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=20 using multiple lock table partitions, it obtains a lock on the system-wide=20 lock mutex and a lock on the per-region mutex. On a single core system it=20 defaults to a single lock table. In this case, the macro that obtains the=20 system-wide lock behaves identically to the per-region lock. I.e., both=20 attempt to acquire the exact same mutex. Since it's already held, the process= =20 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=3D0x8a84550, mutex=3D104) at ../dist/../mutex/mut_pthread.c:207 #5 0xb7daad19 in __lock_getobj (lt=3D0x8a84848, obj=3D0xbfd492ec, ndx=3D492, create=3D1, retp=3D0xbfd491e4) at ../dist/../lock/lock.c:1470 #6 0xb7da7f53 in __lock_get_internal (lt=3D0x8a84848, sh_locker=3D0xb776d508, flags=3D1, obj=3D0xbfd492ec, lock_mode=3DDB_LOCK_READ, timeout=3D0, lock=3D0xbfd493cc) at ../dist/../lock/lock.c:588 #7 0xb7da77d6 in __lock_get_api (env=3D0x8a84550, locker=3D2147483659, flags= =3D1, obj=3D0xbfd492ec, lock_mode=3DDB_LOCK_READ, lock=3D0xbfd493cc) at ../dist/../lock/lock.c:423 #8 0xb7da765b in __lock_get_pp (dbenv=3D0x8a841c0, locker=3D2147483659, flag= s=3D1, obj=3D0xbfd492ec, lock_mode=3DDB_LOCK_READ, lock=3D0xbfd493cc) at ../dist/../lock/lock.c:395 #9 0x08124fb8 in bdb_dn2id_lock (bdb=3D0x8a68620, dn=3D0xbfd493f0, rw=3D0, txn=3D0x8a890b8, lock=3D0xbfd493cc) at ../../../../head/servers/slapd/back-bdb/dn2id.c:47 #10 0x08125d7d in bdb_dn2id (op=3D0xbfd49640, dn=3D0xbfd493f0, ei=3D0xbfd493e= 0, txn=3D0x8a890b8, lock=3D0xbfd493cc) at ../../../../head/servers/slapd/back-bdb/dn2id.c:307 ---Type to continue, or q to quit---q Quit (gdb) frame 4 #4 0xb7d00819 in __db_pthread_mutex_lock (env=3D0x8a84550, mutex=3D104) at ../dist/../mutex/mut_pthread.c:207 207 RET_SET((pthread_mutex_lock(&mutexp->mutex)), ret); (gdb) p *mutexp $1 =3D {mutex =3D {__data =3D {__lock =3D 2, __count =3D 0, __owner =3D 29470= , __kind =3D 0, __nusers =3D 1, {__spins =3D 0, __list =3D {__next =3D 0x0}}}, __size =3D=20 "\002\000\000\000\000\000\000\000\036s\000\000\000\000\000\000\001\000\000\00= 0\000\000\000",=20 __align =3D 2}, cond =3D {__data =3D {__lock =3D 0, __futex =3D 0, __total_seq =3D 0, __wakeup_seq =3D 0, __woken_seq =3D = 0, __mutex =3D 0x0, __nwaiters =3D 0, __broadcast_seq =3D 0}, __size =3D '\0' , __align =3D 0}, pid =3D 29470, tid =3D 3080046272, mutex_next_link =3D 0, alloc_id =3D 6, mutex_set_wait = =3D 1, mutex_set_nowait =3D 129, flags =3D 3} (gdb) The mutex being acquired in frame 4 is the same one that was already acquired= =20 in frame 7, __lock_get_api line 418. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6515459805371444442==-- From harpreet@deeproot.co.in Tue Sep 23 07:38:06 2008 From: harpreet@deeproot.co.in To: openldap-bugs@openldap.org Subject: (ITS#5708) nss-ldap not responding properly Date: Tue, 23 Sep 2008 07:38:05 +0000 Message-ID: <200809230738.m8N7c5tG088859@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0476813061353808345==" --===============0476813061353808345== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 sho= rt time. These are some details and errors which I have. ##libnss-ldap.conf host 127.0.0.1 base dc=3Dcom ldap_version 3 binddn uid=3Dexample,dc=3Dcom 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=3Dexample,dc=3Dcom - Can't contact LDAP server And some time I get --> local4.debug: Sep 23 11:21:40 slapd[8880]: conn=3D224 fd=3D20 closed (connect= ion lost) or local4.debug: Sep 23 11:15:21 slapd[8880]: connection_read(20): no connection! Please respond to me. Regards. --===============0476813061353808345==-- From mgwin@escp-eap.net Tue Sep 23 11:34:55 2008 From: mgwin@escp-eap.net To: openldap-bugs@openldap.org Subject: Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered Date: Tue, 23 Sep 2008 11:34:54 +0000 Message-ID: <200809231134.m8NBYsPP000405@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1297143751792205764==" --===============1297143751792205764== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, 05 Sep 2008 16:21:36 +0200 Michael Ströder 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 --===============1297143751792205764==-- From michael@stroeder.com Tue Sep 23 13:34:06 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered Date: Tue, 23 Sep 2008 13:34:05 +0000 Message-ID: <200809231334.m8NDY5TJ006416@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3548775102380259213==" --===============3548775102380259213== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Michael Gwin wrote: > On Fri, 05 Sep 2008 16:21:36 +0200 > Michael Ströder 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. --===============3548775102380259213==-- From sylvain.thomas@gmail.com Tue Sep 23 14:32:47 2008 From: sylvain.thomas@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5709) slapd sync provider skips some objects Date: Tue, 23 Sep 2008 14:32:47 +0000 Message-ID: <200809231432.m8NEWlFV010753@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8290837314932947379==" --===============8290837314932947379== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=3D5030708029E1 is not sent to the replica (no call to syncprov_sendresp() ) but the object uid=3D50307080309A is sent. ..... Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=3D331 op=3D1 ADD dn=3D"uid=3D50307080309A,ou=3DA,ou=3D9,ou=3Dabonnes,ou=3Dtest,c=3Dfr" 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=3D333 op=3D1 ADD dn=3D"uid=3D5030708029E1,ou=3D1,ou=3DE,ou=3Dabonnes,ou=3Dtest,c=3Dfr" 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=3D332 op=3D1 RESULT tag=3D105 = err=3D0 text=3D 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=3Drid=3D003,csn=3D20080923080903.373805Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=3D333 op=3D1 RESULT tag=3D105 = err=3D0 text=3D 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=3D331 op=3D1 RESULT tag=3D105 = err=3D0 text=3D 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=3Drid=3D003,csn=3D20080923080903.375249Z#000000#001#000000 ...... I think the reason is that the ADD request for uid=3D5030708029E1 is received after that of uid=3D50307080309A, 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 --===============8290837314932947379==-- From mgwin@escp-eap.net Tue Sep 23 20:32:21 2008 From: mgwin@escp-eap.net To: openldap-bugs@openldap.org Subject: Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered Date: Tue, 23 Sep 2008 20:32:20 +0000 Message-ID: <200809232032.m8NKWK1s039078@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1477967913043154107==" --===============1477967913043154107== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, 23 Sep 2008 15:33:47 +0200 Michael Ströder 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? --===============1477967913043154107==-- From michael@stroeder.com Tue Sep 23 21:46:15 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered Date: Tue, 23 Sep 2008 21:46:15 +0000 Message-ID: <200809232146.m8NLkFGY041908@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1647877570441214429==" --===============1647877570441214429== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit mgwin(a)escp-eap.net wrote: > On Tue, 23 Sep 2008 15:33:47 +0200 > Michael Ströder 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. --===============1647877570441214429==-- From mbackes@symas.com Wed Sep 24 05:02:23 2008 From: mbackes@symas.com To: openldap-bugs@openldap.org Subject: (ITS#5710) syncrepl event loss with ppolicy and multiple masters Date: Wed, 24 Sep 2008 05:02:23 +0000 Message-ID: <200809240502.m8O52Npq056988@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1889955301506253550==" --===============1889955301506253550== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============1889955301506253550==-- From stef@memberwebs.com Wed Sep 24 11:21:22 2008 From: stef@memberwebs.com To: openldap-bugs@openldap.org Subject: Re: ITS#5581 reopened Date: Wed, 24 Sep 2008 11:21:22 +0000 Message-ID: <200809241121.m8OBLMDZ091642@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7538435911354021067==" --===============7538435911354021067== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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. >=20 > p. >=20 >=20 > Ing. Pierangelo Masarati > OpenLDAP Core Team >=20 > 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 > ----------------------------------- >=20 >=20 --===============7538435911354021067==-- From sylvain.thomas@gmail.com Wed Sep 24 15:45:15 2008 From: sylvain.thomas@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5709) slapd sync provider skips some objects Date: Wed, 24 Sep 2008 15:45:14 +0000 Message-ID: <200809241545.m8OFjE5d003204@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2803165854919144235==" --===============2803165854919144235== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ------=3D_Part_8723_3706532.1222271104834 Content-Type: text/plain; charset=3DISO-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 ------=3D_Part_8723_3706532.1222271104834 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

May be this helps to better localize the origin of the p= roblem :
After adding log messages in the different functions of the file = syncprov.c I find that for an object replicated successfully the following fu= nctions are called in order :

syncprov_op_mod()
syncprov_op_response()
syncprov_matchops()
syn= cprov_qresp()
syncprov_qstart()
syncprov_qtask()
syncprov_qplay()syncprov_sendresp()

But in the for an object skipped by the sync prov= ider only the first two functions are called (no call is made to syncprov_mat= chops() etc.

Best Regards
Sylvain Thomas
------=3D_Part_8723_3706532.1222271104834-- --===============2803165854919144235==-- From quanah@zimbra.com Thu Sep 25 00:43:42 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered Date: Thu, 25 Sep 2008 00:43:41 +0000 Message-ID: <200809250043.m8P0hfNb033706@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5882390134957293090==" --===============5882390134957293090== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --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 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 . --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============5882390134957293090==-- From Guillaume.Rousse@inria.fr Thu Sep 25 13:05:42 2008 From: Guillaume.Rousse@inria.fr To: openldap-bugs@openldap.org Subject: (ITS#5711) Password Modify Exop don't return ppolicy control in case of error Date: Thu, 25 Sep 2008 13:05:41 +0000 Message-ID: <200809251305.m8PD5f6d095131@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0196033510845263875==" --===============0196033510845263875== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 retu= rn 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 =3D Net::LDAP->new('ldap.domain.com') or die "impossible to connect: $@"; my $result =3D $ldap->bind('cn=3Dfoo,dc=3Ddomain,dc=3Dcom', password =3D> 'ba= r'); die 'impossible to bind: ' . $result->error() if $result->code(); my $pp =3D Net::LDAP::Control::PasswordPolicy->new(); $result =3D $ldap->set_password( newpasswd =3D> 'a', control =3D> [ $pp ] ); my $control =3D $result->control(LDAP_CONTROL_PASSWORDPOLICY); print Dumper($control); --===============0196033510845263875==-- From ando@sys-net.it Thu Sep 25 21:32:18 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5711) Password Modify Exop don't return ppolicy control in case of error Date: Thu, 25 Sep 2008 21:32:18 +0000 Message-ID: <200809252132.m8PLWICu047011@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2553177366683846703==" --===============2553177366683846703== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Guillaume.Rousse(a)inria.fr wrote: > When Password Modify ExOp fails, due to ppolicy restrictions, it doesn't re= turn > any ppolicy control. Right: the control is created and attached to SlapReply, but the=20 callback is slap_cb_null(), and the control is removed from SlapReply=20 and destroyed before ppolicy_modify() returns. This is because extended=20 ops do not directly send response, but rather delegate it to the=20 frontend. I don't see an easy solution, other than taking response into=20 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 ----------------------------------- --===============2553177366683846703==-- From hyc@symas.com Fri Sep 26 04:52:17 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: ITS#5707 [Fwd: Re: 4.7.25 deadlock] Date: Fri, 26 Sep 2008 04:52:16 +0000 Message-ID: <200809260452.m8Q4qGgC070816@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1022578694334043629==" --===============1022578694334043629== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 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-- --===============1022578694334043629==-- From hyc@symas.com Fri Sep 26 06:27:46 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: ITS#5707 [Fwd: Re: 4.7.25 deadlock] Date: Fri, 26 Sep 2008 06:27:45 +0000 Message-ID: <200809260627.m8Q6RjXV077075@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1936094273818584119==" --===============1936094273818584119== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 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/ --===============1936094273818584119==-- From michael@stroeder.com Fri Sep 26 09:12:53 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: ITS#5707 [Fwd: Re: 4.7.25 deadlock] Date: Fri, 26 Sep 2008 09:12:53 +0000 Message-ID: <200809260912.m8Q9CrQh086655@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0085597988018448731==" --===============0085597988018448731== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 > > 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 > > --===============0085597988018448731==-- From ando@sys-net.it Fri Sep 26 12:26:20 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5711) Password Modify Exop don't return ppolicy control in case of error Date: Fri, 26 Sep 2008 12:26:19 +0000 Message-ID: <200809261226.m8QCQJL1000387@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2088441947032358566==" --===============2088441947032358566== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ando(a)sys-net.it wrote: > Guillaume.Rousse(a)inria.fr wrote: >=20 >> When Password Modify ExOp fails, due to ppolicy restrictions, it doesn't r= eturn >> any ppolicy control. >=20 > Right: the control is created and attached to SlapReply, but the=20 > callback is slap_cb_null(), and the control is removed from SlapReply=20 > and destroyed before ppolicy_modify() returns. This is because extended=20 > ops do not directly send response, but rather delegate it to the=20 > frontend. I don't see an easy solution, other than taking response into=20 > the exop handlers. An alternative approach would be to use a specific callback response=20 other that slap_cb_null() within passwd_extop() that duplicates and=20 brings back any controls set within the internal modify, so that they=20 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 ----------------------------------- --===============2088441947032358566==-- From essiambl@gmail.com Fri Sep 26 14:25:00 2008 From: essiambl@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5712) Could not set the connection timeout Date: Fri, 26 Sep 2008 14:25:00 +0000 Message-ID: <200809261425.m8QEP0r5007782@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4385546461122277915==" --===============4385546461122277915== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Luc-Andr=C3=A9 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 host= ed on apache httpd. Immediately after a server startup, I get these strange erro= rs 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 sp= arc hardware. --===============4385546461122277915==-- From quanah@zimbra.com Fri Sep 26 16:13:34 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: ITS#5707 [Fwd: Re: 4.7.25 deadlock] Date: Fri, 26 Sep 2008 16:13:33 +0000 Message-ID: <200809261613.m8QGDX23016928@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3727888926716895363==" --===============3727888926716895363== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 > > 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 --===============3727888926716895363==-- From rtdean@cytherianage.net Sat Sep 27 01:39:33 2008 From: rtdean@cytherianage.net To: openldap-bugs@openldap.org Subject: (ITS#5713) Documentation: olcDbMode incorrect at http://www.openldap.org/doc/admin24/slapdconf2.html Date: Sat, 27 Sep 2008 01:39:32 +0000 Message-ID: <200809270139.m8R1dWAB051031@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8937882089991942041==" --===============8937882089991942041== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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.h= tml provides an incorrect example for the olcDbMode attribute. The documentation reads: >>> 5.2.6.9. olcDbMode: 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 3= 84 will result in an octal permission of 0600, which is, I believe, what the documentation is attempting to state. --===============8937882089991942041==-- From ando@sys-net.it Sat Sep 27 08:08:20 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5711) Password Modify Exop don't return ppolicy control in case of error Date: Sat, 27 Sep 2008 08:08:19 +0000 Message-ID: <200809270808.m8R88JPA070213@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7481408643534884545==" --===============7481408643534884545== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Guillaume.Rousse(a)inria.fr wrote: > When Password Modify ExOp fails, due to ppolicy restrictions, it doesn't re= turn > any ppolicy control. Fixed in HEAD, please test. 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 ----------------------------------- --===============7481408643534884545==-- From ando@sys-net.it Sat Sep 27 08:11:05 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: ITS#5713 Date: Sat, 27 Sep 2008 08:11:05 +0000 Message-ID: <200809270811.m8R8B5Xh070892@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6425688516341337704==" --===============6425688516341337704== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Probably, the right fix consists in changing that attr's syntax to DirectoryString, and allow all syntaxes, from "--w-------" to passing the value to strtol(value, NULL, 0) etc. 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 ----------------------------------- --===============6425688516341337704==-- From ando@sys-net.it Sat Sep 27 08:20:20 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5712) Could not set the connection timeout Date: Sat, 27 Sep 2008 08:20:19 +0000 Message-ID: <200809270820.m8R8KJ2K072089@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4080891990022624899==" --===============4080891990022624899== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable essiambl(a)gmail.com wrote: > Full_Name: Luc-Andr=C3=A9 Essiambre > Version: 2.4.11 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.95.235.3) >=20 >=20 > I'm using openldap to authenticate users for our subversion repositories ho= sted > on apache httpd. Immediately after a server startup, I get these strange er= rors > saying "LDAP: Could not set the connection timeout" This message does not come from anything distributed with OpenLDAP=20 software, so it does not help isolate your issue. > 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 err= or. > Then it will work for a while, then those same errors will come back. You don't specify in what sense you're using OpenLDAP: do you use the=20 client libraries as part of a third-party clien to do a bind to a=20 third-party server, or do you use OpenLDAP as the LDAP server, or both?=20 If you use the client libraries with a third-party client, did you=20 build it with -DLDAP_DEPRECATED=3D1 ? This is required to expose=20 deprecated API to clients that make use of them. > 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. In any case, I don't see (yet) an OpenLDAP bug, so you should direct=20 further communications to openldap-technical(a)openldap.org, since your=20 problem mainly addresses interoperation with other software. 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 ----------------------------------- --===============4080891990022624899==-- From ando@sys-net.it Sat Sep 27 19:48:59 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5714) [feature request] operational attrs defined via configuration Date: Sat, 27 Sep 2008 19:48:58 +0000 Message-ID: <200809271948.m8RJmwMq096045@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6876715392289164119==" --===============6876715392289164119== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.30.78.88) Currently, the attributeType statement does not allow to define operational attributes. The rationale was that operational attributes are somehow application-maintained, so configuration-defined attrs would be essentially unmaintainable. At the same time, modules that are able to maintain operatio= nal attributes can register them bypassing some of the checks attributes defined = via configuration must pass. However, the availability of the "relax" control co= uld make this restriction too strict. In fact, there are works in progress (e.g. draft-wahl-ldap-adminaddr) that define operational attrs which could easily be defined via configuration and maintained via the relax control. This is a feature request to suggest the possibility to define operational attrs via configuration. p. --===============6876715392289164119==-- From sylvain.thomas@gmail.com Mon Sep 29 09:30:58 2008 From: sylvain.thomas@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5709) slapd sync provider skips some objects Date: Mon, 29 Sep 2008 09:30:58 +0000 Message-ID: <200809290930.m8T9UwnG017988@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6587911558911807616==" --===============6587911558911807616== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is not a patch suggestion but may be it helps to better see the problem's origin : I applied the following patch to syncprov.c and I got good results. The concerned objects are sent with a NULL cookie but they are replicated well. The contextCSN is made up by the subsequent objects. Thanks and best regards Sylvain Thomas. ============================================ --- syncprov.c.orig 2008-09-29 11:08:36.000000000 +0200 +++ syncprov.c 2008-09-29 11:10:33.000000000 +0200 @@ -1642,8 +1642,6 @@ } } else { /* internal ops that aren't meant to be replicated */ - ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock ); - return SLAP_CB_CONTINUE; } /* Don't do any processing for consumer contextCSN updates */ --===============6587911558911807616==-- From michael@stroeder.com Mon Sep 29 12:44:22 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: (ITS#5715) segfault in libdb Date: Mon, 29 Sep 2008 12:44:22 +0000 Message-ID: <200809291244.m8TCiMmR037594@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8335345410918900767==" --===============8335345410918900767== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.103.245) HI! I'm experiencing seg faults when using SASL/EXTERNAL bind when connected over ldapi://. I will try to examine this further. segfault at 0 ip b7f21d4c sp b370fd10 error 6 in libdb-4.6.so[b7ef9000+14f000] Ciao, Michael. --===============8335345410918900767==-- From michael@stroeder.com Mon Sep 29 12:48:20 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: (ITS#5716) test046-dds failed (exit 127): invalid ELF header Date: Mon, 29 Sep 2008 12:48:20 +0000 Message-ID: <200809291248.m8TCmKnm038915@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2360644007314661732==" --===============2360644007314661732== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Michael Str=C3=B6der Version: RE24 OS: openSUSE Linux 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.103.245) I will examine why this fails. >>>>> Starting test046-dds ... running defines.sh Running slapadd to build slapd database... /home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/= lt-slapd: error while loading shared libraries: /home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_r/= .libs/libldap_r-2.4-releng.so.2: invalid ELF header slapadd failed (127)! >>>>> ./scripts/test046-dds failed (exit 127) make[2]: *** [bdb-yes] Error 127 make[2]: Leaving directory `/home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2 --===============2360644007314661732==-- From h.b.furuseth@usit.uio.no Mon Sep 29 13:33:01 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5716) test046-dds failed (exit 127): invalid ELF header Date: Mon, 29 Sep 2008 13:33:00 +0000 Message-ID: <200809291333.m8TDX04A055348@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3127836711473603849==" --===============3127836711473603849== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable michael(a)stroeder.com writes: > error while loading shared libraries: > /home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_= r/.libs/libldap_r-2.4-releng.so.2: > invalid ELF header Hopefully a PEBKAC. Loading libraries built for another architecture, or something like that. --=20 Hallvard --===============3127836711473603849==-- From menu@netbsd.org Mon Sep 29 13:34:41 2008 From: menu@netbsd.org To: openldap-bugs@openldap.org Subject: (ITS#5717) slapo-dynlist expantion failed for mapped attributes Date: Mon, 29 Sep 2008 13:34:41 +0000 Message-ID: <200809291334.m8TDYf71056081@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4490664165186147550==" --===============4490664165186147550== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Emmanuel Dreyfus Version: OpenLDAP-2.4.11 OS: NetBSD-4.0 URL:=20 Submission from: (NULL) (193.54.82.42) If slapo-dynlist is configured with attribute mapping, dynlist expantion will only work if the member attribute in included in the searched attriute set. Here is an example: Config: overlay dynlist dynlist-attrset ExMailAddress memberURL mailbox:revalias Searched entry: dn: mailAddress=3Dfoo-employee(a)example.net,o=3Dex objectClass: exMailAddress mailAddress: foo-employee(a)example.net memberURL: ldap:///o=3Dex,revalias?sub?(&(objectClass=3DexPerson)(employer= =3Dfoo))=20 Expantion looks up objects like this: dn: uid=3Djdoe,o=3Dex objectClass: exPerson uid: jdoe revalias: john.doe(a)example.net employer: foo With the member attribute in the searched attribute set: $ ldapsearch mailAddress=3Dfoo-employee(a)example mailbox revalias dn: mailAddress=3Dfoo-employee(a)example.net,o=3Dex mailbox: john.doe(a)example.net mailbox: joe.luser(a)example.net mailbox: emmanuel.dreyfus(a)example.net=20 Without it: $ ldapsearch mailAddress=3Dfoo-employee(a)example mailbox dn: mailAddress=3Dfoo-employee(a)example.net,o=3Dex Note that if no attribute set is provided, it works: $ ldapsearch mailAddress=3Dfoo-employee(a)example dn: mailAddress=3Dfoo-employee(a)example.net,o=3Dex objectClass: exMailAddress mailAddress: foo-employee(a)example.net mailbox: john.doe(a)example.net mailbox: joe.luser(a)example.net mailbox: emmanuel.dreyfus(a)example.net memberURL: ldap:///o=3Dex,revalias?sub?(&(objectClass=3DexPerson)(employer= =3Dfoo)) I should provide a fix for that soon. --===============4490664165186147550==-- From prashantk100@gmail.com Mon Sep 29 15:49:37 2008 From: Prashant kulkarni To: openldap-bugs@openldap.org Subject: Bug- Enforcing validation when validator is NULL Date: Mon, 29 Sep 2008 21:19:25 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0837033747713503908==" --===============0837033747713503908== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi When I am trying to add/edit the value to the attribute "protocol information" which is required in our schema I am getting the error Invalid syntax :protocol information: no validator for syntax 1.3.6.1.4.1.1466.115.121.1.42 from the earlier mailing list I have found The problem seems to be lack of validations in the schema_init.c source code for attribure 'Protocol Information' this attribute protocolInformation is defined in core.schema {"( 1.3.6.1.4.1.1466.115.121.1.42 DESC 'Protocol Information' )", 0, NULL, NULL, NULL}, including values like dnPretty ,UTF8StringValidate..etc in the code instead of NULL values will resolve my problem, but then that require the custom build and I have to do for all the attributes where validation is defined as NULL. I personally feel that for those attributes where validation are NULL in schema_init.c and other schema files, the openLDAP should not force the validation and give this error message, as all these attributes in which validation are not defined becomes unusable . In Tivoli/Sun and Microsoft Active directory LDAP validation is not enforced where validation is defined as NULL hence I am not getting these kind of error in Tivoli/Sun and Microsoft Active directory for editing of this attribute . So any idea how to resolve this ? there is any way to modify any of the config file in openldap to disable this validation for protocol information ? do I have to raise bug request for the same and is this going to be fixed in next openLDAP release. ? Any help and suggestions in this direction is highly appreciated. thanks and regards Prashant --===============0837033747713503908== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.htm" MIME-Version: 1.0 PGRpdiBkaXI9Imx0ciI+PHA+SGk8YnI+V2hlbiBJIGFtIHRyeWluZyB0byBhZGQvZWRpdCB0aGUg dmFsdWUgdG8gdGhlIGF0dHJpYnV0ZSAmcXVvdDtwcm90b2NvbCBpbmZvcm1hdGlvbiZxdW90OyB3 aGljaCBpcyByZXF1aXJlZCBpbiBvdXIgc2NoZW1hIEkgYW0gZ2V0dGluZyB0aGUgZXJyb3I8YnI+ Jm5ic3A7PGJyPkludmFsaWQgc3ludGF4IDpwcm90b2NvbCBpbmZvcm1hdGlvbjogbm8gdmFsaWRh dG9yIGZvciBzeW50YXggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuNDI8YnI+CiZuYnNwOyZu YnNwOzxicj5mcm9tIHRoZSBlYXJsaWVyIG1haWxpbmcgbGlzdCBJIGhhdmUgZm91bmQgVGhlIHBy b2JsZW0gc2VlbXMgdG8gYmUgbGFjayBvZiB2YWxpZGF0aW9ucyBpbiB0aGUgc2NoZW1hX2luaXQu YyBzb3VyY2UgY29kZSBmb3IgYXR0cmlidXJlICYjMzk7UHJvdG9jb2wgSW5mb3JtYXRpb24mIzM5 OyZuYnNwOzwvcD48cD50aGlzIGF0dHJpYnV0ZSBwcm90b2NvbEluZm9ybWF0aW9uIGlzIGRlZmlu ZWQgIGluIGNvcmUuc2NoZW1hPGJyPgombmJzcDs8YnI+Jm5ic3A7eyZxdW90OyggMS4zLjYuMS40 LjEuMTQ2Ni4xMTUuMTIxLjEuNDIgREVTQyAmIzM5O1Byb3RvY29sIEluZm9ybWF0aW9uJiMzOTsg KSZxdW90Oyw8YnI+Jm5ic3A7IDAsIE5VTEwsIE5VTEwsIE5VTEx9LDxicj4mbmJzcDs8YnI+Jm5i c3A7aW5jbHVkaW5nIHZhbHVlcyBsaWtlICBkblByZXR0eSAsVVRGOFN0cmluZ1ZhbGlkYXRlLi5l dGMgaW4gdGhlIGNvZGUgaW5zdGVhZCBvZiBOVUxMIHZhbHVlcyB3aWxsIHJlc29sdmUgbXkgcHJv YmxlbSwgYnV0IHRoZW4gdGhhdCByZXF1aXJlIHRoZSBjdXN0b20gYnVpbGQgYW5kIEkgaGF2ZSB0 byBkbyBmb3IgYWxsIHRoZSBhdHRyaWJ1dGVzIHdoZXJlIHZhbGlkYXRpb24gaXMgZGVmaW5lZCBh cyBOVUxMLjwvcD4KPHA+SSBwZXJzb25hbGx5IGZlZWwgdGhhdCBmb3IgdGhvc2UgYXR0cmlidXRl cyB3aGVyZSB2YWxpZGF0aW9uIGFyZSBOVUxMIGluIHNjaGVtYV9pbml0LmMgYW5kIG90aGVyIHNj aGVtYSBmaWxlcywgdGhlIG9wZW5MREFQIHNob3VsZCBub3QgZm9yY2UgdGhlIHZhbGlkYXRpb24g YW5kIGdpdmUgdGhpcyBlcnJvciBtZXNzYWdlLCBhcyBhbGwgdGhlc2UgIGF0dHJpYnV0ZXMgaW4g d2hpY2ggdmFsaWRhdGlvbiBhcmUgbm90IGRlZmluZWQgYmVjb21lcyB1bnVzYWJsZSAuPGJyPgo8 YnI+SW4gVGl2b2xpL1N1biBhbmQgTWljcm9zb2Z0IEFjdGl2ZSBkaXJlY3RvcnkgTERBUCB2YWxp ZGF0aW9uIGlzIG5vdCBlbmZvcmNlZCB3aGVyZSB2YWxpZGF0aW9uIGlzIGRlZmluZWQgYXMgTlVM TCBoZW5jZSBJIGFtIG5vdCBnZXR0aW5nIHRoZXNlIGtpbmQgb2YgZXJyb3IgaW4gVGl2b2xpL1N1 biBhbmQgTWljcm9zb2Z0IEFjdGl2ZSBkaXJlY3RvcnkgZm9yIGVkaXRpbmcgb2YgdGhpcyBhdHRy aWJ1dGUgLjxicj4KJm5ic3A7PGJyPlNvIGFueSBpZGVhIGhvdyB0byByZXNvbHZlIHRoaXMgPyB0 aGVyZSBpcyBhbnkgd2F5IHRvIG1vZGlmeSBhbnkgb2YgdGhlIGNvbmZpZyBmaWxlIGluIG9wZW5s ZGFwIHRvIGRpc2FibGUgdGhpcyB2YWxpZGF0aW9uIGZvciBwcm90b2NvbCBpbmZvcm1hdGlvbiA/ PGJyPmRvIEkgaGF2ZSB0byByYWlzZSBidWcgcmVxdWVzdCBmb3IgdGhlIHNhbWUgYW5kIGlzIHRo aXMgZ29pbmcgdG8gYmUgZml4ZWQgaW4gbmV4dCBvcGVuTERBUCByZWxlYXNlLiA/PGJyPgombmJz cDsmbmJzcDs8YnI+QW55IGhlbHAgYW5kIHN1Z2dlc3Rpb25zIGluIHRoaXMgZGlyZWN0aW9uIGlz IGhpZ2hseSBhcHByZWNpYXRlZC4gPGJyPjxicj4mbmJzcDt0aGFua3MgYW5kIHJlZ2FyZHM8YnI+ UHJhc2hhbnQ8YnI+PGJyPjwvcD48cD48YnI+PC9wPjxicj48L2Rpdj4K --===============0837033747713503908==-- From ando@sys-net.it Mon Sep 29 15:57:54 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: ITS#5717 Date: Mon, 29 Sep 2008 15:57:54 +0000 Message-ID: <200809291557.m8TFvslA071313@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1367485228180847080==" --===============1367485228180847080== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Emmanuel, I have a fix, should I go and commit it? 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 ----------------------------------- --===============1367485228180847080==-- From manu@netbsd.org Mon Sep 29 16:14:52 2008 From: manu@netbsd.org To: openldap-bugs@openldap.org Subject: fix (ITS#5715) Date: Mon, 29 Sep 2008 16:14:52 +0000 Message-ID: <200809291614.m8TGEqf0073297@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3010927929142448396==" --===============3010927929142448396== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=3Dus-ascii Content-Disposition: inline Attached is a fix for the problem:=20 1) if the member attribute is not part of the requested attribute set,=20 but the mapped attributeis, then we still need to generate the dynlist 2) in this cas, we must add the member attribute to the searched=20 attributes. --=20 Emmanuel Dreyfus manu(a)netbsd.org --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=3Dus-ascii Content-Disposition: attachment; filename=3D"dynlist.patch" --- servers/slapd/overlays/dynlist.c.orig 2008-07-10 02:43:03.000000000 +0200 +++ servers/slapd/overlays/dynlist.c 2008-09-29 17:43:07.000000000 +0200 @@ -369,9 +369,12 @@ =20 /* Don't generate member list if it wasn't requested */ for ( dlm =3D dli->dli_dlm; dlm; dlm =3D dlm->dlm_next ) { if ( userattrs || - ad_inlist( dlm->dlm_member_ad, rs->sr_attrs ) )=20 + ad_inlist( dlm->dlm_member_ad, rs->sr_attrs ) ) + break; + if ( dlm->dlm_mapped_ad && + ad_inlist( dlm->dlm_mapped_ad, rs->sr_attrs ) ) break; } if ( dli->dli_dlm && !dlm ) return SLAP_CB_CONTINUE; @@ -477,8 +480,11 @@ } else { for ( i =3D 0; lud->lud_attrs[i]; i++) /* just count */ ; =20 + if ( dlm && dlm->dlm_member_ad && !ad_inlist( dlm->dlm_member_ad, rs->sr_= attrs ) ) + i++; + o.ors_attrs =3D op->o_tmpcalloc( i + 1, sizeof( AttributeName ), op->o_tm= pmemctx ); for ( i =3D 0, j =3D 0; lud->lud_attrs[i]; i++) { const char *text =3D NULL; =09 @@ -515,8 +521,14 @@ =20 j++; } =20 + if ( dlm && dlm->dlm_member_ad && !ad_inlist( dlm->dlm_member_ad, rs->sr_= attrs ) ) { + o.ors_attrs[j].an_name =3D dlm->dlm_member_ad->ad_cname; + o.ors_attrs[j].an_desc =3D dlm->dlm_member_ad; + j++; + } + if ( j =3D=3D 0 ) { goto cleanup; } =09 --3V7upXqbjpZ4EhLz-- --===============3010927929142448396==-- From manu@netbsd.org Mon Sep 29 16:25:06 2008 From: manu@netbsd.org To: openldap-bugs@openldap.org Subject: fix (ITS#5717) Date: Mon, 29 Sep 2008 16:25:06 +0000 Message-ID: <200809291625.m8TGP6am075950@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2064771380917189238==" --===============2064771380917189238== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --E13BgyNx05feLLmH Content-Type: text/plain; charset=3Dus-ascii Content-Disposition: inline Attached is a fix for the problem: 1) if the member attribute is not part of the requested attribute set, but the mapped attributeis, then we still need to generate the dynlist 2) in this cas, we must add the member attribute to the searched attributes. --=20 Emmanuel Dreyfus manu(a)netbsd.org --E13BgyNx05feLLmH Content-Type: text/plain; charset=3Dus-ascii Content-Disposition: attachment; filename=3D"dynlist.patch" --- servers/slapd/overlays/dynlist.c.orig 2008-07-10 02:43:03.000000000 +0200 +++ servers/slapd/overlays/dynlist.c 2008-09-29 17:43:07.000000000 +0200 @@ -369,9 +369,12 @@ =20 /* Don't generate member list if it wasn't requested */ for ( dlm =3D dli->dli_dlm; dlm; dlm =3D dlm->dlm_next ) { if ( userattrs || - ad_inlist( dlm->dlm_member_ad, rs->sr_attrs ) )=20 + ad_inlist( dlm->dlm_member_ad, rs->sr_attrs ) ) + break; + if ( dlm->dlm_mapped_ad && + ad_inlist( dlm->dlm_mapped_ad, rs->sr_attrs ) ) break; } if ( dli->dli_dlm && !dlm ) return SLAP_CB_CONTINUE; @@ -477,8 +480,11 @@ } else { for ( i =3D 0; lud->lud_attrs[i]; i++) /* just count */ ; =20 + if ( dlm && dlm->dlm_member_ad && !ad_inlist( dlm->dlm_member_ad, rs->sr_= attrs ) ) + i++; + o.ors_attrs =3D op->o_tmpcalloc( i + 1, sizeof( AttributeName ), op->o_tm= pmemctx ); for ( i =3D 0, j =3D 0; lud->lud_attrs[i]; i++) { const char *text =3D NULL; =09 @@ -515,8 +521,14 @@ =20 j++; } =20 + if ( dlm && dlm->dlm_member_ad && !ad_inlist( dlm->dlm_member_ad, rs->sr_= attrs ) ) { + o.ors_attrs[j].an_name =3D dlm->dlm_member_ad->ad_cname; + o.ors_attrs[j].an_desc =3D dlm->dlm_member_ad; + j++; + } + if ( j =3D=3D 0 ) { goto cleanup; } =09 --E13BgyNx05feLLmH-- --===============2064771380917189238==-- From manu@netbsd.org Mon Sep 29 16:25:49 2008 From: manu@netbsd.org To: openldap-bugs@openldap.org Subject: wrong ITS (ITS#5715) Date: Mon, 29 Sep 2008 16:25:48 +0000 Message-ID: <200809291625.m8TGPmHm076593@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1694380106369786213==" --===============1694380106369786213== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Please disregard my previous mail, I appended to the wrong ITS. -- Emmanuel Dreyfus manu(a)netbsd.org --===============1694380106369786213==-- From michael@stroeder.com Mon Sep 29 17:26:29 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5716) test046-dds failed (exit 127): invalid ELF header Date: Mon, 29 Sep 2008 17:26:28 +0000 Message-ID: <200809291726.m8THQSRp094966@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2397948768155090056==" --===============2397948768155090056== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hallvard B Furuseth wrote: > michael(a)stroeder.com writes: >> error while loading shared libraries: >> /home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap= _r/.libs/libldap_r-2.4-releng.so.2: >> invalid ELF header >=20 > Hopefully a PEBKAC. Loading libraries built for another architecture, > or something like that. I re-ran all the tests and it worked. Maybe it was caused by invoking 'make install' as root while still running 'make test' as normal user. Ciao, Michael. --===============2397948768155090056==-- From ando@sys-net.it Mon Sep 29 17:30:04 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5715) segfault in libdb Date: Mon, 29 Sep 2008 17:30:03 +0000 Message-ID: <200809291730.m8THU3mC095742@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4559855868616648051==" --===============4559855868616648051== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable michael(a)stroeder.com wrote: > I'm experiencing seg faults when using SASL/EXTERNAL bind when connected ov= er > ldapi://. I will try to examine this further. >=20 > segfault at 0 ip b7f21d4c sp b370fd10 error 6 in libdb-4.6.so[b7ef9000+14f0= 00] This bug is typical of loading a libsasl2 module (libsasldb) built with=20 a Berkeley DB version different from the one slapd was built with, or=20 loading a libsasl2 module built with a different version of libsasl2=20 than the one slapd was built with. Can you check? 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 ----------------------------------- --===============4559855868616648051==-- From michael@stroeder.com Mon Sep 29 17:38:20 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5715) segfault in libdb Date: Mon, 29 Sep 2008 17:38:20 +0000 Message-ID: <200809291738.m8THcKOQ096658@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7903767922725483203==" --===============7903767922725483203== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: >> I'm experiencing seg faults when using SASL/EXTERNAL bind when >> connected over >> ldapi://. I will try to examine this further. >> >> segfault at 0 ip b7f21d4c sp b370fd10 error 6 in >> libdb-4.6.so[b7ef9000+14f000] >=20 > This bug is typical of loading a libsasl2 module (libsasldb) built with > a Berkeley DB version different from the one slapd was built with, or > loading a libsasl2 module built with a different version of libsasl2 > than the one slapd was built with. Can you check? I will check this right now. Anyway find below the tail of the server's log when invoking ldapwhoami -H ldapi://%2Fhome%2Fmichael%2Ftemp%2Fopenldap-testbed-RE24%2Fslapd1 -Y EXTERNAL Ciao, Michael. --------------------------------- snip -------------------------------- =3D=3D> sasl_bind: dn=3D"" mech=3DEXTERNAL datalen=3D0 SASL Canonicalize [conn=3D0]: authcid=3D"gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Da= uth" slap_sasl_getdn: conn 0 id=3DgidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Dauth [l= en=3D59] =3D=3D>slap_sasl2dn: converting SASL name gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Dauth to a DN =3D=3D> rewrite_context_apply [depth=3D1] string=3D'gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Dau= th' =3D=3D> rewrite_rule_apply rule=3D'gidnumber=3D([0-9]+)\+uidnumber=3D([0-9]+),cn=3Dpeercred,cn=3Dexterna= l,cn=3Dauth' string=3D'gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Dau= th' [1 pass(es)] =3D=3D> rewrite_context_apply [depth=3D1] res=3D{0,'ldap:///ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal??sub?(&(objectClass= =3DposixAccount)(uidNumber=3D500)(gidNumber=3D100))'} [rw] authid: "gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Dauth" -> "ldap:///ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal??sub?(&(objectClass=3DposixAc= count)(uidNumber=3D500)(gidNumber=3D100))" slap_parseURI: parsing ldap:///ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal??sub?(&(objectClass=3DposixAcc= ount)(uidNumber=3D500)(gidNumber=3D100)) ldap_url_parse_ext(ldap:///ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal??sub?(&(obj= ectClass=3DposixAccount)(uidNumber=3D500)(gidNumber=3D100))) put_filter: "(&(objectClass=3DposixAccount)(uidNumber=3D500)(gidNumber=3D100)= )" put_filter: AND put_filter_list "(objectClass=3DposixAccount)(uidNumber=3D500)(gidNumber=3D10= 0)" put_filter: "(objectClass=3DposixAccount)" put_filter: simple put_simple_filter: "objectClass=3DposixAccount" put_filter: "(uidNumber=3D500)" put_filter: simple put_simple_filter: "uidNumber=3D500" put_filter: "(gidNumber=3D100)" put_filter: simple put_simple_filter: "gidNumber=3D100" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: >>> dnNormalize: =3D> ldap_bv2dn(ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal,0) <=3D ldap_bv2dn(ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal)=3D0 <<< dnNormalize: slap_sasl2dn: performing internal search (base=3Dou=3Dschulung,dc=3Dstroeder,dc=3Dlocal, scope=3D2) =3D> hdb_search bdb_dn2entry("ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal") =3D> access_allowed: auth access to "ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal" "entry" requested =3D> dn: [4] ou=3Dusers,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal =3D> dn: [5] ou=3Dgroups,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal =3D> dn: [6] ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal =3D> acl_get: [6] matched =3D> acl_get: [6] attr entry =3D> acl_mask: access to entry "ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal", attr "entry" requested =3D> acl_mask: to all values by "", (=3D0) <=3D check a_dn_pat: * <=3D acl_mask: [2] applying none(=3D0) (stop) <=3D acl_mask: [2] mask: none(=3D0) =3D> slap_access_allowed: auth access denied by none(=3D0) =3D> access_allowed: no more rules send_ldap_result: conn=3D0 op=3D0 p=3D3 send_ldap_result: err=3D32 matched=3D"" text=3D"" <=3D=3Dslap_sasl2dn: Converted SASL name to SASL Canonicalize [conn=3D0]: slapAuthcDN=3D"gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn= =3Dauth" ./start-slapd1.sh: line 14: 20820 Segmentation fault ${OPENLDAP_PREFIX}/libexec/slapd -d stats,acl,args,trace,sync -h "ldap://0.0.0.0:2071 ldapi://%2Fhome%2Fmichael%2Ftemp%2Fopenldap-testbed-RE24%2Fslapd1" -n slapd-schulung-1 -u michael -f ${LOCALCONFIG}/slapd-1.conf -F ${LOCALCONFIG}/slapd-1.conf.d michael(a)nb2:~/temp/openldap-testbed-RE24> --===============7903767922725483203==-- From ando@sys-net.it Mon Sep 29 17:49:22 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5715) segfault in libdb Date: Mon, 29 Sep 2008 17:49:21 +0000 Message-ID: <200809291749.m8THnLIP098170@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7491253747950693630==" --===============7491253747950693630== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable michael(a)stroeder.com wrote: > I will check this right now. Anyway find below the tail of the server's > log when invoking >=20 > ldapwhoami -H > ldapi://%2Fhome%2Fmichael%2Ftemp%2Fopenldap-testbed-RE24%2Fslapd1 -Y > EXTERNAL OK, at a first glance, I see two things: 1) your search finds nothing, probably because anonymous cannot read the=20 "entry" pseudo-attribute of "ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal" (see [1]) 2) this causes a sigsegv, which Is Bad (TM). You should check whether the result of those ACLs is correct, and in the=20 meanwhile provide a core dump, to fix the sigsegv issue. p. > --------------------------------- snip -------------------------------- > =3D=3D> sasl_bind: dn=3D"" mech=3DEXTERNAL datalen=3D0 > SASL Canonicalize [conn=3D0]: > authcid=3D"gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn= =3Dauth" > slap_sasl_getdn: conn 0 > id=3DgidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Dauth = [len=3D59] > =3D=3D>slap_sasl2dn: converting SASL name > gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Dauth to a = DN > =3D=3D> rewrite_context_apply [depth=3D1] > string=3D'gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3D= auth' > =3D=3D> rewrite_rule_apply > rule=3D'gidnumber=3D([0-9]+)\+uidnumber=3D([0-9]+),cn=3Dpeercred,cn=3Dexter= nal,cn=3Dauth' > string=3D'gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3D= auth' [1 > pass(es)] > =3D=3D> rewrite_context_apply [depth=3D1] > res=3D{0,'ldap:///ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal??sub?(&(objectClas= s=3DposixAccount)(uidNumber=3D500)(gidNumber=3D100))'} > [rw] authid: > "gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,cn=3Dauth" -> > "ldap:///ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal??sub?(&(objectClass=3Dposix= Account)(uidNumber=3D500)(gidNumber=3D100))" > slap_parseURI: parsing > ldap:///ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal??sub?(&(objectClass=3DposixA= ccount)(uidNumber=3D500)(gidNumber=3D100)) > ldap_url_parse_ext(ldap:///ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal??sub?(&(o= bjectClass=3DposixAccount)(uidNumber=3D500)(gidNumber=3D100))) > put_filter: "(&(objectClass=3DposixAccount)(uidNumber=3D500)(gidNumber=3D10= 0))" > put_filter: AND > put_filter_list "(objectClass=3DposixAccount)(uidNumber=3D500)(gidNumber=3D= 100)" > put_filter: "(objectClass=3DposixAccount)" > put_filter: simple > put_simple_filter: "objectClass=3DposixAccount" > put_filter: "(uidNumber=3D500)" > put_filter: simple > put_simple_filter: "uidNumber=3D500" > put_filter: "(gidNumber=3D100)" > put_filter: simple > put_simple_filter: "gidNumber=3D100" > ber_scanf fmt ({mm}) ber: > ber_scanf fmt ({mm}) ber: > ber_scanf fmt ({mm}) ber: >>>> dnNormalize: > =3D> ldap_bv2dn(ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal,0) > <=3D ldap_bv2dn(ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal)=3D0 > =3D> ldap_dn2bv(272) > <=3D ldap_dn2bv(ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal)=3D0 > <<< dnNormalize: > slap_sasl2dn: performing internal search > (base=3Dou=3Dschulung,dc=3Dstroeder,dc=3Dlocal, scope=3D2) > =3D> hdb_search > bdb_dn2entry("ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal") > =3D> access_allowed: auth access to "ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal" > "entry" requested > =3D> dn: [4] ou=3Dusers,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal > =3D> dn: [5] ou=3Dgroups,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal > =3D> dn: [6] ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal > =3D> acl_get: [6] matched > =3D> acl_get: [6] attr entry > =3D> acl_mask: access to entry "ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal", at= tr > "entry" requested > =3D> acl_mask: to all values by "", (=3D0) > <=3D check a_dn_pat: * > <=3D acl_mask: [2] applying none(=3D0) (stop) > <=3D acl_mask: [2] mask: none(=3D0) > =3D> slap_access_allowed: auth access denied by none(=3D0) [1] > =3D> access_allowed: no more rules > send_ldap_result: conn=3D0 op=3D0 p=3D3 > send_ldap_result: err=3D32 matched=3D"" text=3D"" > <=3D=3Dslap_sasl2dn: Converted SASL name to > SASL Canonicalize [conn=3D0]: > slapAuthcDN=3D"gidNumber=3D100+uidNumber=3D500,cn=3Dpeercred,cn=3Dexternal,= cn=3Dauth" > ./start-slapd1.sh: line 14: 20820 Segmentation fault > ${OPENLDAP_PREFIX}/libexec/slapd -d stats,acl,args,trace,sync -h > "ldap://0.0.0.0:2071 > ldapi://%2Fhome%2Fmichael%2Ftemp%2Fopenldap-testbed-RE24%2Fslapd1" -n > slapd-schulung-1 -u michael -f ${LOCALCONFIG}/slapd-1.conf -F > ${LOCALCONFIG}/slapd-1.conf.d > michael(a)nb2:~/temp/openldap-testbed-RE24> >=20 >=20 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 ----------------------------------- --===============7491253747950693630==-- From ando@sys-net.it Mon Sep 29 17:55:43 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5718) [documentation] Mention dontusecopy control in conjunction with slapo-chain(5) Date: Mon, 29 Sep 2008 17:55:42 +0000 Message-ID: <200809291755.m8THtgUq099887@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4787743066682524460==" --===============4787743066682524460== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/dontusecopy-chain-2008-09-29-pierangelo-= masarati.patch Submission from: (NULL) (81.72.89.40) Submitted by: ando I'm not too familiar with sdl; moreover, I'm not sure whether this is the rig= ht place to mention the dontusecopy control first. In any case, it seems worth mentioning here this good practice for clients that might write to shadow DSAs and immediately read back. See patch at URL. Cheers, p. --===============4787743066682524460==-- From rein@OpenLDAP.org Mon Sep 29 17:58:02 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: (ITS#5719) Reset syncrepl interval after resceduling paused task Date: Mon, 29 Sep 2008 17:58:01 +0000 Message-ID: <200809291758.m8THw1dO000394@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1769442082264426634==" --===============1769442082264426634== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Rein Tollevik Version: RE_24 OS:=20 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein When a syncrepl task is paused after the thread pool is pauses (due to dynamic configuration updates) it is rescheduled to run immediately. But the interval is not put back again, which causes the slapd_daemon_task() to exercise the C= PU rescheduling the syncrepl task until the next clock second ticks off. I'll commit a fix shortly. Rein Tollevik Basefarm AS --===============1769442082264426634==-- From michael@stroeder.com Mon Sep 29 18:12:11 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5715) segfault in libdb Date: Mon, 29 Sep 2008 18:12:10 +0000 Message-ID: <200809291812.m8TICAiQ003440@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2741866268629184059==" --===============2741866268629184059== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: > >> I'm experiencing seg faults when using SASL/EXTERNAL bind when >> connected over >> ldapi://. I will try to examine this further. >> >> segfault at 0 ip b7f21d4c sp b370fd10 error 6 in >> libdb-4.6.so[b7ef9000+14f000] > > This bug is typical of loading a libsasl2 module (libsasldb) built with > a Berkeley DB version different from the one slapd was built with, or > loading a libsasl2 module built with a different version of libsasl2 > than the one slapd was built with. Can you check? Now I've rebuilt with the pre-installed BDB 4.5 (openSUSE 11.0) packages and it works. Hmm... Ciao, Michael. --===============2741866268629184059==-- From quanah@zimbra.com Mon Sep 29 18:24:33 2008 From: Quanah Gibson-Mount To: openldap-bugs@openldap.org Subject: Re: Bug- Enforcing validation when validator is NULL Date: Mon, 29 Sep 2008 11:24:03 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2421167041588331252==" --===============2421167041588331252== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On September 29, 2008 9:19:25 PM +0530 Prashant kulkarni wrote: > Any help and suggestions in this direction is highly appreciated. Email your question to openldap-software(a)openldap.org or openldap-technical(a)openldap.org. Actual bugs should be filed at . --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============2421167041588331252==-- From ando@sys-net.it Mon Sep 29 18:25:51 2008 From: Pierangelo Masarati To: openldap-bugs@openldap.org Subject: Re: Bug- Enforcing validation when validator is NULL Date: Mon, 29 Sep 2008 20:25:14 +0200 Message-ID: <48E11D8A.7090706@sys-net.it> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5411871414421953081==" --===============5411871414421953081== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Prashant kulkarni wrote: > When I am trying to add/edit the value to the attribute "protocol > information" which is required in our schema I am getting the error > > Invalid syntax :protocol information: no validator for syntax > 1.3.6.1.4.1.1466.115.121.1.42 > > from the earlier mailing list I have found The problem seems to be lack of > validations in the schema_init.c source code for attribure 'Protocol > Information' > > this attribute protocolInformation is defined in core.schema > > {"( 1.3.6.1.4.1.1466.115.121.1.42 DESC 'Protocol Information' )", > 0, NULL, NULL, NULL}, This syntax has been removed from RFC 2252 when revised in RFC 4517, as explicitly indicated in notes 21 and 28 to Appendix B of the latter. This because although mentioned in RFC 2252, those syntaxes were not defined and thus posing interoperability problems. I believe OpenLDAP should move one step forward toward RFC 451* compliance by removing (actually, marking as OBSOLETE) those attributes from *.schema files and those syntaxes from hardcoded ones. > including values like dnPretty ,UTF8StringValidate..etc in the code instead > of NULL values will resolve my problem, but then that require the custom > build and I have to do for all the attributes where validation is defined as > NULL. Not entirely true: you could implement a run-time module that looks up those syntaxes and modifies the appropriate pointers right after initialization. Unless significant changes in the related slapd structures or API, your module would seamlessly breeze through minor and even major releases. Furthermore, if those syntaxes are removed from the hardcoded ones, you could define them via a custom schema file using the X-SUBST feature (ITS#5663) recently introduced in HEAD code. It allows to provide a substitute syntax for unimplemented ones. > I personally feel that for those attributes where validation are NULL in > schema_init.c and other schema files, the openLDAP should not force the > validation and give this error message, as all these attributes in which > validation are not defined becomes unusable . > > In Tivoli/Sun and Microsoft Active directory LDAP validation is not enforced > where validation is defined as NULL hence I am not getting these kind of > error in Tivoli/Sun and Microsoft Active directory for editing of this > attribute . > > So any idea how to resolve this ? there is any way to modify any of the > config file in openldap to disable this validation for protocol information > ? > do I have to raise bug request for the same and is this going to be fixed in > next openLDAP release. ? > > Any help and suggestions in this direction is highly appreciated. I personally believe the absence of a validator for those syntaxes is the safest thing OpenLDAP can do to prevent further interoperability issues. The workaround illustrated above should allow you to circumvent your problem without too much harm. Of course, that's my personal opinion, which might differ from that of the OpenLDAP project. 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 ----------------------------------- --===============5411871414421953081==-- From ando@sys-net.it Mon Sep 29 19:53:48 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: ITS#5717 Date: Mon, 29 Sep 2008 19:53:48 +0000 Message-ID: <200809291953.m8TJrm5T010409@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7006943459601153121==" --===============7006943459601153121== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Fixed in HEAD; test044 updated as well. Please test. 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 ----------------------------------- --===============7006943459601153121==-- From quanah@OpenLDAP.org Tue Sep 30 02:52:30 2008 From: quanah@OpenLDAP.org To: openldap-bugs@openldap.org Subject: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 02:52:30 +0000 Message-ID: <200809300252.m8U2qUOf035912@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0350021488599630823==" --===============0350021488599630823== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Quanah Gibson-Mount Version: 2.3, 2.4, HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.207.132.222) The definition for ldap_utf8_strchr is: utf-8.c:char * (ldap_utf8_strchr)( const char *str, const char *chr ) I.e., string, character, as normal libc functions. However, at line 125 in charray.c, it is called as: if ( ldap_utf8_strchr( brkstr, s ) != NULL ) { This order appears to be incorrect. --Quanah --===============0350021488599630823==-- From quanah@OpenLDAP.org Tue Sep 30 02:54:23 2008 From: quanah@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 02:54:22 +0000 Message-ID: <200809300254.m8U2sMEM036603@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6418847499232341940==" --===============6418847499232341940== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Err, line 195. --Quanah --On September 30, 2008 2:52:30 AM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3, 2.4, HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.207.132.222) > > > The definition for ldap_utf8_strchr is: > > utf-8.c:char * (ldap_utf8_strchr)( const char *str, const char *chr ) > > I.e., string, character, as normal libc functions. > > However, at line 125 in charray.c, it is called as: > > if ( ldap_utf8_strchr( brkstr, s ) != NULL ) { > > This order appears to be incorrect. > > --Quanah > > --===============6418847499232341940==-- From h.b.furuseth@usit.uio.no Tue Sep 30 11:18:05 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 11:18:04 +0000 Message-ID: <200809301118.m8UBI4VT083438@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8850487586960248140==" --===============8850487586960248140== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit quanah(a)OpenLDAP.org writes: > utf-8.c:char * (ldap_utf8_strchr)( const char *str, const char *chr ) > > I.e., string, character, as normal libc functions. > > However, at line 125 in charray.c, it is called as: > if ( ldap_utf8_strchr( brkstr, s ) != NULL ) { > This order appears to be incorrect. No. That code counts the number of delimiters characters in the string being split. Since brkstr can contain several characters, the loop checks each "utf-8 character" in str against brkstr. -- Hallvard --===============8850487586960248140==-- From quanah@zimbra.com Tue Sep 30 16:01:36 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 16:01:35 +0000 Message-ID: <200809301601.m8UG1ZnN010233@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5513629168986180959==" --===============5513629168986180959== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On September 30, 2008 11:18:04 AM +0000 h.b.furuseth(a)usit.uio.no wrote: > quanah(a)OpenLDAP.org writes: >> utf-8.c:char * (ldap_utf8_strchr)( const char *str, const char *chr ) >> >> I.e., string, character, as normal libc functions. >> >> However, at line 125 in charray.c, it is called as: >> if ( ldap_utf8_strchr( brkstr, s ) != NULL ) { >> This order appears to be incorrect. > > No. That code counts the number of delimiters characters in the > string being split. Since brkstr can contain several characters, > the loop checks each "utf-8 character" in str against brkstr. Yes. The calling order was incorrect. It is supposed to be ldap_utf8_strchr(s, brkstr). Also the outside loop was incorrect. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============5513629168986180959==-- From quanah@zimbra.com Tue Sep 30 18:13:06 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: ITS#5707 [Fwd: Re: 4.7.25 deadlock] Date: Tue, 30 Sep 2008 18:13:05 +0000 Message-ID: <200809301813.m8UID5JL018971@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1430004371738128521==" --===============1430004371738128521== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I think their patch is broken. I rebuilt BDB 4.7 with it, and now test008 fails on me: bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") => bdb_dn2id("cn=james a jones 4,ou=people,dc=example,dc=com") <= bdb_dn2id: get failed: DB_LOCK_NOTGRANTED: Lock not granted (-30993) bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") => bdb_dn2id("cn=james a jones 4,ou=people,dc=example,dc=com") <= bdb_dn2id: get failed: DB_LOCK_NOTGRANTED: Lock not granted (-30993) bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") => bdb_dn2id("cn=james a jones 4,ou=people,dc=example,dc=com") <= bdb_dn2id: get failed: DB_LOCK_NOTGRANTED: Lock not granted (-30993) bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") => bdb_dn2id("cn=james a jones 4,ou=people,dc=example,dc=com") <= bdb_dn2id: get failed: DB_LOCK_NOTGRANTED: Lock not granted (-30993) bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") => bdb_dn2id("cn=james a jones 4,ou=people,dc=example,dc=com") <= bdb_dn2id: get failed: DB_LOCK_NOTGRANTED: Lock not granted (-30993) bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") => bdb_dn2id("cn=james a jones 4,ou=people,dc=example,dc=com") --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 >> >> 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 > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============1430004371738128521==-- From h.b.furuseth@usit.uio.no Tue Sep 30 18:20:59 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 18:20:58 +0000 Message-ID: <200809301820.m8UIKwQ9020084@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0438628907256273627==" --===============0438628907256273627== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit quanah(a)zimbra.com writes: > Yes. The calling order was incorrect. It is supposed to be > ldap_utf8_strchr(s, brkstr). No. Try this with the new code: env LDAPHOST='host1 host2' valgrind clients/tools/ldapwhoami -x It returns writes past malloced areas in ldap_str2charray(). options.c calls ldap_charray("host1 host2", ", ") to parse that. It counted the number of commas and spaces in the host string. With the new code, it instead sums up: number of commas in "host1 host2" + number of commas in "ost1 host2" + number of commas in "st1 host2" etc and you never count spaces. > Also the outside loop was incorrect. True. -- Hallvard --===============0438628907256273627==-- From quanah@zimbra.com Tue Sep 30 18:23:08 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: ITS#5707 [Fwd: Re: 4.7.25 deadlock] Date: Tue, 30 Sep 2008 18:23:07 +0000 Message-ID: <200809301823.m8UIN78j020801@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3664777905756696232==" --===============3664777905756696232== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On September 30, 2008 6:13:05 PM +0000 quanah(a)zimbra.com wrote: > I think their patch is broken. I rebuilt BDB 4.7 with it, and now > test008 fails on me: Never mind, test008 fails without the patch to BDB 4.7 as well, so it's not related. test008 simply no longer works for me with current RE24. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3664777905756696232==-- From quanah@zimbra.com Tue Sep 30 18:32:07 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 18:32:06 +0000 Message-ID: <200809301832.m8UIW6Cg021932@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3850624924506083011==" --===============3850624924506083011== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On September 30, 2008 6:20:58 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> Yes. The calling order was incorrect. It is supposed to be >> ldap_utf8_strchr(s, brkstr). > > No. Try this with the new code: > env LDAPHOST='host1 host2' valgrind clients/tools/ldapwhoami -x > It returns writes past malloced areas in ldap_str2charray(). > > options.c calls ldap_charray("host1 host2", ", ") to parse that. > It counted the number of commas and spaces in the host string. > With the new code, it instead sums up: > > number of commas in "host1 host2" > + number of commas in "ost1 host2" > + number of commas in "st1 host2" > > etc and you never count spaces. So, the solution is to revert the order of the call, but leave the loop the way it is now? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3850624924506083011==-- From tamburo@studenti.unina.it Tue Sep 30 19:17:35 2008 From: tamburo@studenti.unina.it To: openldap-bugs@openldap.org Subject: ITS#5695 Date: Tue, 30 Sep 2008 19:17:34 +0000 Message-ID: <200809301917.m8UJHYMZ025169@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0252878111017074637==" --===============0252878111017074637== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is the rights statement for my patch. This is the link http://www.studenti.unina.it/~tamburo/tesi/openldap/Luca-Tamburo-AC-08-09-11.= tgz to my patch with the following rights statement. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Luca Tamburo at ICAR, Branch of Naples, Italy. Luca Tamburo has not assigned rights and/or interest in this work to any party. I, Luca Tamburo am authoriz= ed by Giovanni Schmid, project manager at ICAR, my employer, to release this work under the following terms. Copyright 2008 Luca Tamburo tamburo(a)studenti.unina.it Redistribution and use in source and binary forms, with or without modificati= on, are permitted only as authorized by the OpenLDAP Public License. Regards, Luca ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. --===============0252878111017074637==-- From h.b.furuseth@usit.uio.no Tue Sep 30 19:29:16 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 19:29:15 +0000 Message-ID: <200809301929.m8UJTFLn026486@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5547711360166380419==" --===============5547711360166380419== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Duh, perhaps I should have paid attention to the committed patch instead of your description of the problem... The patch breaks in a different way than I said. Replace ldap_utf8_strchr with ldap_utf8_strpbrk and it should work. I probably can't test it today. -- Hallvard --===============5547711360166380419==-- From hyc@symas.com Tue Sep 30 19:38:00 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 19:37:59 +0000 Message-ID: <200809301937.m8UJbxHi027563@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7366483488444298046==" --===============7366483488444298046== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no wrote: > quanah(a)OpenLDAP.org writes: >> utf-8.c:char * (ldap_utf8_strchr)( const char *str, const char *chr ) >> >> I.e., string, character, as normal libc functions. >> >> However, at line 125 in charray.c, it is called as: >> if ( ldap_utf8_strchr( brkstr, s ) != NULL ) { >> This order appears to be incorrect. > No. That code counts the number of delimiters characters in the > string being split. Since brkstr can contain several characters, > the loop checks each "utf-8 character" in str against brkstr. The code was certainly broken, regardless. If the input string uses any UTF8 characters beyond 0x7f then the simple increment of "s++" would yield invalid characters for most of the iterations of the loop. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7366483488444298046==-- From h.b.furuseth@usit.uio.no Tue Sep 30 19:39:54 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5720) ldap_str2charray calls ldap_utf8_strchr incorrectly Date: Tue, 30 Sep 2008 19:39:54 +0000 Message-ID: <200809301939.m8UJdsLp028253@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3784304772347474819==" --===============3784304772347474819== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no writes: > Replace ldap_utf8_strchr with ldap_utf8_strpbrk and it should work. ..and come to think of, it, the *s non-null test in the for loop should be unnecessary. -- Hallvard --===============3784304772347474819==-- From ghenry@OpenLDAP.org Tue Sep 30 19:42:59 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: ITS#5713 Date: Tue, 30 Sep 2008 19:42:58 +0000 Message-ID: <200809301942.m8UJgwF7029092@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4961687582532846898==" --===============4961687582532846898== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ----- ando(a)sys-net.it wrote: > Probably, the right fix consists in changing that attr's syntax to=20 > DirectoryString, and allow all syntaxes, from "--w-------" to passing >=20 > the value to strtol(value, NULL, 0) etc. Shall we mention the new syntax support in that section of the guide? I'll th= e man page too. --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============4961687582532846898==-- From ando@sys-net.it Tue Sep 30 19:44:31 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: ITS#5713 Date: Tue, 30 Sep 2008 19:44:30 +0000 Message-ID: <200809301944.m8UJiUnZ029778@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3544013656978615191==" --===============3544013656978615191== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Gavin Henry wrote: > ----- ando(a)sys-net.it wrote: >=20 >> Probably, the right fix consists in changing that attr's syntax to=20 >> DirectoryString, and allow all syntaxes, from "--w-------" to passing >> >> the value to strtol(value, NULL, 0) etc. >=20 > Shall we mention the new syntax support in that section of the guide? I'll = the man page too. Well, probably yes. Thanks, 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 ----------------------------------- --===============3544013656978615191==--