openldap-bugs October 2008

openldap-bugs@openldap.org

36 participants
187 discussions

Re: (ITS#5709) slapd sync provider skips some objects
by hyc＠symas.com 31 Oct '08

31 Oct '08

sylvain.thomas(a)gmail.com wrote: > On 10/30/08, Gavin Henry<ghenry(a)openldap.org> wrote: >> Can you upload these zip attachments to our ftp server or somewhere else >> with online >> access please. Then we can test. >> > > I have uploaded the two files to your ftp server (incoming folder). I can confirm that the problem is easily reproducable. Adding a debug message here diff -u -r1.248 syncprov.c --- syncprov.c 17 Oct 2008 15:40:49 -0000 1.248 +++ syncprov.c 31 Oct 2008 21:06:56 -0000 @@ -1638,6 +1638,7 @@ si->si_sids[i] = sid; } } else { + Debug( LDAP_DEBUG_SYNC, "Empty maxcsn for %s\n", op->o_req_dn.bv_val, 0, 0 ); /* internal ops that aren't meant to be replicated */ ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock ); return SLAP_CB_CONTINUE; shows that some of the missing entries are caused by this situation, but not necessarily all. Still investigating. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5781) syncrepl doing delete/add on items without equality
by rubin＠physics.umn.edu 31 Oct '08

31 Oct '08

Patched in servers/slapd/syncrepl.c rev 1.418 http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/syncrepl.c.diff?r1=1… I applied the patch to 2.4.11 and verified it does solve the problem. Thanks!

1 0

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

31 Oct '08

On 10/30/08, Gavin Henry <ghenry(a)openldap.org> wrote: > Can you upload these zip attachments to our ftp server or somewhere else > with online > access please. Then we can test. > >> I have uploaded the two files to your ftp server (incoming folder). Best regards Sylvain Thomas

1 0

(ITS#5783) Possible DB corruption
by moya＠latertulia.org 31 Oct '08

31 Oct '08

Full_Name: Maykel Moya Version: 2.4.11 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.55.135.211) It's second time that I have bitten by this: Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. After that I'm unable to bind against the DSA. The problem has arise in two independent systems. Steps to reproduce: 1. Create a minor db (like Debian does), a dc=foo,dc=org node and a cn=admin,rootdn node 2. Migrate to cn=config 3. Edit cn=config I've added olcTLSCACertificateFile / olcTLSCertificateFile / olcTLSCertificateKeyFiel attributes 4. Restart the server After restarting I see the PROXIED error. I'd wrote to the list before [1][2] but the same thing has come in another system. Regards, maykel [1] http://www.openldap.org/lists/openldap-software/200808/msg00170.html [2] http://www.openldap.org/lists/openldap-software/200808/msg00170.html

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 31 Oct '08

31 Oct '08

------=_Part_29321_8395269.1225438991374 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline it would appear attribute lists containing * (all not operational attributes) and + (all operational attributes), are being dropped by "rwm-map attribute *" or they are not being expanded to attributes first, for whatever reason. the ldapsearch <blah blah> "(objectclass=*)" cn * + works without "rwm-map attrubute *", but stops working with "rwm-map attribute *" put back also, if you explicitly request attributes, you will get them, with our without "rwm-map attribute *" ie: ldapsearch <blah blah> "(objectclass=*)" cn sn entryUUID returns attrubutes which are allowed, but not showing via * and/or + ------=_Part_29321_8395269.1225438991374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline it would appear attribute lists containing * (all not operational attributes) and + (all operational attributes), are being dropped by "rwm-map attribute *" or they are not being expanded to attributes first, for whatever reason. the ldapsearch <blah blah> "(objectclass=*)" cn * + works without "rwm-map attrubute *", but stops working with "rwm-map attribute *" put back also, if you explicitly request attributes, you will get them, with our without "rwm-map attribute *" ie: ldapsearch <blah blah> "(objectclass=*)" cn sn entryUUID returns attrubutes which are allowed, but not showing via * and/or + ------=_Part_29321_8395269.1225438991374--

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 31 Oct '08

31 Oct '08

------=_Part_28816_12585104.1225436998930 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline trying some different things with the last release. very interesting that rwm-map works with operational attributes, i can see hasSubordinates, subschemaSubentry, entryUUID but not the other non-operational attributes such as cn, sn, etc., do not show.. # these dont rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * # these work rwm-map attribute hasSubordinates * rwm-map attribute subschemaSubentry * rwm-map attribute entryUUID * # this enabled rwm-map attribute * On Tue, Oct 21, 2008 at 3:55 PM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > Not clear what the problem is, now. The above configuration seems to work > as intended as far as attribute mapping is concerned. The fact that > "rwm-map objectclass *" no longer kills the objectClass attribuet was fixed > some time ago (the fix is in 2.4.12). What kills the allowed objectClass > values is a bug in evaluating what values are preserved. If you don't put > any "rwm-map objectclass" rule, it works as expected. > > I'm fixing this other bug. > > ------=_Part_28816_12585104.1225436998930 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline trying some different things with the last release. very interesting that rwm-map works with operational attributes, i can see hasSubordinates, subschemaSubentry, entryUUID but not the other non-operational attributes such as cn, sn, etc., do not show.. # these dont<div class="Ih2E3d"> rwm-map attribute cn * rwm-map attribute sn * </div>rwm-map attribute givenName *<div class="Ih2E3d"> rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * </div># these work rwm-map attribute hasSubordinates * rwm-map attribute subschemaSubentry * rwm-map attribute entryUUID * # this enabled rwm-map attribute * <div class="gmail_quote">On Tue, Oct 21, 2008 at 3:55 PM, Pierangelo Masarati <<a href="mailto:ando@sys-net.it">ando(a)sys-net.it</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Not clear what the problem is, now.  The above configuration seems to work as intended as far as attribute mapping is concerned.  The fact that "rwm-map objectclass *" no longer kills the objectClass attribuet was fixed some time ago (the fix is in 2.4.12).  What kills the allowed objectClass values is a bug in evaluating what values are preserved.  If you don't put any "rwm-map objectclass" rule, it works as expected. I'm fixing this other bug. </blockquote></div> ------=_Part_28816_12585104.1225436998930--

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 30 Oct '08

30 Oct '08

[please reply to the ITS] Brett @Google wrote: > trying some different things with the last release. > > very interesting that rwm-map works with operational attributes, i can see > hasSubordinates, subschemaSubentry, entryUUID but not the other > non-operational attributes. Odd. > > # these dont > rwm-map attribute cn * > rwm-map attribute sn * > rwm-map attribute givenName * > rwm-map attribute mail * > rwm-map attribute c * > rwm-map attribute o * > rwm-map attribute ou * > > # these work > rwm-map attribute hasSubordinates * > rwm-map attribute subschemaSubentry * > rwm-map attribute entryUUID * > > # this enabled > rwm-map attribute * Some operational attrs are generated and not stored in the entry (hasSubordinates, entryDN, subschemaSubentry, ...). As a consequence, they are not yet present in the entry when overlays see it during response. slapo-rwm(5), in the operational() hook, could muck with generated operational attrs. Currently, it remaps names, but does not consider removing disallowed attributes, AFAIR. I do not favor mucking too much with operational attrs, as they are... operational. I agree about the opportunity to rewrite the entryDN in order to support virtual views (what slapo-rwm(5) should actually do is replace any occurrence of entryDN in a SearchResultEntry with the entry's DN, if it differs), but probably we should disallow, for example, rewriting of creatorsName and modifiersName. If there is anywhing you want to hide to clients, you should rather use ACLs. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5778) slapd crashes while adding multipe attributes
by ando＠sys-net.it 30 Oct '08

30 Oct '08

