openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

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

Re: (ITS#5471) Object-Deletions (some) missing in syncrepl consumers
by m.d.t.evans＠qmul.ac.uk 18 Apr '08

18 Apr '08

On Wed, 2008-04-16 at 08:34 +0000, marian.eichholz(a)freenet.ag wrote: > Full_Name: Marian Eichholz > Version: HEAD-20080411 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.97.7.65) > > > When I made a consistency check with our two syncrepl consumers, I found several > irritating differences. > > After the initial refresh cycle, the DNs were complete. But when the consumers > got all new objects after, they now have objects that were deleted on the > provider in the meantime. Unfortunately I cannot tell when that happened to a > specific DN. > The set of undeleted objects is not identically on the two consumers. > So I guess that it is not a problem with the data itself. > > So the consumers are corrupted now. > > Both consumers suffer from hanging replication sessions. This is why we switched > from 2.4.8 to HEAD (11.4.2008, see ITS 5463). They were stopped and restarted > repeatedly, of course. The daemons have never been killed. So the DBD backend > SHOULD be OK. > > Any idea how to find such events in the LOCAL4-Log? I did not apply "any" as > loglevel for predictable performance issues and so liked to keep the entries to > a reasonable volume. > > Thank You very much for any idea. > > Yours sincerely - Marian Eichholz (freenet AG) > > Hi Marion. I saw both those problems with 2.4.8. But they both seem to have been fixed in the RE24 cvs tag as of 14/04/08. I have an arrangement of syncrepl servers based on that release that has been running fine for a few days now with about 10 connections per second on the consumers. Martin. -- -- Dr Martin Evans, Computing Services, Queen Mary

1 0

Re: (ITS#5469) Assertion failure causes slapd crash
by jwm＠horde.net 17 Apr '08

17 Apr '08

On Tue, Apr 15, 2008 at 01:20:58PM -0700, Howard Chu wrote: > Howard Chu wrote: > Please try the patch in slapd/connection.c 1.416 and report your results, > thanks. I patched our local slapd yesterday; I'll let you know in a couple of weeks, once we can be certain that slapd is no longer crashing. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#5474) Problem with schema validation in 2.4.8
by benoitde＠sympatico.ca 17 Apr '08

17 Apr '08

Hi, Thanks a lot guys! I tested the patch with both a dump of an LDIF and the JMSAdmin tool of IBM MQ, and confirm that now the problem is fixed. On Thu, Apr 17, 2008 at 06:59:10PM +0000, ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > > > The problem is that OpenLDAP 2.4 allows to add entries that contain > > ABSTRACT objectClasses, as soon as no non-ABSTRACT class is subtyped > > from them, which is clearly an error. > > > > It all reduces to a missing negation in the ABSTRACT subclassing check, > > resulting in reversing the logic of the test. > > > > Please test servers/slapd/schema_check.c 1.112 -> 1.113 > > I also note that 2.3 suffers from the reverse of the reported issue, > namely an abstract class is tolerated, even if no other class inherits > from 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 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- >

1 0

Re: (ITS#5408) back-ldif bugs
by h.b.furuseth＠usit.uio.no 17 Apr '08

17 Apr '08

On Thu, April 17, 2008 18:18, h.b.furuseth(a)usit.uio.no wrote: > On Thu, April 17, 2008 02:12, Howard Chu wrote: >> fails on test005 > > Did before too, I think. Probably canŽt test this week, sorry. Yes I could. And yes, ldif.c rev 1.81 failed the same way. > The full patch is... closer to allowing work on a full ./run -b ldif all. The one IŽve been working on but not committed the rest of yet, I mean. -- Hallvard

1 0

Re: (ITS#5474) Problem with schema validation in 2.4.8
by ando＠sys-net.it 17 Apr '08

17 Apr '08

ando(a)sys-net.it wrote: > The problem is that OpenLDAP 2.4 allows to add entries that contain > ABSTRACT objectClasses, as soon as no non-ABSTRACT class is subtyped > from them, which is clearly an error. > > It all reduces to a missing negation in the ABSTRACT subclassing check, > resulting in reversing the logic of the test. > > Please test servers/slapd/schema_check.c 1.112 -> 1.113 I also note that 2.3 suffers from the reverse of the reported issue, namely an abstract class is tolerated, even if no other class inherits from 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

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