Re: (ITS#5709) slapd sync provider skips some objects
by hyc＠symas.com
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/
15 years, 1 month
Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com
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
15 years, 1 month
Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com
------=_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.<br>
<br>the ldapsearch <blah blah> "(objectclass=*)" cn * +<br><br>works without "rwm-map attrubute *", but stops working with "rwm-map attribute *" put back<br><br>also, if you explicitly request attributes, you will get them, with our without "rwm-map attribute *" ie:<br>
<br>ldapsearch <blah blah> "(objectclass=*)" cn sn entryUUID<br><br>returns attrubutes which are allowed, but not showing via * and/or +<br><br>
------=_Part_29321_8395269.1225438991374--
15 years, 1 month
Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com
------=_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.<br><br>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,<br>etc., do not show..<br>
<br># these dont<div class="Ih2E3d"><br>rwm-map attribute cn *<br>rwm-map attribute sn *<br></div>rwm-map attribute givenName *<div class="Ih2E3d"><br>rwm-map attribute mail *<br>rwm-map attribute c *<br>rwm-map attribute o *<br>
rwm-map attribute ou *<br><br></div># these work<br>
rwm-map attribute hasSubordinates *<br>rwm-map attribute subschemaSubentry *<br>rwm-map attribute entryUUID *<br><br># this enabled<br>rwm-map attribute *<br><br><div class="gmail_quote">On Tue, Oct 21, 2008 at 3:55 PM, Pierangelo Masarati <span dir="ltr"><<a href="mailto:ando@sys-net.it">ando(a)sys-net.it</a>></span> wrote:<br>
<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.<br>
<br>
I'm fixing this other bug.<br>
<br></blockquote></div><br>
------=_Part_28816_12585104.1225436998930--
15 years, 1 month
Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it
[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
-----------------------------------
15 years, 1 month
Re: (ITS#5778) slapd crashes while adding multipe attributes
by ando＠sys-net.it
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
-----------------------------------
15 years, 1 month
Re: (ITS#5778) slapd crashes while adding multipe attributes
by snowyurik＠gmail.com
------=_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--
15 years, 1 month
Re: (ITS#5764) addpartial patch
by hyc＠symas.com
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/
15 years, 1 month
