openldap-bugs April 2008

openldap-bugs@openldap.org

45 participants
192 discussions

Re: (ITS#5476) delta-syncrepl docs from Symas
by csquires＠mun.ca 21 Apr '08

21 Apr '08

More docs. Great! I notice, however, that in the config for the replica there is a difference between this and the directives used in the tests: http://www.openldap.org/devel/cvsweb.cgi/tests/data/slapd-deltasync- slave.conf?hideattic=1&sortbydate=0 There, the directive "overlay syncprov" is also included. Is the latter necessary? Cheers, Craig On Mon, 2008-04-21 at 07:34 +0000, ghenry(a)openldap.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Marty and Matthew from Symas have given permission to use how we see fit: > > http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 > > This is a ticket to track commits for the delta-sycnrepl sections. > >

1 0

(ITS#5479) Pasword Policy docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Marty and Matthew from Symas have given permission to use how we see fit: http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 This is a ticket to track commits for the Password Policy Overlay section.

1 0

(ITS#5478) Can not compile ldap_t61s_to_utf8s function from LDAP library
by emmanuel.duru＠atosorigin.com 21 Apr '08

21 Apr '08

Full_Name: Emmanuel Duru Version: 2.3.38 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) Using OpenLDAP LDAP library to perform conversions between X.500 directory data and LDAP directory data, I need to convert values from T.61 to UTF-8. I see that there is a t61.c file in LDAP library with a ldap_t61s_to_utf8s() function to perform this. The problem is that t61.c does not compile because it refers to ldap_x_wc_to_utf8() and ldap_x_utf8_to_wc() which are defined in utf-8-conv.c file only in case sizeof(wchar_t) >= 4, which is not the case with windows where sizeof(wchar_t) = 2.

1 0

(ITS#5477) Pasword Policy docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

1 0

(ITS#5476) delta-syncrepl docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Marty and Matthew from Symas have given permission to use how we see fit: http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 This is a ticket to track commits for the delta-sycnrepl sections.

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by pere＠hungry.com 20 Apr '08

20 Apr '08

Just a quick reply for future reference if others ask about the same and find this request. [Kurt Zeilenga] > No. Attribute description options cannot contain equal signs. See > RFC 4512. Thank you for your reply. It was very valuable for me that is not as well lectured in the LDAP specification. It is now obvious to me that the extention used by Active Directory LDAP is outside the RFC-documented LDAP specification. I've been told that AD range feature is documented in an expired draft RFC, available from <URL: http://www.tkk.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt >. I'm not sure what was discussed about this draft, but it expired a long time ago. Anyway, the draft can be used to understand how the feature is working. It claim that it is possible to see in supportedControls if this range feature is used by the server. This could be used to enable this feature at runtime, if one wanted to implement the non-conforming feature. I suspect I have to go in that direction, as the project requirements are to use LDAP from AD. :/ > If you want to implement this crap, you can do so without additional > support from LDAP API. Use ldap_first/next_attribute API. Good idea. I have since found out that this ranged multivalue feature is implemented in nss-ldap, and hope it is possible to reuse some code there in nss-ldapd. Happy hacking, -- Petter Reinholdtsen

1 0

Re: (ITS#5475) Enhance ldapdelete to delete with a filter
by h.b.furuseth＠usit.uio.no 20 Apr '08

20 Apr '08

ando(a)sys-net.it writes: > Although I don't see any particular issue in implementing this > enhancement, ldap* tools are essentially intended to implement the basic > LDAP features at the operation level. True, ldapdelete -r is a bit of an aberration in that regard. > You can easily obtain what you're asking for by using > > ldapsearch <search options> | grep ^dn: | ldapdelete <delete options> No. Must also join continuation lines first, check for non-success result from search, and sort the DNs so children precede parents. Excellent example of how quickly LDAP shell scripting become more cumbersome than using a proper LDAP API:-) Come to think of it, an ldapdelete option to reverse-sort the DNs by number of RDNs would be useful. This would satisfy child-before-parent. -- Hallvard

1 0

Re: (ITS#5475) Enhance ldapdelete to delete with a filter
by serenityzhu＠gmail.com 20 Apr '08

20 Apr '08

------=_Part_10709_1485377.1208682014107 Content-Type: text/plain; charset=BIG5 Content-Transfer-Encoding: base64 Content-Disposition: inline RGVhciBQaWVyYW5nZWxvLAoKVGhhbmsgeW91LiBJIGFncmVlIHdpdGggeW91IHRoYXQgaXQgaXMg bm90IGNyaXRpY2FsLCB3ZSBjYW4gdXNlIGxkYXBzZWFyY2gncwpmaWx0ZXIgdG8gYWN0IGFzIGxk YXBkZWxldGUncyBmaWx0ZXIuCgpBZnRlciB5b3VyIGV4cGxhbmF0aW9uLCBpdCBtaWdodCBub3Qg YmUgYSBnb29kIGlkZWEgdG8gaW1wbGVtZW50IHRoZSBmaWx0ZXIKaW4gbGRhcGRlbGV0ZSwgYmVj YXVzZSBpZiBzbywgdGhlIGZpbHRlciBmdW5jdGlvbmFsaXR5IGlzIGR1cGxpY2F0ZSwgaW4gYm90 aApsZGFwc2VhcmNoIGFuZCBsZGFwZGVsZXRlLiBXZSBoYXZlIHRvIG1haW50YWluIHR3byBjb3Bp ZXMgb2YgdGhlIGZpbHRlcgpjb2RlLgoKRnVydGhlciBkaXNjdXNzaW9uIGlzIHdlbGNvbWUhCgpC ZXN0IHJlZ2FyZHMsCkphY2t5CgpPbiBTdW4sIEFwciAyMCwgMjAwOCBhdCAzOjQ2IFBNLCBQaWVy YW5nZWxvIE1hc2FyYXRpIDxhbmRvQHN5cy1uZXQuaXQ+Cndyb3RlOgoKPgo+ID4gSSBmaW5kIHRo YXQgbGRhcGRlbGV0ZSBjYW4gb25seSBkZWxldGUgYSBETiBvciBhIHN1YnRyZWUgb25lIHRpbWUu IElmIEkKPiA+IHdhbnQgdG8KPiA+IGRlbGV0ZSBhbGwgZW50cmllcyBmdWxmaWxsaW5nIGEgY2Vy dGFpbiBmaWx0ZXIuIEkgaGF2ZSB0byBnZXQgdGhlIEROcwo+ID4gZmlyc3QsIHB1dAo+ID4gdGhl bSBpbiBhIGZpbGUsIGFuZCB0aGVuIHVzZSBsZGFwZGVsZXRlIHRvIGRlbGV0ZSB0aGVtLgo+ID4K PiA+IENhbiB3ZSB1c2UgYSBmaWx0ZXIgaW4gbGRhcGRlbGV0ZSwganVzdCBhcyB0aGUgZmlsdGVy IGluIGxkYXBzZWFyY2g/Cj4KPiBBbHRob3VnaCBJIGRvbid0IHNlZSBhbnkgcGFydGljdWxhciBp c3N1ZSBpbiBpbXBsZW1lbnRpbmcgdGhpcwo+IGVuaGFuY2VtZW50LCBsZGFwKiB0b29scyBhcmUg ZXNzZW50aWFsbHkgaW50ZW5kZWQgdG8gaW1wbGVtZW50IHRoZSBiYXNpYwo+IExEQVAgZmVhdHVy ZXMgYXQgdGhlIG9wZXJhdGlvbiBsZXZlbC4gIFlvdSBjYW4gZWFzaWx5IG9idGFpbiB3aGF0IHlv dSdyZQo+IGFza2luZyBmb3IgYnkgdXNpbmcKPgo+IGxkYXBzZWFyY2ggPHNlYXJjaCBvcHRpb25z PiB8IGdyZXAgXmRuOiB8IGxkYXBkZWxldGUgPGRlbGV0ZSBvcHRpb25zPgo+Cj4gKHdoaWNoIGlz IHZlcnkgVU5JWC1zdHlsZSwgQlRXKS4KPgo+IEluIGFueSBjYXNlIHlvdSdkIG5lZWQgdG8gYWRk IGZ1cnRoZXIgbG9naWNzIHRvIGhhbmRsZSBhbnkgZGVsZXRlIGZhaWx1cmUsCj4gd2hpY2gsIGFj Y29yZGluZyB0byBMREFQIG1vZGVsLCBjYW5ub3QgYmUgdHJhbnNhY3Rpb25hbC4gIFNvIGFueQo+ IGNvbnRyaWJ1dGlvbiBpbiB0aGUgc2Vuc2Ugb2YgeW91ciBzdWdnZXN0aW9uIHdvdWxkIHByb2Jh Ymx5IGJlIHdlbGNvbWVkLAo+IGJ1dCBJIGhhcmRseSBzZWUgaXQgY3JpdGljYWwuCj4KPiBwLgo+ Cj4KPgo+IEluZy4gUGllcmFuZ2VsbyBNYXNhcmF0aQo+IE9wZW5MREFQIENvcmUgVGVhbQo+Cj4g U3lzTmV0IHMuci5sLgo+IHZpYSBEb3NzaSwgOCAtIDI3MTAwIFBhdmlhIC0gSVRBTElBCj4gaHR0 cDovL3d3dy5zeXMtbmV0Lml0Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCj4gT2ZmaWNlOiAgKzM5IDAyIDIzOTk4MzA5Cj4gTW9iaWxlOiAgKzM5IDMzMyA0OTYzMTcy Cj4gRW1haWw6ICAgcGllcmFuZ2Vsby5tYXNhcmF0aUBzeXMtbmV0Lml0Cj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPgo+CgoKLS0gClJvbWFucyAzOjIzIEZvciBh bGwgaGF2ZSBkb25lIHdyb25nIGFuZCBhcmUgZmFyIGZyb20gdGhlIGdsb3J5IG9mIEdvZDsKw7mw qK7RIDM6MjMgpl2ssKVApEizo6XHpEa4b6FBwauvyqRGr6uqurphxKOhQwpKb2huIDM6MTYgRm9y IEdvZCBzbyBsb3ZlZCB0aGUgd29ybGQsIHRoYXQgSGUgZ2F2ZSBIaXMgb25seSBiZWdvdHRlbiBT b24sCnRoYXQgd2hvZXZlciBiZWxpZXZlcyBpbiBIaW0gc2hhbGwgbm90IHBlcmlzaCwgYnV0IGhh dmUgZXRlcm5hbCBsaWZlLgqs+b+rutattTM6MTYgr6u3UqVApEihQqzGptyxTqVMqrq/V6XNpGy9 57W5pUytzKFCpXOkQKTBq0ilTKq6oUKko6bct8CkYKFCpM+xb6XDpc2hQwpodHRwOi8vd3d3Lmhr Y2NjLm9yZy9mbGFzaDIuaHRtCg== ------=_Part_10709_1485377.1208682014107 Content-Type: text/html; charset=BIG5 Content-Transfer-Encoding: base64 Content-Disposition: inline RGVhciBQaWVyYW5nZWxvLDxicj48YnI+VGhhbmsgeW91LiBJIGFncmVlIHdpdGggeW91IHRoYXQg aXQgaXMgbm90IGNyaXRpY2FsLCB3ZSBjYW4gdXNlIGxkYXBzZWFyY2gmIzM5O3MgZmlsdGVyIHRv IGFjdCBhcyBsZGFwZGVsZXRlJiMzOTtzIGZpbHRlci4gPGJyPjxicj5BZnRlciB5b3VyIGV4cGxh bmF0aW9uLCBpdCBtaWdodCBub3QgYmUgYSBnb29kIGlkZWEgdG8gaW1wbGVtZW50IHRoZSBmaWx0 ZXIgaW4gbGRhcGRlbGV0ZSwgYmVjYXVzZSBpZiBzbywgdGhlIGZpbHRlciBmdW5jdGlvbmFsaXR5 IGlzIGR1cGxpY2F0ZSwgaW4gYm90aCBsZGFwc2VhcmNoIGFuZCBsZGFwZGVsZXRlLiBXZSBoYXZl IHRvIG1haW50YWluIHR3byBjb3BpZXMgb2YgdGhlIGZpbHRlciBjb2RlLiA8YnI+Cjxicj5GdXJ0 aGVyIGRpc2N1c3Npb24gaXMgd2VsY29tZSE8YnI+PGJyPkJlc3QgcmVnYXJkcyw8YnI+SmFja3k8 YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBTdW4sIEFwciAyMCwgMjAwOCBhdCAz OjQ2IFBNLCBQaWVyYW5nZWxvIE1hc2FyYXRpICZsdDs8YSBocmVmPSJtYWlsdG86YW5kb0BzeXMt bmV0Lml0Ij5hbmRvQHN5cy1uZXQuaXQ8L2E+Jmd0OyB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwg MjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsi Pjxicj4KJmd0OyBJIGZpbmQgdGhhdCBsZGFwZGVsZXRlIGNhbiBvbmx5IGRlbGV0ZSBhIEROIG9y IGEgc3VidHJlZSBvbmUgdGltZS4gSWYgSTxicj4KJmd0OyB3YW50IHRvPGJyPgomZ3Q7IGRlbGV0 ZSBhbGwgZW50cmllcyBmdWxmaWxsaW5nIGEgY2VydGFpbiBmaWx0ZXIuIEkgaGF2ZSB0byBnZXQg dGhlIEROczxicj4KJmd0OyBmaXJzdCwgcHV0PGJyPgomZ3Q7IHRoZW0gaW4gYSBmaWxlLCBhbmQg dGhlbiB1c2UgbGRhcGRlbGV0ZSB0byBkZWxldGUgdGhlbS48YnI+CiZndDs8YnI+CiZndDsgQ2Fu IHdlIHVzZSBhIGZpbHRlciBpbiBsZGFwZGVsZXRlLCBqdXN0IGFzIHRoZSBmaWx0ZXIgaW4gbGRh cHNlYXJjaD88YnI+Cjxicj4KQWx0aG91Z2ggSSBkb24mIzM5O3Qgc2VlIGFueSBwYXJ0aWN1bGFy IGlzc3VlIGluIGltcGxlbWVudGluZyB0aGlzPGJyPgplbmhhbmNlbWVudCwgbGRhcCogdG9vbHMg YXJlIGVzc2VudGlhbGx5IGludGVuZGVkIHRvIGltcGxlbWVudCB0aGUgYmFzaWM8YnI+CkxEQVAg ZmVhdHVyZXMgYXQgdGhlIG9wZXJhdGlvbiBsZXZlbC4gJm5ic3A7WW91IGNhbiBlYXNpbHkgb2J0 YWluIHdoYXQgeW91JiMzOTtyZTxicj4KYXNraW5nIGZvciBieSB1c2luZzxicj4KPGJyPgpsZGFw c2VhcmNoICZsdDtzZWFyY2ggb3B0aW9ucyZndDsgfCBncmVwIF5kbjogfCBsZGFwZGVsZXRlICZs dDtkZWxldGUgb3B0aW9ucyZndDs8YnI+Cjxicj4KKHdoaWNoIGlzIHZlcnkgVU5JWC1zdHlsZSwg QlRXKS48YnI+Cjxicj4KSW4gYW55IGNhc2UgeW91JiMzOTtkIG5lZWQgdG8gYWRkIGZ1cnRoZXIg bG9naWNzIHRvIGhhbmRsZSBhbnkgZGVsZXRlIGZhaWx1cmUsPGJyPgp3aGljaCwgYWNjb3JkaW5n IHRvIExEQVAgbW9kZWwsIGNhbm5vdCBiZSB0cmFuc2FjdGlvbmFsLiAmbmJzcDtTbyBhbnk8YnI+ CmNvbnRyaWJ1dGlvbiBpbiB0aGUgc2Vuc2Ugb2YgeW91ciBzdWdnZXN0aW9uIHdvdWxkIHByb2Jh Ymx5IGJlIHdlbGNvbWVkLDxicj4KYnV0IEkgaGFyZGx5IHNlZSBpdCBjcml0aWNhbC48YnI+Cjxi cj4KcC48YnI+Cjxicj4KPGJyPgo8YnI+CkluZy4gUGllcmFuZ2VsbyBNYXNhcmF0aTxicj4KT3Bl bkxEQVAgQ29yZSBUZWFtPGJyPgo8YnI+ClN5c05ldCBzLnIubC48YnI+CnZpYSBEb3NzaSwgOCAt IDI3MTAwIFBhdmlhIC0gSVRBTElBPGJyPgo8YSBocmVmPSJodHRwOi8vd3d3LnN5cy1uZXQuaXQi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnN5cy1uZXQuaXQ8L2E+PGJyPgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Ck9mZmljZTogJm5ic3A7KzM5IDAyIDIz OTk4MzA5PGJyPgpNb2JpbGU6ICZuYnNwOyszOSAzMzMgNDk2MzE3Mjxicj4KRW1haWw6ICZuYnNw OyA8YSBocmVmPSJtYWlsdG86cGllcmFuZ2Vsby5tYXNhcmF0aUBzeXMtbmV0Lml0Ij5waWVyYW5n ZWxvLm1hc2FyYXRpQHN5cy1uZXQuaXQ8L2E+PGJyPgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+Cjxicj4KPGJyPgo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBj bGVhcj0iYWxsIj48YnI+LS0gPGJyPlJvbWFucyAzOjIzIEZvciBhbGwgaGF2ZSBkb25lIHdyb25n IGFuZCBhcmUgZmFyIGZyb20gdGhlIGdsb3J5IG9mIEdvZDs8YnI+w7mwqK7RIDM6MjMgpl2ssKVA pEizo6XHpEa4b6FBwauvyqRGr6uqurphxKOhQzxicj5Kb2huIDM6MTYgRm9yIEdvZCBzbyBsb3Zl ZCB0aGUgd29ybGQsIHRoYXQgSGUgZ2F2ZSBIaXMgb25seSBiZWdvdHRlbiBTb24sIHRoYXQgd2hv ZXZlciBiZWxpZXZlcyBpbiBIaW0gc2hhbGwgbm90IHBlcmlzaCwgYnV0IGhhdmUgZXRlcm5hbCBs aWZlLjxicj4KrPm/q7rWrbUzOjE2IK+rt1KlQKRIoUKsxqbcsU6lTKq6v1elzaRsvee1uaVMrcyh QqVzpECkwatIpUyquqFCpKOm3LfApGChQqTPsW+lw6XNoUM8YnI+PGEgaHJlZj0iaHR0cDovL3d3 dy5oa2NjYy5vcmcvZmxhc2gyLmh0bSI+aHR0cDovL3d3dy5oa2NjYy5vcmcvZmxhc2gyLmh0bTwv YT4K ------=_Part_10709_1485377.1208682014107--

1 0

Re: (ITS#5475) Enhance ldapdelete to delete with a filter
by ando＠sys-net.it 20 Apr '08

20 Apr '08

> I find that ldapdelete can only delete a DN or a subtree one time. If I > want to > delete all entries fulfilling a certain filter. I have to get the DNs > first, put > them in a file, and then use ldapdelete to delete them. > > Can we use a filter in ldapdelete, just as the filter in ldapsearch? Although I don't see any particular issue in implementing this enhancement, ldap* tools are essentially intended to implement the basic LDAP features at the operation level. You can easily obtain what you're asking for by using ldapsearch <search options> | grep ^dn: | ldapdelete <delete options> (which is very UNIX-style, BTW). In any case you'd need to add further logics to handle any delete failure, which, according to LDAP model, cannot be transactional. So any contribution in the sense of your suggestion would probably be welcomed, but I hardly see it critical. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5475) Enhance ldapdelete to delete with a filter
by serenityzhu＠gmail.com 19 Apr '08

19 Apr '08

Full_Name: Jacky Wu Version: 2.3 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (222.166.160.180) Dear all, I find that ldapdelete can only delete a DN or a subtree one time. If I want to delete all entries fulfilling a certain filter. I have to get the DNs first, put them in a file, and then use ldapdelete to delete them. Can we use a filter in ldapdelete, just as the filter in ldapsearch? Thank you. Best regards, Jacky

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2008