- openldap-bugs - openldap.org

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

Re: (ITS#5764) addpartial patch
by dhawes＠vt.edu 30 Oct '08

30 Oct '08

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?

1 0

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

30 Oct '08

Full_Name: Alex Schumann Version: 2.4.11 OS: freebsd 7.0-release-p3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.101.220.229) We are using nis.schema's nisNetgroupTriple to hold unix netgroups. When we make a change, we do so using the following code snipit: $mesg = $ldap_master->modify ( $dn, replace => [ 'nisNetgroupTriple' => \@{$groups{$g}} ] ); The master accepts this change, but all the syncrepl slaves immediately start failing: Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_search (0) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 cn=ng115,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=ng115,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_search (0) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 cn=ng116,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed Oct 29 11:54:28 lanark slapd[4187]: null_callback : error code 0x12 Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_modify (18) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_modify failed (18) Oct 29 11:54:28 lanark slapd[4187]: do_syncrepl: rid=001 retrying Error code 0x12 is LDAP_INAPPROPRIATE_MATCHING, which indicates that syncrepl tried to do a delete/add on a multivalued attribute witohout an equality matching rule. Reason being, the schema for nis defines nisNetgroupTriple without an EQUALITY. You can argue between openldap and sun if that is an error in the schema, but fact is syncrepl should not fail in this or similar cases. Proper behavior would be if there is no equality, syncrepl should fall back to a replace. many thanks to hyc on freenode #openldap for helping me to understand what was going on here. http://www.archivesat.com/OpenLDAP_bugs/thread1581049.htm indicates nisNetgroupTriple is improperly defined according to SUN, but is really an aside on this bug.

1 0

Re: (ITS#5764) addpartial patch
by ando＠sys-net.it 30 Oct '08

30 Oct '08

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). 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#5779) backsql_load_schema_map checks wrong schema column in db
by robb＠wtg.cw.com 30 Oct '08

30 Oct '08

Pierangelo Masarati wrote: > I have applied a blind fix to back-sql/schema-map.c; please apply the > patch between r1.67 & r1.68 and report (presented below as a reference). > > p. > > diff -u -r1.67 schema-map.c > --- servers/slapd/back-sql/schema-map.c 21 Aug 2008 20:07:29 -0000 > 1.67 > +++ servers/slapd/back-sql/schema-map.c 30 Oct 2008 13:02:24 -0000 applied the fix and issue is resolved. Many thanks (and man that was fast :) Rob

1 0

Re: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)
by hyc＠symas.com 30 Oct '08

30 Oct '08

emmanuel.duru(a)atosorigin.com wrote: > It works fine with MoveFileEx. Thanks for the confirmation. We'll release this in 2.4.13... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5780) "manageDIT" is still used instead of "relax" here and there
by ando＠sys-net.it 30 Oct '08

30 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando s/manageDIT/relax/

1 0

Re: (ITS#5779) backsql_load_schema_map checks wrong schema column in db
by ando＠sys-net.it 30 Oct '08

30 Oct '08

robb(a)wtg.cw.com wrote: > Full_Name: Robert Brooks > Version: 2.4.12 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.28.17.64) > > > start-up of slapd reports > > "backsql_load_schema_map(): required column #6 "expect_return" is empty" > > however the value of ldap_oc_mappings.create_proc is actually being checked, > this can be confirmed by changing create_proc value in database from empty value > to non-empty. > > problem seems to be around line 567 of schema-map.c > > " { delete_proc_idx + 1, "expect_return" }," > > 6 seems correct value, but actual result is not correct I have applied a blind fix to back-sql/schema-map.c; please apply the patch between r1.67 & r1.68 and report (presented below as a reference). p. diff -u -r1.67 schema-map.c --- servers/slapd/back-sql/schema-map.c 21 Aug 2008 20:07:29 -0000 1.67 +++ servers/slapd/back-sql/schema-map.c 30 Oct 2008 13:02:24 -0000 @@ -570,7 +570,7 @@ int i; for ( i = 0; required[ i ].name != NULL; i++ ) { - if ( oc_row.value_len[ i ] <= 0 ) { + if ( oc_row.value_len[ required[ i ].idx ] <= 0 ) { Debug( LDAP_DEBUG_ANY, "backsql_load_schema_map(): " "required column #%d \"%s\" is empty\n", 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#5759) whitespace vs white space
by ghenry＠OpenLDAP.org 30 Oct '08

30 Oct '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I noticed that the term "whitespace" and "white space" are used inconsistently > throughout the documentation. Can we please pick one? ;) > > --Quanah > > whitespace it is. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

RE: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)
by emmanuel.duru＠atosorigin.com 30 Oct '08

30 Oct '08

It works fine with MoveFileEx.

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by ghenry＠OpenLDAP.org 30 Oct '08

30 Oct '08

Can you upload these zip attachments to our ftp server or somewhere else with online access please. Then we can test. > > ------=_Part_18730_5320025.1224681987183 > Content-Type: application/zip; name=test018-parallel-import.zip > Content-Transfer-Encoding: base64 > X-Attachment-Id: file0 > Content-Disposition: attachment; filename=test018-parallel-import.zip -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5779) backsql_load_schema_map checks wrong schema column in db
by robb＠wtg.cw.com 30 Oct '08

30 Oct '08

Full_Name: Robert Brooks Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.28.17.64) start-up of slapd reports "backsql_load_schema_map(): required column #6 "expect_return" is empty" however the value of ldap_oc_mappings.create_proc is actually being checked, this can be confirmed by changing create_proc value in database from empty value to non-empty. problem seems to be around line 567 of schema-map.c " { delete_proc_idx + 1, "expect_return" }," 6 seems correct value, but actual result is not correct

1 0

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

29 Oct '08

yoreck(a)rambler.ru wrote: > Full_Name: Yuriy V. Ohonin > Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49) Is there any special reason you're using a release that is more than 2 years old? Can you reproduce the issue with the latest release? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5778) slapd crashes while adding multipe attributes
by yoreck＠rambler.ru 29 Oct '08