snowyurik(a)gmail.com wrote: > ------=_Part_36644_12214634.1225420991107 > Content-Type: text/plain; charset=KOI8-R > Content-Transfer-Encoding: base64 > Content-Disposition: inline > > SSBoYXZlIGluc3RhbGxlZCB0aGUgbGF0ZXN0IHJlbGVhc2UgKG9wZW5sZGFwLTIuNC4xMiksIGlm > IGkgdXNlIGJzZC1tYWtlIGZvcgpidWlsZGluZyBvcGVubGRhcCwgc2xhcGQgc3RhcnRzIGJ1dCBn > b2VzIG5vdCBhbnN3ZXIgbm8gYW55dGhpbmcgKGV2ZW4ga2lsbCksCmluIGNhc2UgaSB1c2UgZ251 > LW1ha2UsIHNsYXBkIGRvZXMgbm90IHN0YXJ0IGF0IGFsbC4KCkluIGJvdGggc2l0dWF0aW9uLCBp > IGdldCBubyBlcnJvcnMuCgpNYXliZSBJIGRvIHNvbWV0aGluZyB3cm9uZywgYnV0IGkgc2hvdWxk > IGdldCBzb21lIGVycm9yIG1lc3NhZ2UgaW4gdGhpcwpjYXNlLCBpc24ndCBpdD8KMjAwOC8xMC8z > MCBQaWVyYW5nZWxvIE1hc2FyYXRpIDxhbmRvQHN5cy1uZXQuaXQ+Cgo+IODSycog78jPzsnOIHdy > b3RlOgo+Cj4+IFNvcnJ5Lgo+Pgo+PiBUaGlzIGlzIGJlY2F1c2Ugb2YgRnJlZUJTRCBwb3J0cyBj > b2xsZWN0aW9uLiBJJ2xsIHRyeSB0byBpbnN0YWxsIHRoZQo+PiBsYXRlc3QKPj4gcmVsZWFzZS4g > V2lsbCBpdCBiZSBjb3JyZWN0IGlmIGkgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGluIGEgd2Vlaywg > YW5kIHRlbGwKPj4gaWYgdGhlIHByb2JsZW0gZXhpc3Q/Cj4+Cj4KPiBBcyB5b3UgbGlrZS4gICBC > dXQgcGxlYXNlIHJlcGx5IHRvIDxvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnPiwgbm90IHRvIG15 > Cj4gcGVyc29uYWwgYWRkcmVzcy4KPgo+IHAuCj4KPgo+IEluZy4gUGllcmFuZ2VsbyBNYXNhcmF0 > aQo+IE9wZW5MREFQIENvcmUgVGVhbQo+Cj4gU3lzTmV0IHMuci5sLgo+IHZpYSBEb3NzaSwgOCAt > IDI3MTAwIFBhdmlhIC0gSVRBTElBCj4gaHR0cDovL3d3dy5zeXMtbmV0Lml0Cj4gLS0tLS0tLS0t > LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBPZmZpY2U6ICArMzkgMDIgMjM5OTgzMDkKPiBN > b2JpbGU6ICArMzkgMzMzIDQ5NjMxNzIKPiBGYXg6ICAgICArMzkgMDM4MiA0NzY0OTcKPiBFbWFp > bDogICBhbmRvQHN5cy1uZXQuaXQKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t > LQo+Cj4K > ------=_Part_36644_12214634.1225420991107 > Content-Type: text/html; charset=KOI8-R > Content-Transfer-Encoding: base64 > Content-Disposition: inline > > PHA+SSBoYXZlIGluc3RhbGxlZCB0aGUgbGF0ZXN0IHJlbGVhc2UgKG9wZW5sZGFwLTIuNC4xMiks > IGlmIGkgdXNlIGJzZC1tYWtlIGZvciBidWlsZGluZyBvcGVubGRhcCwgc2xhcGQgc3RhcnRzIGJ1 > dCBnb2VzIG5vdCBhbnN3ZXIgbm8gYW55dGhpbmcgKGV2ZW4ga2lsbCksIGluIGNhc2UgaSB1c2Ug > Z251LW1ha2UsIHNsYXBkIGRvZXMgbm90IHN0YXJ0IGF0IGFsbC48L3A+PHA+SW4gYm90aCBzaXR1 > YXRpb24sIGkgZ2V0IG5vIGVycm9ycy48L3A+Cgo8cD5NYXliZSBJIGRvIHNvbWV0aGluZyB3cm9u > ZywgYnV0IGkgc2hvdWxkIGdldCBzb21lIGVycm9yIG1lc3NhZ2UgaW4gdGhpcyBjYXNlLCBpc24m > IzM5O3QgaXQ/PC9wPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA4LzEwLzMwIFBpZXJhbmdl > bG8gTWFzYXJhdGkgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86YW5kb0BzeXMt > bmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+YW5kb0BzeXMtbmV0Lml0PC9hPiZndDs8L3NwYW4+PGJy > PgoKPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 > ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdj7g0snK > IO/Iz87JziB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 > Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm > dDoxZXgiPgpTb3JyeS48YnI+Cjxicj4KVGhpcyBpcyBiZWNhdXNlIG9mIEZyZWVCU0QgcG9ydHMg > Y29sbGVjdGlvbi4gSSYjMzk7bGwgdHJ5IHRvIGluc3RhbGwgdGhlIGxhdGVzdDxicj4KcmVsZWFz > ZS4gV2lsbCBpdCBiZSBjb3JyZWN0IGlmIGkgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGluIGEgd2Vl > aywgYW5kIHRlbGw8YnI+CmlmIHRoZSBwcm9ibGVtIGV4aXN0Pzxicj4KPC9ibG9ja3F1b3RlPgo8 > YnI+PC9kaXY+CkFzIHlvdSBsaWtlLiAmbmJzcDsgQnV0IHBsZWFzZSByZXBseSB0byAmbHQ7PGEg > aHJlZj0ibWFpbHRvOm9wZW5sZGFwLWl0c0BvcGVubGRhcC5vcmciIHRhcmdldD0iX2JsYW5rIj5v > cGVubGRhcC1pdHNAb3BlbmxkYXAub3JnPC9hPiZndDssIG5vdCB0byBteSBwZXJzb25hbCBhZGRy > ZXNzLjxkaXY+PGRpdj48YnI+Cjxicj4KcC48YnI+Cjxicj4KPGJyPgpJbmcuIFBpZXJhbmdlbG8g > TWFzYXJhdGk8YnI+Ck9wZW5MREFQIENvcmUgVGVhbTxicj4KPGJyPgpTeXNOZXQgcy5yLmwuPGJy > Pgp2aWEgRG9zc2ksIDggLSAyNzEwMCBQYXZpYSAtIElUQUxJQTxicj4KPGEgaHJlZj0iaHR0cDov > L3d3dy5zeXMtbmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5zeXMtbmV0Lml0PC9h > Pjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Ck9mZmljZTogJm5i > c3A7KzM5IDAyIDIzOTk4MzA5PGJyPgpNb2JpbGU6ICZuYnNwOyszOSAzMzMgNDk2MzE3Mjxicj4K > RmF4OiAmbmJzcDsgJm5ic3A7ICszOSAwMzgyIDQ3NjQ5Nzxicj4KRW1haWw6ICZuYnNwOyA8YSBo > cmVmPSJtYWlsdG86YW5kb0BzeXMtbmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+YW5kb0BzeXMtbmV0 > Lml0PC9hPjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Cjxicj4K > PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxwPjxicj48L3A+Cg== > ------=_Part_36644_12214634.1225420991107-- > > Please post plaintext messages; as you can see, the ITS doesn't like other formats. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5778) slapd crashes while adding multipe attributes
by snowyurik＠gmail.com 30 Oct '08

30 Oct '08

------=_Part_36644_12214634.1225420991107 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline SSBoYXZlIGluc3RhbGxlZCB0aGUgbGF0ZXN0IHJlbGVhc2UgKG9wZW5sZGFwLTIuNC4xMiksIGlm IGkgdXNlIGJzZC1tYWtlIGZvcgpidWlsZGluZyBvcGVubGRhcCwgc2xhcGQgc3RhcnRzIGJ1dCBn b2VzIG5vdCBhbnN3ZXIgbm8gYW55dGhpbmcgKGV2ZW4ga2lsbCksCmluIGNhc2UgaSB1c2UgZ251 LW1ha2UsIHNsYXBkIGRvZXMgbm90IHN0YXJ0IGF0IGFsbC4KCkluIGJvdGggc2l0dWF0aW9uLCBp IGdldCBubyBlcnJvcnMuCgpNYXliZSBJIGRvIHNvbWV0aGluZyB3cm9uZywgYnV0IGkgc2hvdWxk IGdldCBzb21lIGVycm9yIG1lc3NhZ2UgaW4gdGhpcwpjYXNlLCBpc24ndCBpdD8KMjAwOC8xMC8z MCBQaWVyYW5nZWxvIE1hc2FyYXRpIDxhbmRvQHN5cy1uZXQuaXQ+Cgo+IODSycog78jPzsnOIHdy b3RlOgo+Cj4+IFNvcnJ5Lgo+Pgo+PiBUaGlzIGlzIGJlY2F1c2Ugb2YgRnJlZUJTRCBwb3J0cyBj b2xsZWN0aW9uLiBJJ2xsIHRyeSB0byBpbnN0YWxsIHRoZQo+PiBsYXRlc3QKPj4gcmVsZWFzZS4g V2lsbCBpdCBiZSBjb3JyZWN0IGlmIGkgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGluIGEgd2Vlaywg YW5kIHRlbGwKPj4gaWYgdGhlIHByb2JsZW0gZXhpc3Q/Cj4+Cj4KPiBBcyB5b3UgbGlrZS4gICBC dXQgcGxlYXNlIHJlcGx5IHRvIDxvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnPiwgbm90IHRvIG15 Cj4gcGVyc29uYWwgYWRkcmVzcy4KPgo+IHAuCj4KPgo+IEluZy4gUGllcmFuZ2VsbyBNYXNhcmF0 aQo+IE9wZW5MREFQIENvcmUgVGVhbQo+Cj4gU3lzTmV0IHMuci5sLgo+IHZpYSBEb3NzaSwgOCAt IDI3MTAwIFBhdmlhIC0gSVRBTElBCj4gaHR0cDovL3d3dy5zeXMtbmV0Lml0Cj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBPZmZpY2U6ICArMzkgMDIgMjM5OTgzMDkKPiBN b2JpbGU6ICArMzkgMzMzIDQ5NjMxNzIKPiBGYXg6ICAgICArMzkgMDM4MiA0NzY0OTcKPiBFbWFp bDogICBhbmRvQHN5cy1uZXQuaXQKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+Cj4K ------=_Part_36644_12214634.1225420991107 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline PHA+SSBoYXZlIGluc3RhbGxlZCB0aGUgbGF0ZXN0IHJlbGVhc2UgKG9wZW5sZGFwLTIuNC4xMiks IGlmIGkgdXNlIGJzZC1tYWtlIGZvciBidWlsZGluZyBvcGVubGRhcCwgc2xhcGQgc3RhcnRzIGJ1 dCBnb2VzIG5vdCBhbnN3ZXIgbm8gYW55dGhpbmcgKGV2ZW4ga2lsbCksIGluIGNhc2UgaSB1c2Ug Z251LW1ha2UsIHNsYXBkIGRvZXMgbm90IHN0YXJ0IGF0IGFsbC48L3A+PHA+SW4gYm90aCBzaXR1 YXRpb24sIGkgZ2V0IG5vIGVycm9ycy48L3A+Cgo8cD5NYXliZSBJIGRvIHNvbWV0aGluZyB3cm9u ZywgYnV0IGkgc2hvdWxkIGdldCBzb21lIGVycm9yIG1lc3NhZ2UgaW4gdGhpcyBjYXNlLCBpc24m IzM5O3QgaXQ/PC9wPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA4LzEwLzMwIFBpZXJhbmdl bG8gTWFzYXJhdGkgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86YW5kb0BzeXMt bmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+YW5kb0BzeXMtbmV0Lml0PC9hPiZndDs8L3NwYW4+PGJy PgoKPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdj7g0snK IO/Iz87JziB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPgpTb3JyeS48YnI+Cjxicj4KVGhpcyBpcyBiZWNhdXNlIG9mIEZyZWVCU0QgcG9ydHMg Y29sbGVjdGlvbi4gSSYjMzk7bGwgdHJ5IHRvIGluc3RhbGwgdGhlIGxhdGVzdDxicj4KcmVsZWFz ZS4gV2lsbCBpdCBiZSBjb3JyZWN0IGlmIGkgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGluIGEgd2Vl aywgYW5kIHRlbGw8YnI+CmlmIHRoZSBwcm9ibGVtIGV4aXN0Pzxicj4KPC9ibG9ja3F1b3RlPgo8 YnI+PC9kaXY+CkFzIHlvdSBsaWtlLiAmbmJzcDsgQnV0IHBsZWFzZSByZXBseSB0byAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9wZW5sZGFwLWl0c0BvcGVubGRhcC5vcmciIHRhcmdldD0iX2JsYW5rIj5v cGVubGRhcC1pdHNAb3BlbmxkYXAub3JnPC9hPiZndDssIG5vdCB0byBteSBwZXJzb25hbCBhZGRy ZXNzLjxkaXY+PGRpdj48YnI+Cjxicj4KcC48YnI+Cjxicj4KPGJyPgpJbmcuIFBpZXJhbmdlbG8g TWFzYXJhdGk8YnI+Ck9wZW5MREFQIENvcmUgVGVhbTxicj4KPGJyPgpTeXNOZXQgcy5yLmwuPGJy Pgp2aWEgRG9zc2ksIDggLSAyNzEwMCBQYXZpYSAtIElUQUxJQTxicj4KPGEgaHJlZj0iaHR0cDov L3d3dy5zeXMtbmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5zeXMtbmV0Lml0PC9h Pjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Ck9mZmljZTogJm5i c3A7KzM5IDAyIDIzOTk4MzA5PGJyPgpNb2JpbGU6ICZuYnNwOyszOSAzMzMgNDk2MzE3Mjxicj4K RmF4OiAmbmJzcDsgJm5ic3A7ICszOSAwMzgyIDQ3NjQ5Nzxicj4KRW1haWw6ICZuYnNwOyA8YSBo cmVmPSJtYWlsdG86YW5kb0BzeXMtbmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+YW5kb0BzeXMtbmV0 Lml0PC9hPjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Cjxicj4K PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxwPjxicj48L3A+Cg== ------=_Part_36644_12214634.1225420991107--

1 0

Re: (ITS#5764) addpartial patch
by hyc＠symas.com 30 Oct '08

30 Oct '08

dhawes(a)vt.edu wrote: > Pierangelo Masarati wrote: >> dhawes(a)vt.edu wrote: >>> Full_Name: David Hawes >>> Version: 2.4.12 >>> OS: URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch >>> Submission from: (NULL) (128.173.38.164) >>> >>> >>> This patch includes the following changes: >>> >>> - -fPIC added to the Makefile for compilation on x86_64 systems. >>> - No longer use be_search() to retrieve the entry that is to be >>> compared. Use >>> be_entry_get_rw() instead. >> You should probably use overlay_entry_get_ov() rather than >> be_entry_get_rw() from inside an overlay (AFAIR). > > Okay, I'll make that change, thanks. > > I notice that most overlays seem to use be_entry_get_rw(), and one > (translucent) uses both. What is the reasoning to use one over the other? Most of those overlays were written before overlay_entry_get_ov() was written. It's just a convenience function so you don't have to juggle bd_info pointers all the time. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2008