From michael at stroeder.com Tue Oct 10 12:53:23 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 10 Oct 2000 12:53:23 +0200 Subject: Building python-ldap against Netscape's LDAP-SDK 4.11 References: <39DF3C97.5ED9E859@stroeder.com> Message-ID: <39E2F523.81798D62@stroeder.com> HI! Well, I have to admit that I messed up the libs => forget about my previous pseudo-results. I tried again to build python-ldap against Netscape's LDAP-SDK 4.11 but it fails. David, could you have a look at this? Is there any chance that it's possible to build against 4.11? Maybe it would make more sense to dig into the OpenLDAP 2.x libs? Ciao, Michael. From david.leonard at csee.uq.edu.au Fri Oct 6 01:45:22 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Fri, 6 Oct 2000 09:45:22 +1000 (EST) Subject: Building python-ldap against Netscape's LDAP-SDK 4.11 In-Reply-To: <39DCDBBB.E625D1D5@stroeder.com> Message-ID: On Thu, 5 Oct 2000, Michael Str?der typed thusly: > > Ok, I edited Modules/LDAPObject.c to use only 2 arguments. The really, configure.in should be modified to test for and pick that up... can you send me your diffs to LDAPObject.c? > > module builds now and import ldap works. But it gives me undefined > > exceptions. > > > > ldap.LDAPError: unknown error (C API does not expose error) I just looked at netscape's docs and found the function ldap_get_lderrno(). i've added it in (untested patch at end of message) i'm also going to upgrade Misc/openldap.sh to grab an OpenLDAP 2 release but it seems I'll need to bundle libtool into the distribution :( > It's me again. ;-) talking to yourself is a sign of impending madness :) > I managed to connect to a OpenLDAP 2.0.6 server (which is LDAPv3). > Connecting to OpenLDAP 1.2.11 server (LDAPv2) does not work. It > seems it has something to do with choosing LDAPv3 during connect and > falling back to LDAPv2 if v3 fails. > > I can browse my test data on the OpenLDAP 2.0 server. But when I hit > a LDAPv3 referral entry the exception above is raised. I guess the > C-LDAP-SDK returns some LDAPv3 specific data not known to > python-ldap. no, its probably a simple error, just have to teach the module how to find it. > BTW: The following code is also rejected (it works with OpenLDAP > 1.2.11 libs): > > ldap_obj.deref = ldap.DEREF_NEVER > ldap_obj.options = 0 > > Traceback: > [..] > ldap_obj.options = 0 > NameError: cannot set that field > > Why I want this? hmm, perhaps this is a design error. if the C API doesn't support things like options, then there will be no .options attribute to set. I had originally imagined people writing code like: if hasattr(ldap_obj, 'options'): ldap_obj.options = 0 which shows the variability of the C libraries. however at this level (_ldap), I really wanted to get as close to the C api as possible, and leave it to "higher-level" abstractions to deal with such nitty gritty logic. > I would like to actively catch LDAPv3 referrals. This works slightly > well with catching ldap.PARTIAL_RESULTS and pulling the referral > LDAP URL out of the info field. > However, if binding via LDAPv2 (OpenLDAP 1.2.x libs) to a LDAPv3 > server > 1. the server is free to just ignore my request if a referral is hit > and > 2. I don't get the search continuations of the referral entry when > doing a one level search. > This causes a lot of inconsistent behaviour of my client (besides > all those broken LDAP servers out there...sigh!). suggested patches are welcome :) d -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Index: errors.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/errors.c,v retrieving revision 1.3 diff -u -r1.3 errors.c --- errors.c 2000/08/14 22:37:37 1.3 +++ errors.c 2000/10/05 23:44:05 @@ -30,7 +30,7 @@ PyErr_SetFromErrno( LDAPexception_class ); return NULL; } -#ifdef LDAP_TYPE_IS_OPAQUE +#if !defined(HAVE_LDAP_GET_LDERRNO) && defined(LDAP_TYPE_IS_OPAQUE) else { PyErr_SetString(LDAPexception_class, "unknown error (C API does not expose error)"); @@ -42,8 +42,16 @@ PyObject *errobj; PyObject *info; PyObject *str; + char *m, *s; +#if defined(HAVE_LDAP_GET_LDERRNO) + errnum = ldap_get_lderrno(l, &m, &s); +#else errnum = l->ld_errno; + m = l->ld_matched; + s = l->ld_error; +#endif + if (errnum<0 || errnum>=NUM_LDAP_ERRORS) errobj = LDAPexception_class; /* unknown error XXX */ else @@ -60,22 +68,19 @@ if (str) PyDict_SetItemString( info, "desc", str ); Py_XDECREF(str); + + if (m == NULL && (str = PyString_FromString(m)) != NULL) { + PyDict_SetItemString(info, "matched", str); + Py_DECREF(str); + } else + PyDict_SetItemString(info, "matched", Py_None); + + if (s == NULL && (str = PyString_FromString(s)) != NULL) { + PyDict_SetItemString(info, "info", str); + Py_DECREF(str); + } else + PyDict_SetItemString(info, "info", Py_None); - if (l->ld_matched != NULL && *l->ld_matched != '\0') - { - str = PyString_FromString(l->ld_matched); - if (str) - PyDict_SetItemString( info, "matched", str ); - Py_XDECREF(str); - } - - if (l->ld_error != NULL && *l->ld_error != '\0') - { - str = PyString_FromString(l->ld_error); - if (str) - PyDict_SetItemString( info, "info", str ); - Py_XDECREF(str); - } PyErr_SetObject( errobj, info ); Py_DECREF(info); return NULL; From michael at stroeder.com Tue Oct 17 11:29:06 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 17 Oct 2000 11:29:06 +0200 Subject: patch: l_ldap_result() now properly raising exceptions References: <39E4799A.FC18856A@dante.org.uk> <39E98712.671AF599@stroeder.com> <39EACF10.2373297B@dante.org.uk> <39EB1482.8E6DBD61@stroeder.com> <39EB1E29.5FDFBFA6@dante.org.uk> <39EB286C.74555390@stroeder.com> <39EB63A3.1C372F67@dante.org.uk> Message-ID: <39EC1BE2.A3380F7@stroeder.com> Konstantin Chuguev wrote: > > Oughh. After some late hacking tonight, here we are :-) GREAT!!! It works. I have attached Konstantin's patch to this message. Could someone with more Python/C knowledge look into the patched LDAPObject.c function l_ldap_result() to make sure that we do not introduce new memory leaks with this patch? Note: Since the result() method now properly raises exceptions caused by LDAP errors one might have to add additional exception handling to the calling Python code. Ciao, Michael. -------------- next part -------------- --- LDAPObject.c.orig Mon Aug 14 23:37:37 2000 +++ LDAPObject.c Mon Oct 16 20:54:10 2000 @@ -1198,7 +1198,7 @@ double timeout = -1.0; struct timeval tv; struct timeval* tvp; - int result; + int res_type, result; LDAPMessage *msg = NULL; PyObject *result_str, *retval; @@ -1214,13 +1214,26 @@ } LDAP_BEGIN_ALLOW_THREADS( self ); - result = ldap_result( self->ldap, msgid, all, tvp, &msg ); + res_type = ldap_result( self->ldap, msgid, all, tvp, &msg ); LDAP_END_ALLOW_THREADS( self ); - if (result == -1) + if (res_type < 0) /* LDAP or system error */ return LDAPerror( self->ldap, "ldap_result" ); - result_str = LDAPconstant( result ); + if (res_type == 0) /* Timeout has occured */ + return Py_None; + + if (res_type != LDAP_RES_SEARCH_ENTRY) { + LDAP_BEGIN_ALLOW_THREADS( self ); + result = ldap_result2error( self->ldap, msg, 0 ); + LDAP_END_ALLOW_THREADS( self ); + + if (result != LDAP_SUCCESS) { /* result error */ + return LDAPerror( self->ldap, "ldap_result2error" ); + } + } + + result_str = LDAPconstant( res_type ); if (msg == NULL) { retval = Py_BuildValue("(OO)", result_str, Py_None); From jeff at ollie.clive.ia.us Fri Nov 17 06:01:16 2000 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Thu, 16 Nov 2000 23:01:16 -0600 Subject: patch to compile with OpenLDAP 2.0.7 In-Reply-To: <3A1465FD.C7CF1CC6@stroeder.com>; from michael@stroeder.com on Thu, Nov 16, 2000 at 11:55:57PM +0100 References: <20001116155610.A4547@ollie.clive.ia.us> <3A1465FD.C7CF1CC6@stroeder.com> Message-ID: <20001116230116.A6161@ollie.clive.ia.us> On Thu, Nov 16, 2000 at 11:55:57PM +0100, Michael Str?der wrote: > "Jeffrey C. Ollie" wrote: > > > > I've gotten today's CVS version to compile against OpenLDAP 2.0.7. > > Ooops. Double efforts. I'm currently testing patches by Konstantin > (Cc:-ed) which also allow to retrieve search continuation references > (LDAPv3 referrals). > > He made some changes to attributes of LDAPObject. Especially setting > the options is different. I didn't know that anyone else was working on it... The list has been quiet for some time now. It looks like Konstantin's work goes beyond what I intended to accomplish. I wasn't looking to add any functionality, just to get python-ldap to compile and work. But I'd be happy to test out other patches and perhaps fix a bug or two. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From jeff at ollie.clive.ia.us Thu Nov 16 22:56:10 2000 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Thu, 16 Nov 2000 15:56:10 -0600 Subject: patch to compile with OpenLDAP 2.0.7 Message-ID: <20001116155610.A4547@ollie.clive.ia.us> I've gotten today's CVS version to compile against OpenLDAP 2.0.7. It seems that the OpenLDAP people dropped a number of macros between v1 and v2. A fairly simple patch that #ifdefs the dropped macros and everything compiles fine. Oh yeah, I did have to use "LIBS=-lresolv ./configure" to get the configure script to properly: apparently the RedHat RPM for OpenLDAP introduces a depencency because the configure script fails with an undefined reference to __dn_expand and __res_query. I've attached the patch and also entered a bug on sourceforge. Jeff -------------- next part -------------- --- python-ldap/Modules/constants.c Sun Aug 13 10:00:59 2000 +++ python-ldap-20001116/Modules/constants.c Thu Nov 16 15:15:24 2000 @@ -66,7 +66,9 @@ add_int(d,VERSION1); add_int(d,VERSION2); add_int(d,VERSION); +#ifdef LDAP_MAX_ATTR_LEN add_int(d,MAX_ATTR_LEN); +#endif add_int(d,TAG_MESSAGE); add_int(d,TAG_MSGID); @@ -79,9 +81,15 @@ add_int(d,REQ_MODRDN); add_int(d,REQ_COMPARE); add_int(d,REQ_ABANDON); +#ifdef LDAP_REQ_UNBIND_30 add_int(d,REQ_UNBIND_30); +#endif +#ifdef LDAP_REQ_DELETE_30 add_int(d,REQ_DELETE_30); +#endif +#ifdef LDAP_REQ_ABANDON_30 add_int(d,REQ_ABANDON_30); +#endif /* reversibles */ @@ -106,9 +114,15 @@ add_int(d,AUTH_KRBV4); add_int(d,AUTH_KRBV41); add_int(d,AUTH_KRBV42); +#ifdef LDAP_AUTH_SIMPLE_30 add_int(d,AUTH_SIMPLE_30); +#endif +#ifdef LDAP_AUTH_KRBV41_30 add_int(d,AUTH_KRBV41_30); +#endif +#ifdef LDAP_AUTH_KRBV42_30 add_int(d,AUTH_KRBV42_30); +#endif add_int(d,FILTER_AND); add_int(d,FILTER_OR); add_int(d,FILTER_NOT); @@ -118,13 +132,21 @@ add_int(d,FILTER_LE); add_int(d,FILTER_PRESENT); add_int(d,FILTER_APPROX); +#ifdef LDAP_FILTER_PRESENT_30 add_int(d,FILTER_PRESENT_30); +#endif add_int(d,SUBSTRING_INITIAL); add_int(d,SUBSTRING_ANY); add_int(d,SUBSTRING_FINAL); +#ifdef LDAP_SUBSTRING_INITIAL_30 add_int(d,SUBSTRING_INITIAL_30); +#endif +#ifdef LDAP_SUBSTRING_ANY_30 add_int(d,SUBSTRING_ANY_30); +#endif +#ifdef LDAP_SUBSTRING_FINAL_30 add_int(d,SUBSTRING_FINAL_30); +#endif add_int(d,SCOPE_BASE); add_int(d,SCOPE_ONELEVEL); add_int(d,SCOPE_SUBTREE); @@ -135,7 +157,9 @@ /* (errors.c contains the error constants) */ +#ifdef LDAP_DEFAULT_REFHOPLIMIT add_int(d,DEFAULT_REFHOPLIMIT); +#endif #ifdef LDAP_CACHE_BUCKETS add_int(d,CACHE_BUCKETS); #endif @@ -161,8 +185,12 @@ /* XXX - these belong in errors.c */ +#ifdef LDAP_URL_ERR_NOTLDAP add_int(d,URL_ERR_NOTLDAP); +#endif +#ifdef LDAP_URL_ERR_NODN add_int(d,URL_ERR_NODN); +#endif add_int(d,URL_ERR_BADSCOPE); add_int(d,URL_ERR_MEM); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From michael at stroeder.com Thu Nov 16 23:55:57 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 16 Nov 2000 23:55:57 +0100 Subject: patch to compile with OpenLDAP 2.0.7 References: <20001116155610.A4547@ollie.clive.ia.us> Message-ID: <3A1465FD.C7CF1CC6@stroeder.com> "Jeffrey C. Ollie" wrote: > > I've gotten today's CVS version to compile against OpenLDAP 2.0.7. Ooops. Double efforts. I'm currently testing patches by Konstantin (Cc:-ed) which also allow to retrieve search continuation references (LDAPv3 referrals). He made some changes to attributes of LDAPObject. Especially setting the options is different. Would be nice if you coordinate your work. Thanks to both of you. Ciao, Michael. From david.leonard at dstc.edu.au Sun Nov 19 04:14:06 2000 From: david.leonard at dstc.edu.au (David Leonard) Date: Sun, 19 Nov 2000 04:14:06 +0100 (CET) Subject: thoughts on v3 support In-Reply-To: <20001117141946.B7714@ollie.clive.ia.us> Message-ID: On Fri, 17 Nov 2000, Jeffrey C. Ollie typed thusly: > > Drop it. Since OpenLDAP 2.0.x is out and seems to be reasonable > > stable there's no good reason anymore to support outdated APIs. (In > > the case of Netscape and Novell you even can't download them > > anymore.) > I don't know about Netscape, but you can certainly download the Novell > LDAP libraries. However, that's orthoginal as to whether we want to > keep support for other libraries. some thoughts 1) it is possible to ditch all c library support and implement ldap client code in 100% pure python. the problem is that this is WAY too much effort 2) alternatively, python-ldap could be 'bundled' with a 'preferred' ldapv3 implementation. main problem here is that of choosing one preferred impl bearing in mind that users will find very good reasons to use other libs 3) of course, i think that the real answer is to get a new 'standard' api that the various ldapv3 libs are expected to adhere to, then concentrate on that (with possible support for particular library extensions. ) i couldn't find an LDAPv3 rfc that could be used as for specifying the api. RFC1823 is way out of date now. on the other hand, there is the Java API for ldapv3... does anyone know if the v3 libs that are coming out adhere to some written-down standard api? should someone here just declare one and write it down? comments? d PS met up with michael stroder and mirko in Karlsruhe last night. apart from feeding me concoctions of banana and cherry juice, they tried to teach me some german. -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Cassette tapes have an almost unlimited capacity for data. - Commodore 64 Programmer's Reference Guide (1983) From Konstantin.Chuguev at dante.org.uk Fri Nov 17 11:47:20 2000 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Fri, 17 Nov 2000 10:47:20 +0000 Subject: patch to compile with OpenLDAP 2.0.7 References: <20001116155610.A4547@ollie.clive.ia.us> <3A1465FD.C7CF1CC6@stroeder.com> <20001116230116.A6161@ollie.clive.ia.us> Message-ID: <3A150CB8.D8318A17@dante.org.uk> Hello Jeffrey and all. Attached are recent version of my patches, if you are interested. They provide the following: * automatic recognition of OpenLDAP-1.2.x or OpenLDAP-2.0.x at compilation time, building different sets of Python LDAP constants and error exception objects for different OpenLDAP versions; * special tuples for continuation references: (None, [list_of_URLs]). Compare to normal entry tuples: (DN, {dict_of_attributes}). Both types of tuples can be returned from search methods; * new type of result type in the result method: SEARCH_REFERENCE. * a few new ldap object attributes, among them: referrals - disables (0) or enables (1) following referrals; is set to 1 after ldap object initialisation; version (2 or 3) - sets LDAP protocol version (default is 2). Any comments/suggestions/fixes are welcome. Regards, Konstantin. "Jeffrey C. Ollie" wrote: > On Thu, Nov 16, 2000 at 11:55:57PM +0100, Michael Str?der wrote: > > "Jeffrey C. Ollie" wrote: > > > > > > I've gotten today's CVS version to compile against OpenLDAP 2.0.7. > > > > Ooops. Double efforts. I'm currently testing patches by Konstantin > > (Cc:-ed) which also allow to retrieve search continuation references > > (LDAPv3 referrals). > > > > He made some changes to attributes of LDAPObject. Especially setting > > the options is different. > > I didn't know that anyone else was working on it... The list has been > quiet for some time now. It looks like Konstantin's work goes beyond > what I intended to accomplish. I wasn't looking to add any > functionality, just to get python-ldap to compile and work. But I'd > be happy to test out other patches and perhaps fix a bug or two. > > Jeff > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW: http://www.dante.net -------------- next part -------------- --- constants.c.orig Wed Nov 15 10:41:35 2000 +++ constants.c Wed Nov 15 10:48:23 2000 @@ -66,7 +66,6 @@ add_int(d,VERSION1); add_int(d,VERSION2); add_int(d,VERSION); - add_int(d,MAX_ATTR_LEN); add_int(d,TAG_MESSAGE); add_int(d,TAG_MSGID); @@ -79,9 +78,27 @@ add_int(d,REQ_MODRDN); add_int(d,REQ_COMPARE); add_int(d,REQ_ABANDON); + +#if defined(LDAP_API_VERSION) + /* OpenLDAPv2 */ + add_int(d,VERSION3); + add_int(d,VERSION_MIN); + add_int(d,VERSION_MAX); + add_int(d,TAG_LDAPDN); + add_int(d,TAG_LDAPCRED); + add_int(d,TAG_CONTROLS); + add_int(d,TAG_REFERRAL); + + add_int(d,REQ_MODDN); + add_int(d,REQ_RENAME); +#else + /* OpenLDAPv1 */ + add_int(d,MAX_ATTR_LEN); + add_int(d,REQ_UNBIND_30); add_int(d,REQ_DELETE_30); add_int(d,REQ_ABANDON_30); +#endif /* reversibles */ @@ -89,6 +106,14 @@ PyDict_SetItem( reverse, zero, Py_None ); Py_DECREF( zero ); +#if defined(LDAP_API_VERSION) + /* OpenLDAPv2 */ + add_int_r(d,RES_SEARCH_REFERENCE); + add_int_r(d,RES_MODDN); /* Aliases for RES_MODRDN; */ + add_int_r(d,RES_RENAME); /* init them before the main name */ + add_int(d,RES_UNSOLICITED); +#endif + add_int_r(d,RES_BIND); add_int_r(d,RES_SEARCH_ENTRY); add_int_r(d,RES_SEARCH_RESULT); @@ -106,9 +131,6 @@ add_int(d,AUTH_KRBV4); add_int(d,AUTH_KRBV41); add_int(d,AUTH_KRBV42); - add_int(d,AUTH_SIMPLE_30); - add_int(d,AUTH_KRBV41_30); - add_int(d,AUTH_KRBV42_30); add_int(d,FILTER_AND); add_int(d,FILTER_OR); add_int(d,FILTER_NOT); @@ -118,13 +140,9 @@ add_int(d,FILTER_LE); add_int(d,FILTER_PRESENT); add_int(d,FILTER_APPROX); - add_int(d,FILTER_PRESENT_30); add_int(d,SUBSTRING_INITIAL); add_int(d,SUBSTRING_ANY); add_int(d,SUBSTRING_FINAL); - add_int(d,SUBSTRING_INITIAL_30); - add_int(d,SUBSTRING_ANY_30); - add_int(d,SUBSTRING_FINAL_30); add_int(d,SCOPE_BASE); add_int(d,SCOPE_ONELEVEL); add_int(d,SCOPE_SUBTREE); @@ -133,6 +151,16 @@ add_int(d,MOD_REPLACE); add_int(d,MOD_BVALUES); +#if !defined(LDAP_API_VERSION) + /* OpenLDAPv1 */ + add_int(d,AUTH_SIMPLE_30); + add_int(d,AUTH_KRBV41_30); + add_int(d,AUTH_KRBV42_30); + add_int(d,FILTER_PRESENT_30); + add_int(d,SUBSTRING_INITIAL_30); + add_int(d,SUBSTRING_ANY_30); + add_int(d,SUBSTRING_FINAL_30); + /* (errors.c contains the error constants) */ add_int(d,DEFAULT_REFHOPLIMIT); @@ -145,15 +173,36 @@ #ifdef LDAP_CACHE_OPT_CACHEALLERRS add_int(d,CACHE_OPT_CACHEALLERRS); #endif + +#endif /* !defined(LDAP_API_VERSION) */ add_int(d,FILT_MAXSIZ); add_int(d,DEREF_NEVER); add_int(d,DEREF_SEARCHING); add_int(d,DEREF_FINDING); add_int(d,DEREF_ALWAYS); add_int(d,NO_LIMIT); +#if defined(LDAP_API_VERSION) + /* OpenLDAPv2 */ + add_int(d,OPT_API_INFO); + add_int(d,OPT_DESC); + add_int(d,OPT_DEREF); + add_int(d,OPT_SIZELIMIT); + add_int(d,OPT_TIMELIMIT); + add_int(d,OPT_PROTOCOL_VERSION); + add_int(d,OPT_SERVER_CONTROLS); + add_int(d,OPT_CLIENT_CONTROLS); + add_int(d,OPT_API_FEATURE_INFO); + add_int(d,OPT_HOST_NAME); + add_int(d,OPT_ERROR_NUMBER); + add_int(d,OPT_ERROR_STRING); + add_int(d,OPT_MATCHED_DN); + add_int(d,OPT_PRIVATE_EXTENSION_BASE); +#else + /* OpenLDAPv1 */ #ifdef LDAP_OPT_DNS add_int(d,OPT_DNS); #endif +#endif /* defined(LDAP_API_VERSION) */ #ifdef LDAP_OPT_REFERRALS add_int(d,OPT_REFERRALS); #endif @@ -161,9 +210,24 @@ /* XXX - these belong in errors.c */ +#if defined(LDAP_API_VERSION) + /* OpenLDAPv2 */ + add_int(d,URL_SUCCESS); + add_int(d,URL_ERR_PARAM); + add_int(d,URL_ERR_BADSCHEME); + add_int(d,URL_ERR_BADENCLOSURE); + add_int(d,URL_ERR_BADURL); + add_int(d,URL_ERR_BADHOST); + add_int(d,URL_ERR_BADATTRS); + add_int(d,URL_ERR_BADSCOPE); + add_int(d,URL_ERR_BADFILTER); + add_int(d,URL_ERR_BADEXTS); +#else + /* OpenLDAPv1 */ add_int(d,URL_ERR_NOTLDAP); add_int(d,URL_ERR_NODN); add_int(d,URL_ERR_BADSCOPE); +#endif /* defined(LDAP_API_VERSION) */ add_int(d,URL_ERR_MEM); /* author */ -------------- next part -------------- --- errors.c.orig Wed Nov 15 10:41:35 2000 +++ errors.c Wed Nov 15 14:17:15 2000 @@ -17,7 +17,13 @@ /* list of error objects */ +#if defined(LDAP_API_VERSION) +/* OpenLDAPv2 */ +#define NUM_LDAP_ERRORS LDAP_REFERRAL_LIMIT_EXCEEDED+1 +#else +/* OpenLDAPv1 */ #define NUM_LDAP_ERRORS LDAP_NO_MEMORY+1 +#endif static PyObject* errobjects[ NUM_LDAP_ERRORS ]; @@ -30,21 +36,26 @@ PyErr_SetFromErrno( LDAPexception_class ); return NULL; } -#ifdef LDAP_TYPE_IS_OPAQUE +#if defined(LDAP_TYPE_IS_OPAQUE) && !defined(LDAP_API_VERSION) else { PyErr_SetString(LDAPexception_class, "unknown error (C API does not expose error)"); return NULL; } -#else +#else /* defined(LDAP_TYPE_IS_OPAQUE) && !defined(LDAP_API_VERSION) */ else { int errnum; PyObject *errobj; PyObject *info; PyObject *str; +#if defined(LDAP_API_VERSION) + char *matched, *error; + if (ldap_get_option(l, LDAP_OPT_ERROR_NUMBER, &errnum) < 0) +#else errnum = l->ld_errno; if (errnum<0 || errnum>=NUM_LDAP_ERRORS) +#endif /* defined(LDAP_API_VERSION) */ errobj = LDAPexception_class; /* unknown error XXX */ else errobj = errobjects[errnum]; @@ -61,6 +72,35 @@ PyDict_SetItemString( info, "desc", str ); Py_XDECREF(str); +#if defined(LDAP_API_VERSION) + if (ldap_get_option(l, LDAP_OPT_MATCHED_DN, &matched) >= 0 + && matched != NULL) { + if (*matched != '\0') { + str = PyString_FromString(matched); + if (str) + PyDict_SetItemString( info, "matched", str ); + Py_XDECREF(str); + } + ldap_memfree(matched); + } + + if (errnum == LDAP_REFERRAL) { + str = PyString_FromString(msg); + if (str) + PyDict_SetItemString( info, "info", str ); + Py_XDECREF(str); + } else if (ldap_get_option(l, LDAP_OPT_ERROR_STRING, &error) >= 0 + && error != NULL) { + if (error != '\0') { + str = PyString_FromString(error); + if (str) + PyDict_SetItemString( info, "info", str ); + Py_XDECREF(str); + } + ldap_memfree(error); + } + +#else /* defined(LDAP_API_VERSION) */ if (l->ld_matched != NULL && *l->ld_matched != '\0') { str = PyString_FromString(l->ld_matched); @@ -76,11 +116,12 @@ PyDict_SetItemString( info, "info", str ); Py_XDECREF(str); } +#endif /* defined(LDAP_API_VERSION) */ PyErr_SetObject( errobj, info ); Py_DECREF(info); return NULL; } -#endif +#endif /* defined(LDAP_TYPE_IS_OPAQUE) && !defined(LDAP_API_VERSION) */ } @@ -163,4 +204,19 @@ seterrobj(USER_CANCELLED); seterrobj(PARAM_ERROR); seterrobj(NO_MEMORY); +#if defined(LDAP_API_VERSION) + seterrobj(REFERRAL); + seterrobj(ADMINLIMIT_EXCEEDED); + seterrobj(UNAVAILABLE_CRITICAL_EXTENSION); + seterrobj(CONFIDENTIALITY_REQUIRED); + seterrobj(SASL_BIND_IN_PROGRESS); + seterrobj(AFFECTS_MULTIPLE_DSAS); + seterrobj(CONNECT_ERROR); + seterrobj(NOT_SUPPORTED); + seterrobj(CONTROL_NOT_FOUND); + seterrobj(NO_RESULTS_RETURNED); + seterrobj(MORE_RESULTS_TO_RETURN); + seterrobj(CLIENT_LOOP); + seterrobj(REFERRAL_LIMIT_EXCEEDED); +#endif } -------------- next part -------------- --- LDAPObject.c.orig Wed Nov 15 10:46:27 2000 +++ LDAPObject.c Wed Nov 15 16:24:34 2000 @@ -1204,9 +1204,9 @@ double timeout = -1.0; struct timeval tv; struct timeval* tvp; - int res_type, result; + int res_type; LDAPMessage *msg = NULL; - PyObject *result_str, *retval; + PyObject *result_str, *retval, *pmsg; if (!PyArg_ParseTuple( args, "|iid", &msgid, &all, &timeout )) return NULL; @@ -1232,28 +1232,46 @@ return Py_None; } - /* thanks to Konstantin Chuguev for this */ - if (res_type != LDAP_RES_SEARCH_ENTRY) { - LDAP_BEGIN_ALLOW_THREADS( self ); + if (res_type == LDAP_RES_SEARCH_ENTRY +#if defined(LDAP_API_VERSION) + || res_type == LDAP_RES_SEARCH_REFERENCE +#endif + ) + pmsg = LDAPmessage_to_python( self->ldap, msg ); + else { + int result; +#if defined(LDAP_API_VERSION) + char **refs = NULL; + ldap_parse_result( self->ldap, msg, &result, NULL, NULL, &refs, NULL, 0 ); +#else result = ldap_result2error( self->ldap, msg, 0 ); - LDAP_END_ALLOW_THREADS( self ); - - if (result != LDAP_SUCCESS) { /* result error */ - return LDAPerror( self->ldap, "ldap_result2error" ); +#endif + if (result != LDAP_SUCCESS) { + char *e; +#if defined(LDAP_API_VERSION) + char err[1024]; + if (result == LDAP_REFERRAL && refs && refs[0]) { + snprintf(err, sizeof(err), "Referral:\n%s", refs[0]); + e = err; + } else + e = "ldap_parse_result"; +#else + e = "ldap_result2error"; +#endif + return LDAPerror( self->ldap, e ); } + pmsg = Py_None; } result_str = LDAPconstant( res_type ); - if (msg == NULL) { - retval = Py_BuildValue("(OO)", result_str, Py_None); + if (pmsg == NULL) { + retval = NULL; } else { - PyObject *pmsg = LDAPmessage_to_python( self->ldap, msg ); - if (pmsg == NULL) - retval = NULL; - else - retval = Py_BuildValue("(OO)", result_str, pmsg); - Py_DECREF(pmsg); + retval = Py_BuildValue("(OO)", result_str, pmsg); + if (pmsg != Py_None) { + Py_DECREF(pmsg); + } } Py_DECREF(result_str); return retval; @@ -1444,6 +1462,9 @@ /* ldap_search_s == ldap_search_st */ +#if !defined(LDAP_API_VERSION) +/* OpenLDAPv1 */ + /* ldap_ufn_search_c */ /* ldap_ufn_search_ct */ @@ -1527,6 +1548,8 @@ "\tSee the LDAP library manual pages for more information on these\n" "\t`user-friendly name' functions."; +#endif /* !defined(LDAP_API_VERSION) */ + /* ldap_sort_entries */ /* ldap_url_search */ @@ -1681,9 +1704,12 @@ {"search", (PyCFunction)l_ldap_search, METH_VARARGS, doc_search}, {"search_s", (PyCFunction)l_ldap_search_st, METH_VARARGS, doc_search}, {"search_st", (PyCFunction)l_ldap_search_st, METH_VARARGS, doc_search}, +#if !defined(LDAP_API_VERSION) +/* OpenLDAPv1 */ {"ufn_search_s", (PyCFunction)l_ldap_ufn_search_s, METH_VARARGS, doc_ufn}, {"ufn_setfilter", (PyCFunction)l_ldap_ufn_setfilter, METH_VARARGS, doc_ufn}, {"ufn_setprefix", (PyCFunction)l_ldap_ufn_setprefix, METH_VARARGS, doc_ufn}, +#endif {"url_search_s", (PyCFunction)l_ldap_url_search_st, METH_VARARGS, doc_url_search}, {"url_search_st", (PyCFunction)l_ldap_url_search_st, METH_VARARGS, doc_url_search}, #if defined(FILENO_SUPPORTED) @@ -1758,7 +1784,47 @@ static PyObject* getattr( LDAPObject* self, char* name ) { - +#if defined(LDAP_API_VERSION) +/* OpenLDAPv2 */ + int res, option, intval, is_string = 0; + char *strval; + + if (streq(name,"version")) + option = LDAP_OPT_PROTOCOL_VERSION; + else if (streq(name,"deref")) + option = LDAP_OPT_DEREF; + else if (streq(name,"referrals")) + option = LDAP_OPT_REFERRALS; + else if (streq(name,"restart")) + option = LDAP_OPT_REFERRALS; + else if (streq(name,"timelimit")) + option = LDAP_OPT_TIMELIMIT; + else if (streq(name,"sizelimit")) + option = LDAP_OPT_SIZELIMIT; + else if (streq(name,"errno")) + option = LDAP_OPT_ERROR_NUMBER; + else if (streq(name,"error")) { + option = LDAP_OPT_ERROR_STRING; + is_string = 1; + } else if (streq(name,"matched")) { + option = LDAP_OPT_MATCHED_DN; + is_string = 1; + } else + return Py_FindMethod( methods, (PyObject*)self, name ); + LDAP_BEGIN_ALLOW_THREADS( self ); + res = ldap_get_option(self->ldap, option, is_string ? (void *)&strval + : (void *)&intval); + LDAP_END_ALLOW_THREADS( self ); + if (res < 0) + return LDAPerror( self->ldap, "ldap_get_option" ); + if (!is_string) + return PyInt_FromLong(intval); + if (strval != NULL) + return PyString_FromString(strval); + Py_INCREF(Py_None); + return Py_None; +#else +/* OpenLDAPv1 */ #ifndef LDAP_TYPE_IS_OPAQUE if (streq(name,"lberoptions")) return PyInt_FromLong(self->ldap->ld_lberoptions); @@ -1791,6 +1857,7 @@ return PyInt_FromLong(self->valid); return Py_FindMethod( methods, (PyObject*)self, name ); +#endif /* defined(LDAP_API_VERSION) */ } /* set attribute */ @@ -1798,7 +1865,12 @@ static int setattr( LDAPObject* self, char* name, PyObject* value ) { +#if defined(LDAP_API_VERSION) + int res, intval, option; + int *intptr = &intval; +#else long intval; +#endif if (streq(name,"errno") || streq(name,"error") || @@ -1814,6 +1886,34 @@ return -1; } +#if defined(LDAP_API_VERSION) +/* OpenLDAPv2 */ + if (streq(name,"deref")) + option = LDAP_OPT_DEREF; + else if(streq(name,"version")) + option = LDAP_OPT_PROTOCOL_VERSION; + else if(streq(name,"referrals")) { + option = LDAP_OPT_REFERRALS; + intptr = (void *)intval; + } else if(streq(name,"restart")) { + option = LDAP_OPT_RESTART; + intptr = (void *)intval; + } else if (streq(name,"timelimit")) + option = LDAP_OPT_TIMELIMIT; + else if (streq(name,"sizelimit")) + option = LDAP_OPT_SIZELIMIT; + else { + PyErr_SetString( PyExc_NameError, "cannot set that field" ); + return -1; + } + LDAP_BEGIN_ALLOW_THREADS( self ); + res = ldap_set_option(self->ldap, option, intptr); + LDAP_END_ALLOW_THREADS( self ); + if (res < 0) + return LDAPerror( self->ldap, "ldap_get_option" ), -1; + return 0; +#else +/* OpenLDAPv1 */ # define set(a,max) \ if (streq(name,#a)) { \ if (intval < 0 || intval > max ) \ @@ -1837,6 +1937,7 @@ /* it fell through to here */ PyErr_SetString( PyExc_NameError, "cannot set that field" ); return -1; +#endif /* defined(LDAP_API_VERSION) */ } /* type entry */ -------------- next part -------------- --- message.c.orig Wed Nov 15 10:41:35 2000 +++ message.c Wed Nov 15 16:51:18 2000 @@ -114,6 +114,40 @@ PyList_Append(result, entrytuple); Py_DECREF(entrytuple); } +#if defined(LDAP_API_VERSION) + for(entry = ldap_first_reference(ld,m); + entry != NULL; + entry = ldap_next_reference(ld,entry)) + { + char **refs = NULL; + PyObject* entrytuple; + PyObject* reflist = PyList_New(0); + + if (reflist == NULL) { + Py_DECREF(result); + ldap_msgfree( m ); + return NULL; + } + if (ldap_parse_reference(ld, entry, &refs, NULL, 0) != LDAP_SUCCESS) { + Py_DECREF(result); + ldap_msgfree( m ); + return LDAPerror( ld, "ldap_parse_reference" ); + } + if (refs) { + int i; + for (i=0; refs[i] != NULL; i++) { + PyObject *refstr = PyString_FromString(refs[i]); + PyList_Append(reflist, refstr); + Py_DECREF(refstr); + } + ber_memvfree( (void **) refs ); + } + entrytuple = Py_BuildValue("(sO)", NULL, reflist); + Py_DECREF(reflist); + PyList_Append(result, entrytuple); + Py_DECREF(entrytuple); + } +#endif ldap_msgfree( m ); return result; } From david.leonard at dstc.edu.au Fri Nov 17 15:34:54 2000 From: david.leonard at dstc.edu.au (David Leonard) Date: Fri, 17 Nov 2000 15:34:54 +0100 (CET) Subject: patch to compile with OpenLDAP 2.0.7 In-Reply-To: <3A150CB8.D8318A17@dante.org.uk> Message-ID: Hi everyone. I'm in germany at the moment hey these patches look ok i have a medium concern, something that i've been guilty of and would like to see go away, and that is conditional existance of interfaces. eg ufn_search_s() might be #ifdef'd out and some python program that wants to use it will get a NameError when it tries to use it. A better exception would be NotImplementedError. ie instead of writing #ifdef LDAP_API_THING ldap_ufn_search_s(PyObject blah, blah) { blah; } #endif it ought to be ldap_ufn_search_s(PyObject blah, blah) { #ifdef LDAP_API_THING blah; #else return Py_ErrObject(Py_NotImplementeError); #endif } A similar problem arises with 'constants'.. I'm not sure what to do here.. make all undefined cosntants equal None? also there should be some nice way of reliably determining the underlying library's api version ... maybe _ldap.api_version... any suggestions on how that might be done nicely are welcome. tschuss! d On Fri, 17 Nov 2000, Konstantin Chuguev typed thusly: > Hello Jeffrey and all. > > Attached are recent version of my patches, if you are interested. They > provide the following: > > * automatic recognition of OpenLDAP-1.2.x or OpenLDAP-2.0.x at compilation > time, building different sets of Python LDAP constants and error > exception objects for different OpenLDAP versions; > * special tuples for continuation references: (None, [list_of_URLs]). > Compare to normal entry tuples: (DN, {dict_of_attributes}). Both types > of tuples can be returned from search methods; > * new type of result type in the result method: SEARCH_REFERENCE. > * a few new ldap object attributes, among them: referrals - disables (0) > or enables (1) following referrals; is set to 1 after ldap object > initialisation; version (2 or 3) - sets LDAP protocol version (default > is 2). > > Any comments/suggestions/fixes are welcome. > > > Regards, > Konstantin. > > "Jeffrey C. Ollie" wrote: > > > On Thu, Nov 16, 2000 at 11:55:57PM +0100, Michael Str?der wrote: > > > "Jeffrey C. Ollie" wrote: > > > > > > > > I've gotten today's CVS version to compile against OpenLDAP 2.0.7. > > > > > > Ooops. Double efforts. I'm currently testing patches by Konstantin > > > (Cc:-ed) which also allow to retrieve search continuation references > > > (LDAPv3 referrals). > > > > > > He made some changes to attributes of LDAPObject. Especially setting > > > the options is different. > > > > I didn't know that anyone else was working on it... The list has been > > quiet for some time now. It looks like Konstantin's work goes beyond > > what I intended to accomplish. I wasn't looking to add any > > functionality, just to get python-ldap to compile and work. But I'd > > be happy to test out other patches and perhaps fix a bug or two. > > > > Jeff > > > > From jeff at ollie.clive.ia.us Fri Nov 17 16:56:25 2000 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 17 Nov 2000 09:56:25 -0600 Subject: patch to compile with OpenLDAP 2.0.7 In-Reply-To: ; from david.leonard@dstc.edu.au on Fri, Nov 17, 2000 at 03:34:54PM +0100 References: <3A150CB8.D8318A17@dante.org.uk> Message-ID: <20001117095625.A7006@ollie.clive.ia.us> On Fri, Nov 17, 2000 at 03:34:54PM +0100, David Leonard wrote: > > eg ufn_search_s() might be #ifdef'd out and some python program that wants > to use it will get a NameError when it tries to use it. A better exception > would be NotImplementedError. I don't have a huge problem with that. > A similar problem arises with 'constants'.. I'm not sure what to do here.. > make all undefined cosntants equal None? No, as this will cause problems that are harder to debug as None may be a valid parameter in some cases. If you let NameError exceptions be raised you can immediately track down the offending reference. I don't think that adding code to raise NotImplementedError in the case of undefined constants buys you anything but code bloat. > also there should be some nice way of reliably determining the > underlying library's api version ... maybe _ldap.api_version... > any suggestions on how that might be done nicely are welcome. I'd suggest using LDAP_API_VERSION, LDAP_VENDOR_NAME, and LDAP_VENDOR_VERSION. There are also some miscellaneous LDAP_API_FEATURE* macros. Jeff P.S. Konstantin: I didn't receive a copy of your e-mail with the patches, could you try sending it again? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From Konstantin.Chuguev at dante.org.uk Fri Nov 17 17:26:36 2000 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Fri, 17 Nov 2000 16:26:36 +0000 Subject: patch to compile with OpenLDAP 2.0.7 References: <3A150CB8.D8318A17@dante.org.uk> <20001117095625.A7006@ollie.clive.ia.us> Message-ID: <3A155C3C.362C9824@dante.org.uk> "Jeffrey C. Ollie" wrote: > On Fri, Nov 17, 2000 at 03:34:54PM +0100, David Leonard wrote: > > > > eg ufn_search_s() might be #ifdef'd out and some python program that wants > > to use it will get a NameError when it tries to use it. A better exception > > would be NotImplementedError. > > I don't have a huge problem with that. > Neither do I. > > > A similar problem arises with 'constants'.. I'm not sure what to do here.. > > make all undefined cosntants equal None? > > No, as this will cause problems that are harder to debug as None may > be a valid parameter in some cases. If you let NameError exceptions > be raised you can immediately track down the offending reference. I > don't think that adding code to raise NotImplementedError in the case > of undefined constants buys you anything but code bloat. > I would agree with Jeffrey here. > > > also there should be some nice way of reliably determining the > > underlying library's api version ... maybe _ldap.api_version... > > any suggestions on how that might be done nicely are welcome. > > I'd suggest using LDAP_API_VERSION, LDAP_VENDOR_NAME, and > LDAP_VENDOR_VERSION. There are also some miscellaneous > LDAP_API_FEATURE* macros. > I think David is talking about determining an API version in Python. IMO, as all the python LDAP calls and methods go through the python-ldap anyway, there is a little reason to uncover C API implementation details to the python level. Knowing which features are supported is useful though. But it doesn't necessarily have to be done by creating constants in python-ldap which values are set at the compilation time. For example, if you try to set the version attribute to any value in python-ldap compiled against OpenLDAPv1.2, you'll get an exception; same case with using ufn_ methods etc. I mean, python-ldap should try to hide as many libldap implementation details from the python level as possible, and if it cannot, to indicate it in the most native (Python-wise) way of failure (such as exception). As for C LDAP macros indicating vendor, version and supported features, I don't know much about them. I used approach suggested by Kurt Zeilenga in the attached message. I didn't touch anything related to Netscape/Mozilla/Umich SDK in my patches. There is one thing I don't like in the patches. A client may need ldap.REFERRAL exception to return a list of referral URLs, along with the standard LDAP exception information. Currently, I see no way to attach a variable to the exception object dictionary, as LDAPerror function does not have enough arguments for that. What I have done on the patches is a hack, imitating LDAPv2 behaviour. Maybe we should consider extending LDAPerror function somehow... > > Jeff > > P.S. Konstantin: I didn't receive a copy of your e-mail with the > patches, could you try sending it again? > Sure, I'll send them directly to you in the next message. Not sure if it'll get through, because the original message failed with the following error: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: jeff at ollie.clive.ia.us: SMTP error from remote mailer after RCPT TO:: host max.ollie.clive.ia.us [161.210.214.102]: 550 Cannot route to Regards, Konstantin. -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW: http://www.dante.net -------------- next part -------------- An embedded message was scrubbed... From: "Kurt D. Zeilenga" Subject: Re: How to check OpenLDAP version? Date: Fri, 03 Nov 2000 17:13:42 -0800 Size: 1742 URL: From michael at stroeder.com Fri Nov 17 19:51:10 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 17 Nov 2000 19:51:10 +0100 Subject: patch to compile with OpenLDAP 2.0.7 References: <3A150CB8.D8318A17@dante.org.uk> <20001117095625.A7006@ollie.clive.ia.us> <3A155C3C.362C9824@dante.org.uk> Message-ID: <3A157E1E.7B3BC6DA@stroeder.com> Konstantin Chuguev wrote: > > Knowing which features are supported is useful though. But it doesn't > necessarily have to be done by creating constants in python-ldap which values > are set at the compilation time. For example, if you try to set the version > attribute to any value in python-ldap compiled against OpenLDAPv1.2, you'll get > an exception; same case with using ufn_ methods etc. Yes, an exception is sufficient. Well, let me repeat my position: You can change python-ldap to be completely incompatible to previous versions. I'm fine with that if I get full LDAPv3 support (some steps already made by Konstantin :-), VLV, SSL/TLS, bla di bla... > I didn't touch anything related to Netscape/Mozilla/Umich SDK in my > patches. Drop it. Since OpenLDAP 2.0.x is out and seems to be reasonable stable there's no good reason anymore to support outdated APIs. (In the case of Netscape and Novell you even can't download them anymore.) > Maybe we should consider extending LDAPerror function somehow... Anyway, drop compability whereever it's necessary to have a cleaner design! I'm fine with a new CVS branch for python-ldap. For compability with old python-ldap we can write a Python wrapper class later... Ciao, Michael. From jeff at ollie.clive.ia.us Fri Nov 17 21:19:46 2000 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 17 Nov 2000 14:19:46 -0600 Subject: patch to compile with OpenLDAP 2.0.7 In-Reply-To: <3A157E1E.7B3BC6DA@stroeder.com>; from michael@stroeder.com on Fri, Nov 17, 2000 at 07:51:10PM +0100 References: <3A150CB8.D8318A17@dante.org.uk> <20001117095625.A7006@ollie.clive.ia.us> <3A155C3C.362C9824@dante.org.uk> <3A157E1E.7B3BC6DA@stroeder.com> Message-ID: <20001117141946.B7714@ollie.clive.ia.us> On Fri, Nov 17, 2000 at 07:51:10PM +0100, Michael Str?der wrote: > Konstantin Chuguev wrote: > > > > I didn't touch anything related to Netscape/Mozilla/Umich SDK in my > > patches. > > Drop it. Since OpenLDAP 2.0.x is out and seems to be reasonable > stable there's no good reason anymore to support outdated APIs. (In > the case of Netscape and Novell you even can't download them > anymore.) I don't know about Netscape, but you can certainly download the Novell LDAP libraries. However, that's orthoginal as to whether we want to keep support for other libraries. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From jeff at ollie.clive.ia.us Fri Nov 17 21:19:46 2000 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 17 Nov 2000 14:19:46 -0600 Subject: patch to compile with OpenLDAP 2.0.7 In-Reply-To: <3A157E1E.7B3BC6DA@stroeder.com>; from michael@stroeder.com on Fri, Nov 17, 2000 at 07:51:10PM +0100 References: <3A150CB8.D8318A17@dante.org.uk> <20001117095625.A7006@ollie.clive.ia.us> <3A155C3C.362C9824@dante.org.uk> <3A157E1E.7B3BC6DA@stroeder.com> Message-ID: <20001117141946.B7714@ollie.clive.ia.us> On Fri, Nov 17, 2000 at 07:51:10PM +0100, Michael Str?der wrote: > Konstantin Chuguev wrote: > > > > I didn't touch anything related to Netscape/Mozilla/Umich SDK in my > > patches. > > Drop it. Since OpenLDAP 2.0.x is out and seems to be reasonable > stable there's no good reason anymore to support outdated APIs. (In > the case of Netscape and Novell you even can't download them > anymore.) I don't know about Netscape, but you can certainly download the Novell LDAP libraries. However, that's orthoginal as to whether we want to keep support for other libraries. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From michael at stroeder.com Fri Nov 17 19:41:12 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 17 Nov 2000 19:41:12 +0100 Subject: patch to compile with OpenLDAP 2.0.7 References: Message-ID: <3A157BC8.E1388741@stroeder.com> David Leonard wrote: > > i have a medium concern, something that i've been guilty of and would like > to see go away, and that is conditional existance of interfaces. > > eg ufn_search_s() might be #ifdef'd out and some python program that wants > to use it will get a NameError when it tries to use it. A better exception > would be NotImplementedError. Kick it out. Even the exception you mentioned isn't necessary. No serious LDAP programmer used it I guess. > A similar problem arises with 'constants'.. I'm not sure what to do here.. > make all undefined cosntants equal None? Just kick it out. > also there should be some nice way of reliably determining the > underlying library's api version ... maybe _ldap.api_version... > any suggestions on how that might be done nicely are welcome. I even have no problems with starting from scratch. I happily rewrite the changed parts in web2ldap just to get proper LDAPv3 support and SSL/TLS... Maybe let's start with a new LDAPEXT-inspired python-ldap 2.x? Ciao, Michael. From michael at stroeder.com Fri Nov 17 07:48:18 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 17 Nov 2000 07:48:18 +0100 Subject: patch to compile with OpenLDAP 2.0.7 References: <20001116155610.A4547@ollie.clive.ia.us> <3A1465FD.C7CF1CC6@stroeder.com> <20001116230116.A6161@ollie.clive.ia.us> Message-ID: <3A14D4B2.1D3B38BA@stroeder.com> "Jeffrey C. Ollie" wrote: > > On Thu, Nov 16, 2000 at 11:55:57PM +0100, Michael Str?der wrote: > > "Jeffrey C. Ollie" wrote: > > > > > > I've gotten today's CVS version to compile against OpenLDAP 2.0.7. > > > > Ooops. Double efforts. I'm currently testing patches by Konstantin > > (Cc:-ed) which also allow to retrieve search continuation references > > (LDAPv3 referrals). > > > > He made some changes to attributes of LDAPObject. Especially setting > > the options is different. > > I didn't know that anyone else was working on it... The list has been > quiet for some time now. We did not expect anybody else to work on it. Therefore there was no announcement here. > It looks like Konstantin's work goes beyond > what I intended to accomplish. I wasn't looking to add any > functionality, just to get python-ldap to compile and work. Well, when building against OpenLDAP 2.0.x libs you gain some new important features. Especially LDAPv3 is what we basically need to handle referrals in a reasonable manner. This might lead to incompatible python-ldap API but the new features are worth it, I think. > But I'd > be happy to test out other patches and perhaps fix a bug or two. Well, are you interested in adding new functionality? If yes, SSL/TLS support and some parts of the new LDAPEXT-API would be nice. I'm not a C programmer myself. I can just provide help with designing the new API and doing extensive tests. Ciao, Michael. From jeff at ollie.clive.ia.us Fri Nov 17 21:15:09 2000 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 17 Nov 2000 14:15:09 -0600 Subject: patch to compile with OpenLDAP 2.0.7 In-Reply-To: <3A14D4B2.1D3B38BA@stroeder.com>; from michael@stroeder.com on Fri, Nov 17, 2000 at 07:48:18AM +0100 References: <20001116155610.A4547@ollie.clive.ia.us> <3A1465FD.C7CF1CC6@stroeder.com> <20001116230116.A6161@ollie.clive.ia.us> <3A14D4B2.1D3B38BA@stroeder.com> Message-ID: <20001117141509.A7714@ollie.clive.ia.us> On Fri, Nov 17, 2000 at 07:48:18AM +0100, Michael Str?der wrote: > "Jeffrey C. Ollie" wrote: > > > > I didn't know that anyone else was working on it... The list has been > > quiet for some time now. > > We did not expect anybody else to work on it. Therefore there was no > announcement here. > > > It looks like Konstantin's work goes beyond what I intended to > > accomplish. I wasn't looking to add any functionality, just to > > get python-ldap to compile and work. > > Well, when building against OpenLDAP 2.0.x libs you gain some new > important features. Especially LDAPv3 is what we basically need to > handle referrals in a reasonable manner. This might lead to > incompatible python-ldap API but the new features are worth it, I > think. Yes, a worthy goal. However, it'd be nice to get a version out the door that compiles/links against 2.0.x and then worry about new functionality introduced by LDAPv3. > > But I'd be happy to test out other patches and perhaps fix a bug > > or two. > > Well, are you interested in adding new functionality? If yes, > SSL/TLS support and some parts of the new LDAPEXT-API would be nice. > I'm not a C programmer myself. I can just provide help with > designing the new API and doing extensive tests. SSL/TLS would be high on my priority list. I do know how to program in C but programming isn't my primary duty at work and I don't ever seem to get much free time at home that I can work on programming. But who knows, maybe I'll stay up late one night... Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From jeff at ollie.clive.ia.us Fri Nov 17 21:15:09 2000 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 17 Nov 2000 14:15:09 -0600 Subject: patch to compile with OpenLDAP 2.0.7 In-Reply-To: <3A14D4B2.1D3B38BA@stroeder.com>; from michael@stroeder.com on Fri, Nov 17, 2000 at 07:48:18AM +0100 References: <20001116155610.A4547@ollie.clive.ia.us> <3A1465FD.C7CF1CC6@stroeder.com> <20001116230116.A6161@ollie.clive.ia.us> <3A14D4B2.1D3B38BA@stroeder.com> Message-ID: <20001117141509.A7714@ollie.clive.ia.us> On Fri, Nov 17, 2000 at 07:48:18AM +0100, Michael Str?der wrote: > "Jeffrey C. Ollie" wrote: > > > > I didn't know that anyone else was working on it... The list has been > > quiet for some time now. > > We did not expect anybody else to work on it. Therefore there was no > announcement here. > > > It looks like Konstantin's work goes beyond what I intended to > > accomplish. I wasn't looking to add any functionality, just to > > get python-ldap to compile and work. > > Well, when building against OpenLDAP 2.0.x libs you gain some new > important features. Especially LDAPv3 is what we basically need to > handle referrals in a reasonable manner. This might lead to > incompatible python-ldap API but the new features are worth it, I > think. Yes, a worthy goal. However, it'd be nice to get a version out the door that compiles/links against 2.0.x and then worry about new functionality introduced by LDAPv3. > > But I'd be happy to test out other patches and perhaps fix a bug > > or two. > > Well, are you interested in adding new functionality? If yes, > SSL/TLS support and some parts of the new LDAPEXT-API would be nice. > I'm not a C programmer myself. I can just provide help with > designing the new API and doing extensive tests. SSL/TLS would be high on my priority list. I do know how to program in C but programming isn't my primary duty at work and I don't ever seem to get much free time at home that I can work on programming. But who knows, maybe I'll stay up late one night... Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From michael at stroeder.com Fri Nov 17 22:01:39 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 17 Nov 2000 22:01:39 +0100 Subject: patch to compile with OpenLDAP 2.0.7 References: <20001116155610.A4547@ollie.clive.ia.us> <3A1465FD.C7CF1CC6@stroeder.com> <20001116230116.A6161@ollie.clive.ia.us> <3A14D4B2.1D3B38BA@stroeder.com> <20001117141509.A7714@ollie.clive.ia.us> Message-ID: <3A159CB3.F17EB0BF@stroeder.com> "Jeffrey C. Ollie" wrote: > > Yes, a worthy goal. However, it'd be nice to get a version out the > door that compiles/links against 2.0.x and then worry about new > functionality introduced by LDAPv3. Konstantin's patches already compile cleanly and work. I will do further testing this weekend. The most important goal was to be able to bind as a LDAPv3 client. > SSL/TLS would be high on my priority list. I do know how to program > in C but programming isn't my primary duty at work and I don't ever > seem to get much free time at home that I can work on programming. One of the main advantages of the OpenLDAP 2.0.x libs is that they have already built-in support for LDAP over SSL, LDAP with STARTTLS extension and SASL binding. Theoretically you can enable features this by setting the right options... Ciao, Michael. From michael at stroeder.com Sun Nov 19 11:41:20 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 19 Nov 2000 11:41:20 +0100 Subject: thoughts on v3 support References: Message-ID: <3A17AE50.36A39520@stroeder.com> David Leonard wrote: > > 1) it is possible to ditch all c library support and implement ldap > client code in 100% pure python. the problem is that this is WAY too > much effort I already seriously thought about this. I'm currently using a ASN.1 parser module written by Jeremy Hylton for my own X.509 certificate library. I'm doing some patches for this to get more standard ASN.1 types into it. This ASN.1 module could be used to implement a LDAP library. I agree it's much effort. > 2) alternatively, python-ldap could be 'bundled' with a 'preferred' ldapv3 > implementation. main problem here is that of choosing one preferred impl > bearing in mind that users will find very good reasons to use other libs As I already said: You will have difficulties to download the right version of at least the Netscape libs (not sure about the Novell libs). Recent Netscape version 4.x differ is various aspects like setting options etc. that it will be difficult to support them. > 3) of course, i think that the real answer is to get a new 'standard' api YES! > that the various ldapv3 libs are expected to adhere to, then concentrate > on that (with possible support for particular library extensions. ) YES! Concentrating on the OpenLDAP 2.0.x libs would give access to more useful features besides LDAPv3 binding like: - LDAP over SSL - LDAP with STARTTLS - SASL - normalizing functions for DNs - UTF-8 checking - all schema stuff - LDAP syntax checking ... > i couldn't find an LDAPv3 rfc that could be used as for specifying the api. > RFC1823 is way out of date now. on the other hand, there is the Java API > for ldapv3... There's no RFC yet. OpenLDAP 2.0.x implements LDAPEXT-API which is only an Internet draft up to now. See http://www.ietf.org/html.charters/ldapext-charter.html for more info. Ciao, Michael. From michael at stroeder.com Sun Nov 19 11:57:57 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 19 Nov 2000 11:57:57 +0100 Subject: Unicode objects Message-ID: <3A17B235.45DE7989@stroeder.com> HI! BTW: Unicode objects (Python 1.6+) are quite handy for LDAP applications which have to hande NON-ASCII characters... Ciao, Michael. From david.leonard at dstc.edu.au Sun Dec 10 14:28:54 2000 From: david.leonard at dstc.edu.au (David Leonard) Date: Sun, 10 Dec 2000 14:28:54 +0100 (CET) Subject: on removing constants Message-ID: On Thu, 16 Nov 2000, Jeffrey C. Ollie typed thusly: > I've gotten today's CVS version to compile against OpenLDAP 2.0.7. It > seems that the OpenLDAP people dropped a number of macros between v1 > and v2. A fairly simple patch that #ifdefs the dropped macros and > everything compiles fine. I think it will be more beneficial to just remove those dead constants from the python namespace altogether. Does anyone ever use them? Here's the list MAX_ATTR_LEN REQ_UNBIND_30 REQ_DELETE_30 REQ_ABANDON_30 AUTH_SIMPLE_30 AUTH_KRBV41_30 AUTH_KRBV42_30 FILTER_PRESENT_30 SUBSTRING_INITIAL_30 SUBSTRING_ANY_30 SUBSTRING_FINAL_30 URL_ERR_NOTLDAP URL_ERR_NODN CACHE_BUCKETS CACHE_OPT_CACHENOERRS CACHE_OPT_CACHEALLERRS DEFAULT_REFHOPLIMIT OPT_DNS OPT_REFERRALS Does anyone even use the cache control stuff? If you do, I will suggest that the future cache calls be of the form l.set_cache_options("noerrs", "blah") Instead of l.set_cache_options(_ldap.CACHE_OPT_CACHENOERRS | _ldap.BLAH) It reads a bit easier too. comments? What about the referrals and DNS options? someone must, surely :) i think also that a string-base approach would be better there too. >>> l.options ("restart",) >>> l.options = l.options + "referrals", >>> l.options ("referrals", "restart") >>> l.options = l.options + "snork", # silently ignored?? ("referrals", "restart") i've been talking to michael stroeder about getting all these things together in a clean way for a '2.0' release of python-ldap. this means that strong changes like the above are quite possible. d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 I put my chin on my knee, and looked for flaws in the soft grain of my beige plastic monitor casing. - Julian Assange Index: constants.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/constants.c,v retrieving revision 1.5 diff -u -r1.5 constants.c --- constants.c 2000/08/13 15:00:59 1.5 +++ constants.c 2000/12/10 13:07:58 @@ -66,7 +66,7 @@ add_int(d,VERSION1); add_int(d,VERSION2); add_int(d,VERSION); - add_int(d,MAX_ATTR_LEN); + /* add_int(d,MAX_ATTR_LEN); */ add_int(d,TAG_MESSAGE); add_int(d,TAG_MSGID); @@ -79,9 +79,9 @@ add_int(d,REQ_MODRDN); add_int(d,REQ_COMPARE); add_int(d,REQ_ABANDON); - add_int(d,REQ_UNBIND_30); - add_int(d,REQ_DELETE_30); - add_int(d,REQ_ABANDON_30); + /* add_int(d,REQ_UNBIND_30); */ + /* add_int(d,REQ_DELETE_30); */ + /* add_int(d,REQ_ABANDON_30); */ /* reversibles */ @@ -106,9 +106,9 @@ add_int(d,AUTH_KRBV4); add_int(d,AUTH_KRBV41); add_int(d,AUTH_KRBV42); - add_int(d,AUTH_SIMPLE_30); - add_int(d,AUTH_KRBV41_30); - add_int(d,AUTH_KRBV42_30); + /* add_int(d,AUTH_SIMPLE_30); */ + /* add_int(d,AUTH_KRBV41_30); */ + /* add_int(d,AUTH_KRBV42_30); */ add_int(d,FILTER_AND); add_int(d,FILTER_OR); add_int(d,FILTER_NOT); @@ -118,13 +118,13 @@ add_int(d,FILTER_LE); add_int(d,FILTER_PRESENT); add_int(d,FILTER_APPROX); - add_int(d,FILTER_PRESENT_30); + /* add_int(d,FILTER_PRESENT_30); */ add_int(d,SUBSTRING_INITIAL); add_int(d,SUBSTRING_ANY); add_int(d,SUBSTRING_FINAL); - add_int(d,SUBSTRING_INITIAL_30); - add_int(d,SUBSTRING_ANY_30); - add_int(d,SUBSTRING_FINAL_30); + /* add_int(d,SUBSTRING_INITIAL_30); */ + /* add_int(d,SUBSTRING_ANY_30); */ + /* add_int(d,SUBSTRING_FINAL_30); */ add_int(d,SCOPE_BASE); add_int(d,SCOPE_ONELEVEL); add_int(d,SCOPE_SUBTREE); @@ -135,34 +135,24 @@ /* (errors.c contains the error constants) */ - add_int(d,DEFAULT_REFHOPLIMIT); -#ifdef LDAP_CACHE_BUCKETS - add_int(d,CACHE_BUCKETS); -#endif -#ifdef LDAP_CACHE_OPT_CACHENOERRS - add_int(d,CACHE_OPT_CACHENOERRS); -#endif -#ifdef LDAP_CACHE_OPT_CACHEALLERRS - add_int(d,CACHE_OPT_CACHEALLERRS); -#endif + /* add_int(d,DEFAULT_REFHOPLIMIT); */ + /* add_int(d,CACHE_BUCKETS); */ + /* add_int(d,CACHE_OPT_CACHENOERRS); */ + /* add_int(d,CACHE_OPT_CACHEALLERRS); */ add_int(d,FILT_MAXSIZ); add_int(d,DEREF_NEVER); add_int(d,DEREF_SEARCHING); add_int(d,DEREF_FINDING); add_int(d,DEREF_ALWAYS); add_int(d,NO_LIMIT); -#ifdef LDAP_OPT_DNS - add_int(d,OPT_DNS); -#endif -#ifdef LDAP_OPT_REFERRALS - add_int(d,OPT_REFERRALS); -#endif + /* add_int(d,OPT_DNS); */ + /* add_int(d,OPT_REFERRALS); */ add_int(d,OPT_RESTART); /* XXX - these belong in errors.c */ - add_int(d,URL_ERR_NOTLDAP); - add_int(d,URL_ERR_NODN); + /* add_int(d,URL_ERR_NOTLDAP); */ + /* add_int(d,URL_ERR_NODN); */ add_int(d,URL_ERR_BADSCOPE); add_int(d,URL_ERR_MEM); From michael at stroeder.com Sun Dec 10 14:51:47 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 10 Dec 2000 14:51:47 +0100 Subject: on removing constants References: Message-ID: <3A338A73.2F30251D@stroeder.com> David Leonard wrote: > > Does anyone ever use them? Here's the list > [..] > OPT_REFERRALS I was using it. > Does anyone even use the cache control stuff? Yes. I think we should leave the 1.x stuff as is and start with python-ldap-ext based on OpenLDAP 2.0.x... Ciao, Michael. From david.leonard at dstc.edu.au Sun Dec 10 23:27:49 2000 From: david.leonard at dstc.edu.au (David Leonard) Date: Sun, 10 Dec 2000 23:27:49 +0100 (CET) Subject: python-ldap-2.0 In-Reply-To: <3A338A73.2F30251D@stroeder.com> Message-ID: On Sun, 10 Dec 2000, Michael Str?der typed thusly: > I think we should leave the 1.x stuff as is and start with > python-ldap-ext based on OpenLDAP 2.0.x... Okay, to keep everyone on the list informed: Michael, as a knowledgable Karlsruhe local, showed me all the local restaurants that have closed down and then we discussed the direction for python-ldap. After a few drinks, and a discussion on cats, we agreed on the following plan: * python-ldap-1.10 will be tidied up, with just the memory-leak patches applied, and a proper documentation build. (ie no v3 changes will be applied as it breaks v2 builds.) A final release will be made. * A new python-ldap-2.0 will be started, with an API that is likely to be somewhat incompatible with that of p-l-1.10. In particular, the following will be the major compatibility targets: + Python-2.0 support (ie unicode) + OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT) This means that people relying on v2 client/servers should be happy enough with a reasonably stable release. And people wanting to live in the 3rd millenium should be happy with a version (relatively) free of legacy support. Please, comment! Are there problems with the above plan? In addition, I seek more comment on any more changes that the _ldap library may need to support LDAPv3 connections. (Remember that the purpose of this module is not to give an abstraction of X.500 directory services, but rather to provide an abstraction of the LDAP C API.) d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 I put my chin on my knee, and looked for flaws in the soft grain of my beige plastic monitor casing. - Julian Assange From michael at stroeder.com Mon Dec 11 14:32:38 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 11 Dec 2000 14:32:38 +0100 Subject: python-ldap-2.0 References: Message-ID: <3A34D776.EB659D21@stroeder.com> David Leonard wrote: > > On Sun, 10 Dec 2000, Michael Str?der typed thusly: > > I think we should leave the 1.x stuff as is and start with > > python-ldap-ext based on OpenLDAP 2.0.x... > > Okay, to keep everyone on the list informed: > > Michael, as a knowledgable Karlsruhe local, showed me all the local > restaurants that have closed down and then we discussed the direction for > python-ldap. After a few drinks, and a discussion on cats, we agreed on > the following plan: Been there, got a t-shirt(?). > In addition, I seek more comment on any more changes that the _ldap library > may need to support LDAPv3 connections. (Remember that the purpose of this > module is not to give an abstraction of X.500 directory services, but rather > to provide an abstraction of the LDAP C API.) I would like to stay as close as possible to the new LDAP-EXT API in OpenLDAP 2.0.x since this API already trys to give some level of abstraction (SASL for providing several authentication methods etc.). Once again the things I would like to see: - LDAPv3 binding - proper support for search continuations (LDAPv3 referrals) - SSL and STARTTLS support - Access to schema functions (would save lots of work in Python applications) - Virtual List Controls (rather low-prio) IMHO python-ldap 2.0 should provide as much access to the C-API as possible (except the functions marked as deprecated in ldap.h. We can put a Python-written abstraction layer above this later. > Please, comment! Yes! I hope this discussion is not "local". ;-) Ciao, Michael. From jlittle at stanford.edu Tue Nov 28 02:00:16 2000 From: jlittle at stanford.edu (Joe Little) Date: Mon, 27 Nov 2000 17:00:16 -0800 (PST) Subject: New python-ldap-1.10alpha3 RPM available w/ OpenLDAP 2.x patch Message-ID: I've place on Open-IT.org's website my first build of python-ldap w/ the patch provided by Jeffrey C. Ollie on this list. If there is anything you'd like better with the RPM, as well as who I need to site, etc, please tell me. There were no SRPMs available to build from, so this is a new RPM spec file and all that.. http://www.open-it.org/download The file is both in the prototypes directory (with my addluser script), and in each of the distribution directories. SRPMS are with the distributions only. You can track any changes to the RPM via www.open-it.org From sascha at free.de Tue Dec 12 12:07:23 2000 From: sascha at free.de (Sascha Gresk) Date: Tue, 12 Dec 2000 12:07:23 CET Subject: python-ldap-2.0 Message-ID: <200012121108.eBCB8Nu32718@lists.sourceforge.net> > > In addition, I seek more comment on any more changes that the _ldap > library > > may need to support LDAPv3 connections. (Remember that the purpose of > this > > module is not to give an abstraction of X.500 directory services, but > rather > > to provide an abstraction of the LDAP C API.) So implementing all in pure python isnt the way to go ?. > > Please, comment! So are you still going to handcraft all wrappers by hand ? - I am still using SWIG to get this job done for my environment. Now I have a job to swig myself towards v3 ... > > Yes! I hope this discussion is not "local". ;-) > Well, Dortmund and Karlsruhe might be considered local ;-) > Ciao, Michael. > From michael at stroeder.com Tue Dec 12 12:25:49 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 12 Dec 2000 12:25:49 +0100 Subject: python-ldap-2.0 References: <200012121108.eBCB8Nu32718@lists.sourceforge.net> Message-ID: <3A360B3D.C9DB2FFF@stroeder.com> Sascha Gresk wrote: > > > > to provide an abstraction of the LDAP C API.) > > So implementing all in pure python isnt the way to go ?. A pure Python implementation would be hard work! I played with an ASN.1 decoder/encoder module for a while. Even building the messages is not easy but think of all the schema handling and syntax checking - not to speak of SSL/TLS ... > > > Please, comment! > > So are you still going to handcraft all wrappers by hand ? - I > am still using SWIG to get this job done for my environment. > Now I have a job to swig myself towards v3 ... Did you release some of your LDAP-related SWIG stuff to the public? Maybe I missed the announcement. Since python-ldap 2.0 is meant to be a completely new implementation you're welcome to contribute your work with SWIG. Ciao, Michael. From sascha at free.de Tue Dec 12 12:56:25 2000 From: sascha at free.de (Sascha Gresk) Date: Tue, 12 Dec 2000 12:56:25 CET Subject: python-ldap-2.0 Message-ID: <200012121157.MAA13315@post.webmailer.de> [...] > > > > So implementing all in pure python isnt the way to go ?. > > A pure Python implementation would be hard work! I agree ;-) > > Did you release some of your LDAP-related SWIG stuff to the public? Yes, have a look at http://www.free.de/homes/sascha/swig-ldap. > Maybe I missed the announcement. Well using swig-ldap might still be awfull for users of python-ldap, so I wasnt talking to much about it ... >Since python-ldap 2.0 is meant to > be a completely new implementation you're welcome to contribute your > work with SWIG. > Maybe its not as complete as python-ldap but its used in a productive enviroment (solaris 5.5.1 / 7.2 ; freebsd ) and might serve as an interesting example. Bye, Sascha > Ciao, Michael. > From michael at stroeder.com Tue Dec 12 15:59:38 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 12 Dec 2000 15:59:38 +0100 Subject: python-ldap-2.0 References: <20001212154927.B24099@mediasupervision.de> Message-ID: <3A363D5A.5A46E06C@stroeder.com> Gregor Hoffleit wrote: > > > + Python-2.0 support (ie unicode) > > When you write 'Python 2.0 support' and 'free of legacy support', does this > mean that this new version won't work anymore with Python 1.5.2 ? Not sure how David will comment. My personal opinion is that python-ldap 2.0 should make direct use of the new Unicode objects in Python 2.0 (I dropped Python 1.5.2 in web2ldap because of this). If we can provide normal string support and Unicode support at the same time without producing a code bloat then we could keep Python 1.5.2 support. If it gets too messy personally I would like to drop support for non-Unicode Python versions since migrating to e.g. Python 2.0 isn't that hard anyway and Unicode objects are so handy... Ciao, Michael. From gregor at mediasupervision.de Tue Dec 12 15:49:27 2000 From: gregor at mediasupervision.de (Gregor Hoffleit) Date: Tue, 12 Dec 2000 15:49:27 +0100 Subject: python-ldap-2.0 Message-ID: <20001212154927.B24099@mediasupervision.de> David, > * A new python-ldap-2.0 will be started, with an API that is likely > to be somewhat incompatible with that of p-l-1.10. In particular, > the following will be the major compatibility targets: > + Python-2.0 support (ie unicode) > + OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT) > > This means that people relying on v2 client/servers should be happy enough >?with a reasonably stable release. And people wanting to live in the 3rd > millenium should be happy with a version (relatively) free of legacy > support. When you write 'Python 2.0 support' and 'free of legacy support', does this mean that this new version won't work anymore with Python 1.5.2 ? Gregor From michael at stroeder.com Tue Dec 12 16:07:57 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 12 Dec 2000 16:07:57 +0100 Subject: python-ldap-2.0 References: <20001212154927.B24099@mediasupervision.de> Message-ID: <3A363F4D.6062B6A1@stroeder.com> Gregor Hoffleit wrote: > > When you write 'Python 2.0 support' and 'free of legacy support', > does this mean that this new version won't work anymore > with Python 1.5.2 ? Additional note: The old python-ldap 1.10.x will be properly released. The new python-ldap 2.0 will be incompatible to old applications anyway (just like the new OpenLDAP 2.0.x API based on LDAP-EXT is not compatible to the old OpenLDAP 1.2.x API based on RFC1823). Ciao, Michael. From fog at mixadlive.com Tue Dec 12 17:50:07 2000 From: fog at mixadlive.com (Federico Di Gregorio) Date: Tue, 12 Dec 2000 17:50:07 +0100 Subject: python-ldap-2.0 In-Reply-To: <3A34D776.EB659D21@stroeder.com>; from michael@stroeder.com on Mon, Dec 11, 2000 at 02:32:38PM +0100 References: <3A34D776.EB659D21@stroeder.com> Message-ID: <20001212175007.G18867@mixadlive.com> Scavenging the mail folder uncovered Michael Str?der's letter: > > In addition, I seek more comment on any more changes that the _ldap library > > may need to support LDAPv3 connections. (Remember that the purpose of this > > module is not to give an abstraction of X.500 directory services, but rather > > to provide an abstraction of the LDAP C API.) > > I would like to stay as close as possible to the new LDAP-EXT API in > OpenLDAP 2.0.x since this API already trys to give some level of > abstraction (SASL for providing several authentication methods > etc.). i agree. > Once again the things I would like to see: > > - LDAPv3 binding > - proper support for search continuations (LDAPv3 referrals) > - SSL and STARTTLS support > - Access to schema functions (would save lots of work in Python > applications) mmm... what are schema functions? some time ago i was trying to code some v3 schema support in pure python (do you remember) but i never tidied up the code to something really useable. (nobody ever tried my code to... *grin*) ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog at mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog at debian.org The number of the beast: vi vi vi. -- Delexa Jones From michael at stroeder.com Tue Dec 12 18:18:19 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 12 Dec 2000 18:18:19 +0100 Subject: python-ldap-2.0 References: <3A34D776.EB659D21@stroeder.com> <20001212175007.G18867@mixadlive.com> Message-ID: <3A365DDB.D3268378@stroeder.com> Federico Di Gregorio wrote: > > mmm... what are schema functions? some time ago i was trying to > code some v3 schema support in pure python (do you remember) but > i never tidied up the code to something really useable. (nobody > ever tried my code to... *grin*) The schema functions are exposed in ldap_schema.h of OpenLDAP 2.0.x and are exactly what you started to write (off course I remember). Ciao, Michael. From lbarstow at vr1.com Thu Dec 14 22:21:51 2000 From: lbarstow at vr1.com (Les Barstow) Date: Thu, 14 Dec 2000 14:21:51 -0700 Subject: Spec file Message-ID: <3A3939EF.13CFA47E@vr1.com> I was wondering if someone could provide the SPEC file which was used to compile the RPM for RedHat. I have a RedHat 6.2 SPARC box, but have an interest in maintaining python-ldap as a package. I'd be happy to donate the SPARC RPM back to the development site. Thanks, (PS - I'm not subscribed to the dev list; just an interested user...) -- Les Barstow | e-mail: lbarstow at vr1.com System Administrator | VR-1, Inc. | The box said "Requires Windows 95 or better", http://www.vr1.com | so I installed Linux! From michael at stroeder.com Fri Dec 15 09:24:54 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 15 Dec 2000 09:24:54 +0100 Subject: Spec file References: <3A3939EF.13CFA47E@vr1.com> Message-ID: <3A39D556.207B49B7@stroeder.com> Les Barstow wrote: > > I was wondering if someone could provide the SPEC file which was used to > compile the RPM for RedHat. I have a RedHat 6.2 SPARC box, but have an > interest in maintaining python-ldap as a package. > > I'd be happy to donate the SPARC RPM back to the development site. Have a look at what Mirko did so far: http://www.webideal.de/ldap/. He does not have the time to keep up with the new versions. > (PS - I'm not subscribed to the dev list; just an interested user...) Please subscribe. It's really low-traffic. Ciao, Michael. From sascha at free.de Wed Dec 13 09:29:09 2000 From: sascha at free.de (Sascha Gresk) Date: Wed, 13 Dec 2000 09:29:09 CET Subject: python-ldap-2.0 Message-ID: <200012130830.eBD8Ubu26873@lists.sourceforge.net> > > Before we all dive into it can you give a short description > of what you think the main advantages are? > + interface file is smaller and hopefully easier to maintain + data structures convert to objects in a convenient way + support for ruby, perl, guile wont be to different - limits hard core hacking of the interface - swig does not currently parse every conceivable type of C declaration See attachment for some more information. %Sascha -- /* Yeah */ -------------- next part -------------- A non-text attachment was scrubbed... Name: why-swig.txt Type: application/octet-stream Size: 2346 bytes Desc: not available URL: From michael at stroeder.com Sun Dec 17 15:02:46 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 17 Dec 2000 15:02:46 +0100 Subject: python-ldap-2.0 References: <20001212154927.B24099@mediasupervision.de> <20001217113016.A728@53b.hoffleit.de> Message-ID: <3A3CC786.62801893@stroeder.com> Gregor Hoffleit wrote: > > IIRC, quite a few services inside Debian are using python-ldap > (http://db.debian.org/), e.g. for maintenance of the maintainer > database. I'm not sure which sorts of code are involved there, > and if they were ready > to switch to Python 2.0, but if I would prefer to provide them with a > python-ldap package which works on both 2.0 as well as 1.5.2. I think the old python-ldap package will still exist and bugfixed => the old applications have a properly working module to run with. BTW: This module also works with Python 2.0 => no problem for http://db.debian.org/ at all. > But if that's not feasible, I can simply split the package > and stick with the old legacy code as python-ldap for 1.5.2 > and provide the new code as python2-ldap. Yes, I would prefer that everyone considers the new python-ldap-2.0 (or python-ldap-ext?) to be a completely separate package. Ciao, Michael. From gregor at hoffleit.de Sun Dec 17 11:30:16 2000 From: gregor at hoffleit.de (Gregor Hoffleit) Date: Sun, 17 Dec 2000 11:30:16 +0100 Subject: python-ldap-2.0 In-Reply-To: ; from david.leonard@csee.uq.edu.au on Sat, Dec 16, 2000 at 07:05:53PM +1000 References: <20001212154927.B24099@mediasupervision.de> Message-ID: <20001217113016.A728@53b.hoffleit.de> On Sat, Dec 16, 2000 at 07:05:53PM +1000, David Leonard wrote: > On Tue, 12 Dec 2000, Gregor Hoffleit typed thusly: > > When you write 'Python 2.0 support' and 'free of legacy support', does this > > mean that this new version won't work anymore with Python 1.5.2 ? > > yes... is that a problem? No fatal problem, just a sort of inconvenience: It's a longer story... Due to the GPL problems with the new Python license, Debian will provide and maintain both Python 1.5.2 and Python 2.0 packages. It's on the maintainer of a package depending on Python to decide if the license of his package allows to be used with Python 2.0, or if he has to stick with Python 1.5.2 if he doesn't want to infringe the license. Users of third-party Python code will have to make the same decision. IIRC, quite a few services inside Debian are using python-ldap (http://db.debian.org/), e.g. for maintenance of the maintainer database. I'm not sure which sorts of code are involved there, and if they were ready to switch to Python 2.0, but if I would prefer to provide them with a python-ldap package which works on both 2.0 as well as 1.5.2. But if that's not feasible, I can simply split the package and stick with the old legacy code as python-ldap for 1.5.2 and provide the new code as python2-ldap. Gregor From michael at stroeder.com Tue Dec 19 08:31:22 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 19 Dec 2000 08:31:22 +0100 Subject: python-ldap-2.0 References: Message-ID: <3A3F0ECA.BAAC7F78@stroeder.com> David Margrave wrote: > > What would be cool is if python-ldap could not only accept unicode > strings, but also automatically apply the language tag when > creating or modifying attributes (i.e. cn;lang-de). I don't think that the C module should do high-level operations like this. I can imagine that it's worth to write a Python class for it - contributions and detailed suggestions welcome. But let's stick to things found in OpenLDAP 2.0's ldap.h first. > Also, I haven't seen any discussion of SSL support. I for one would > like > the module to be able to do an SSL handshake to port 636 (or whatever it > is) to protect the credentials when simple auth is being used. OpenLDAP 2 has support for LDAP via SSL (URL scheme ldaps:// -> port 636) and LDAP with STARTTLS. > It would also be cool to get the Kerberos V5 GSS-API SASL mechanism > going. OpenLDAP supports SASL (not only Kerberos) if build with the Cyrus SASL lib. > I'm interested in doing the work to add these features. Great! Please take a closer look at OpenLDAP 2.0.x. Ciao, Michael. From davidma at eskimo.com Tue Dec 19 02:41:47 2000 From: davidma at eskimo.com (David Margrave) Date: Mon, 18 Dec 2000 17:41:47 -0800 (PST) Subject: python-ldap-2.0 In-Reply-To: Message-ID: Hello, I haven't been following the list too closely, so forgive me if some of this has already been discussed. I think unicode support is a great thing to add. I have already played with language tags a bit, but still being on python 1.5.2 for the most part, haven't had a convenient way to do the unicode conversions. What would be cool is if python-ldap could not only accept unicode strings, but also automatically apply the language tag when creating or modifying attributes (i.e. cn;lang-de). Of course, I can also imagine situations where you wouldn't want the module making assumptions like this. Also, I haven't seen any discussion of SSL support. I for one would like the module to be able to do an SSL handshake to port 636 (or whatever it is) to protect the credentials when simple auth is being used. I have to admit I haven't looked into whether open LDAP supports this, or whether it is something that would have to be cobbled in. If open LDAP doesn't have this, and doesn't provide for socket callbacks, then it could be tricky. It would also be cool to get the Kerberos V5 GSS-API SASL mechanism going. I'm interested in doing the work to add these features. Dave On Sun, 10 Dec 2000, David Leonard wrote: > On Sun, 10 Dec 2000, Michael Str?der typed thusly: > > I think we should leave the 1.x stuff as is and start with > > python-ldap-ext based on OpenLDAP 2.0.x... > > Okay, to keep everyone on the list informed: > > Michael, as a knowledgable Karlsruhe local, showed me all the local > restaurants that have closed down and then we discussed the direction for > python-ldap. After a few drinks, and a discussion on cats, we agreed on > the following plan: > > * python-ldap-1.10 will be tidied up, with just the memory-leak > patches applied, and a proper documentation build. (ie no v3 > changes will be applied as it breaks v2 builds.) A final release > will be made. > > * A new python-ldap-2.0 will be started, with an API that is likely > to be somewhat incompatible with that of p-l-1.10. In particular, > the following will be the major compatibility targets: > + Python-2.0 support (ie unicode) > + OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT) > > This means that people relying on v2 client/servers should be happy enough > with a reasonably stable release. And people wanting to live in the 3rd > millenium should be happy with a version (relatively) free of legacy support. > > Please, comment! Are there problems with the above plan? > > In addition, I seek more comment on any more changes that the _ldap library > may need to support LDAPv3 connections. (Remember that the purpose of this > module is not to give an abstraction of X.500 directory services, but rather > to provide an abstraction of the LDAP C API.) > > d > -- > David Leonard David.Leonard at dstc.edu.au > DSTC Room:78-632 Ph:+61 7 336 58358 > The University of Queensland http://www.dstc.edu.au/ > QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 > > I put my chin on my knee, and looked for flaws in the soft grain of my > beige plastic monitor casing. - Julian Assange > > From david.leonard at csee.uq.edu.au Tue Dec 19 03:06:37 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Tue, 19 Dec 2000 12:06:37 +1000 (EST) Subject: python-ldap-2.0 In-Reply-To: Message-ID: On Mon, 18 Dec 2000, David Margrave typed thusly: > Also, I haven't seen any discussion of SSL support. yes this is an important thing. i'm hoping that it will be more or less transparent to the api user. perhaps it will be done by just by providing set/get/check-certiciate hooks to the user like the python socket module does for those who really care :) > It would also be cool to get the Kerberos V5 GSS-API SASL mechanism going. I'm not overly familiar with this, i'm afraid -- David Leonard David.Leonard at dstc.edu.au CRC For Distributed Systems Technology Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Cassette tapes have an almost unlimited capacity for data. - Commodore 64 Programmer's Reference Guide (1983) From david.leonard at csee.uq.edu.au Sat Dec 16 10:00:32 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Sat, 16 Dec 2000 19:00:32 +1000 (EST) Subject: Spec file In-Reply-To: <3A39D556.207B49B7@stroeder.com> Message-ID: just a quick note on future packaging: python1.6 and above come with a distribution/packaging system ... which can build RPMs, etc. (or, so i have finally discoverred in the python documentation) so... Begone! disparate and out-of-date packaging systems! :) what i mean to say is that things will get better... i promise.. real soon now... no new taxes On Fri, 15 Dec 2000, Michael Str?der typed thusly: > > I was wondering if someone could provide the SPEC file which was used to > > compile the RPM for RedHat. I have a RedHat 6.2 SPARC box, but have an > > interest in maintaining python-ldap as a package. > > > > I'd be happy to donate the SPARC RPM back to the development site. > > Have a look at what Mirko did so far: http://www.webideal.de/ldap/. > He does not have the time to keep up with the new versions. > > > (PS - I'm not subscribed to the dev list; just an interested user...) > > Please subscribe. It's really low-traffic. -- David Leonard David.Leonard at dstc.edu.au CRC For Distributed Systems Technology Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Cassette tapes have an almost unlimited capacity for data. - Commodore 64 Programmer's Reference Guide (1983) From Jason.Tishler at dothill.com Wed Dec 27 15:37:50 2000 From: Jason.Tishler at dothill.com (Jason Tishler) Date: Wed, 27 Dec 2000 09:37:50 -0500 Subject: Cygwin Patch In-Reply-To: <3A3637AD.4C5977FD@stroeder.com>; from michael@stroeder.com on Tue, Dec 12, 2000 at 03:35:25PM +0100 References: <3A3637AD.4C5977FD@stroeder.com> Message-ID: <20001227093750.A251@dothill.com> On Sun, 10 Dec 2000 23:27:49 +0100, David Leonard wrote: > * python-ldap-1.10 will be tidied up, with just the memory-leak > patches applied, and a proper documentation build. (ie no v3 > changes will be applied as it breaks v2 builds.) A final release > will be made. Hopefully, the attached patch (against python-ldap-1.10alpha3) can still be considered for inclusion in the 1.10 final release. It enables python-ldap to build OOTB as a shared extension for Cygwin Python. Cygwin is an open-source POSIX emulation layer that enables many GNU and UNIX tools to port to Windows without any source code changes. If interested, please see http://www.cygwin.com for more information. Note that the patch has no functional changes -- it only enables the code to compile cleanly with Cygwin gcc. Specifically, the changes are as follows: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() I'm quite willing to redo the patch against python-ldap CVS if that will facilitate its acceptance. My original plan was to wait until the Cygwin Python DLL and Shared Extension Patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 was accepted and committed into Python CVS before contacting the list. However, due to the impending 1.10 final release, I realized that it would be prudent to submit the patch sooner rather than later. The procedure to apply the patch (to python-ldap-1.10alpha3) is as follows: $ cd python-ldap-1.10alpha3 $ # save the attachment to the current directory $ patch -p1 ; from michael@stroeder.com on Wed, Dec 27, 2000 at 04:50:21PM +0100 References: <3A3637AD.4C5977FD@stroeder.com> <20001227093750.A251@dothill.com> <3A4A0FBD.F8AD441C@stroeder.com> Message-ID: <20001227130915.A254@dothill.com> Michael, On Wed, Dec 27, 2000 at 04:50:21PM +0100, Michael Str?der wrote: > Jason Tishler wrote: > > > > python-ldap to build OOTB as a shared extension for Cygwin Python. > > Which leads to the question whether you can provide pre-compiled > Win32 binaries of python-ldap for download. I was going to offer to provide pre-built binaries in my previous email, but I thought that it would be considered presumptuous without waiting to see if the patch would be accepted. There are also other issues regarding the usefulness of the pre-built binary: 1. Cygwin python-ldap is *not* a Mingw (i.e., straight Win32) binary and requires Cygwin's cygwin1.dll to run 2. Cygwin python-ldap requires Cygwin Python to be built with a DLL core (similar to Win32 Python) Additionally, I was hoping to store the pre-built binary on http://python-ldap.sourceforge.net/release.php since my public web space is currently very limited. Nevertheless, I can provide the following packages that are installable with Cygwin's setup.exe: python-ldap-1.10alpha3-1.tar.gz: Cygwin python-ldap python-20001116-1.tar.gz: Cygwin Python 2.0 with DLL core openldap-1.2.11-1.tar.gz: Cygwin OpenLDAP 1.2.11 clients and libs Only the first one above is required. The other two are offered for convenience only -- it makes more sense for them to be contributed to the Cygwin project instead. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler at dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com