29 Oct '08

Full_Name: Yuriy V. Ohonin Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49) OS: FreeBSD 6.2-RELEASE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.65.16.93) slapd daemon crashes complitely in such a situation: I create my own class in shema objectclass ( Tasks:Chain:Element NAME ('x-tch-e' 'x-Task-Chain-Element') MUST ( cn ) MAY ( x-tch-nxt $ x-tch-sp $ x-tch-ep ) DESC 'Container of pointers, next and previos' ) and an attribute wich should have multiple values attributetype ( Tasks:Attr:3 NAME ('x-tch-nxt' 'x-Task-Chain-Next') EQUALITY distinguishedNameMatch DESC 'Point to next chain element' SYNTAX distinguishedName ) Slapd starts sussesfully. It is possible add first x-tch-nxt attribute to an entry, but if i try to add next one (usind ldapbrowser, or ldap_mod_add php function) slapd stops (i have no such process any more) this is what syslog say: Oct 30 12:11:45 yurik kernel: pid 13227 (slapd), uid 389: exited on signal 6

1 0

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by michael＠stroeder.com 29 Oct '08

29 Oct '08

Kurt Zeilenga wrote: > > On Oct 29, 2008, at 2:56 AM, michael(a)stroeder.com wrote: > >> I wonder whether it would be worth that slapd rejects a SASL bind >> request with >> BindRequest.name set (normally used for simple bind) returning a >> protocolError >> error code. > > RFC 4513: > Clients sending a BindRequest message with the sasl choice selected > SHOULD send a zero-length value in the name field. Servers receiving > a BindRequest message with the sasl choice selected SHALL ignore any > value in the name field. > > So, no. Ok. My intention was that if 'name' field and SASL authc-ID leads to different identity mapping it could confuse admins seeing 'name' in the BindRequest but a different authz-ID being in effect. Anyway no strong need, just an idea. Ciao, Michael.

1 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by hyc＠symas.com 29 Oct '08

29 Oct '08

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.12 > OS: > URL: > Submission from: (NULL) (193.55.250.67) > > > [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr > ... > bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run > database recovery > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run > recovery > bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed: > DB_RUNRECOVERY: Fatal error, run database recovery (-30975) > [root@etoile ~]# echo $? > 0 > > It makes a bit difficult to know if slapcat-based backup were successful. How did you create this situation? I can't test a fix without some way to break the DB in the first place, and generally the DB doesn't fail... -- -- 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#5763) libRSAglue bug in OpenLDAP configure script
by hyc＠symas.com 29 Oct '08

29 Oct '08

epj(a)newpointtech.com wrote: > Full_Name: Eric Johanson > Version: 2.4.12 > OS: Debian Linux 4.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.80.228.78) > > > The "configure" script has a bug when TLS is enabled, which causes it to fail > when using recent versions of OpenSSL. The bug is found on line 18759 of the > "configure" script in OpenLDAP 2.4.12. The line currently reads: > > LIBS="-lssl -lcrypto -lRSAglue -lrsaref $LIBS" > > But the -lRSAglue and -lrsaref are old OpenSSL libraries that are not in use any > more. I modified the above line to read: > > LIBS="-lssl -lcrypto $LIBS" > > This solves the problem. However, perhaps someone wants to add logic to detect > which version of OpenSSL is being used and then vary the LIBS variable > accordingly when the configure script tests for the linkability of the > ssl3_accept() function. > > Note that many Linux systems, even those that have a recent OpenSSL, may still > have the -lRSAglue and -lrsaref libraries (just for compatibility reasons). To > reproduce this bug, you will have to search your system and remove all files > with the names libRSAglue.a and librsaref.a. The configure script only checks for -lRSAglue after it has already failed to link without it. As such, there's something wrong on your machine for it to even be reaching that test. There is no OpenLDAP bug here. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs