From michael at stroeder.com Mon Jul 9 17:03:42 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 09 Jul 2001 17:03:42 +0200 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> Message-ID: <3B49C7CE.D36A2164@stroeder.com> Konstantin, nice to see you're back on list. Konstantin Chuguev wrote: > > I seem to have missed some changes in python-ldap that made it > incompatible with OpenLDAPv1. Sorry, my fault probably related to a system upgrade. IMHO SuSE changed something with the libs they're shipping and I had to explicitly use -lresolv to solve my local build problem. See http://python-ldap.sourceforge.net/faq.shtml, item 5. David was working to incorporate your patches but did not commit anything so far. The diffs based on your work he sent me does not seem to work with recent OpenLDAP 2.0.11. It seems to me that the OpenLDAP 2 API is still subject to minor changes (e.g. ldap_set_rebind_proc()). Unfortunately David is not available to work on this stuff for the next months. Ciao, Michael. From Konstantin.Chuguev at dante.org.uk Mon Jul 9 15:50:42 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Mon, 09 Jul 2001 14:50:42 +0100 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> Message-ID: <3B49B6B2.517691E6@dante.org.uk> Hi All, Sorry, I've been doing completely different things last few months. I could read the mailings from the list, but couldn't react. I re-started my work on python-ldap patches in June, just few days before I went on holiday... Now I'm back. I seem to have missed some changes in python-ldap that made it incompatible with OpenLDAPv1. I'm not quite sure about it. Am I right? My patches (made against about a half year old CVSed python-ldap and CVSed between v2.0.6 and 2.0.7 OpenLDAPv2) are not included into the current python-ldap CVS, so I know it's not them that broke OpenLDAPv1 compatibility in CVS. If the patches do break compatibily when applied on their own, then well, blame myself for it, not python-ldap developers :-) Michael Str?der wrote: > David Leonard wrote: > > > > the current status of the development tree seems to be: > > * supporting OpenLDAP 2.* (but dropping support for earlier > > versions) > Is it possible to keep support for both branches of OpenLDAP? I understand Michael's concern about it. OpenLDAPv1 is still well developed version, it is used by many people who don't need v2 functionality. > > I have to say that I'm feeling *very* unhappy about the current > situation. I have absolutely no clue what to tell my users about how > to install python-ldap. > > - There's no proper stable release since months although the CVS > tree was pretty stable until a few weeks ago. I suggested to make a > release before tinkering with the CVS version several times... > > - Undocumented OpenLDAP 2.0.x-related patches are floating around > which actually break existing python-ldap applications. > I remember, one day I asked people if we could put the patches to CVS. I still don't see any harm if we had _partial_ OpenLDAPv2 support in the main branch, provided it doesn't break anything else. Partial, because there are some API differences, so often you just can't use same functions for same operations in OpenLDAPv1 and v2 cases (of course I mean the C API, but the current python-ldap implementation generally inherits it). We could even try to stick with a single python-ldap API, no matter whether it's build with OpenLDAPv1 or v2. But in this case the current python-ldap API should be changed. The examples are ldap_set_rebind_proc and SSL/TLS-related calls. But, in my area of interest (LDAPv3 referrals) API differences between OpenLDAPv1 and v2 are hidden from a python-ldap user. > > I'd really prefer a stable version which builds against OpenLDAP > 1.2.x, works rock-solid without memory leaks, do not core-dump and > behaves as documented instead of OpenLDAP 2.0.x-patched version > which break code and do not have any additional benefits. > Michael, if you are talking about my patches, I'd like to help. I made fresh versions of them (built against the latest CVS version of python-ldap and OpenLDAP-2.0.11. I tested them with the recent version of web2ldap. Referrals work like a charm! I haven't tested the patches against OpenLDAPv1, but I believe they shouldn't pose any problems. If anybody is interested to check them, I can post them to the mailing list. 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 From Konstantin.Chuguev at dante.org.uk Tue Jul 10 17:45:55 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Tue, 10 Jul 2001 16:45:55 +0100 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <000201c10927$2a80e770$0281640a@redeemer> Message-ID: <3B4B2333.BE4DC8FE@dante.org.uk> Hi David, David Leonard wrote: > this is good - commit it I doubt I can do that: I'm not a python-ldap developer... :-) > > will the documentation need updating? > I'll prepare another patch for python-ldap/Doc/libldap.tex. Regards, Konstantin. > > d > > ----- Original Message ----- > From: "Konstantin Chuguev" > To: > Cc: > Sent: Tuesday, July 10, 2001 6:59 PM > Subject: Re: compiling against OpenLDAP 2.0.11 > > > Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS > > repository require a new version of patches. I've attached them. > > The patches don't change the behaviour of python-ldap when compiled > > against OpenLDAPv1, but create an alternative code when used with > > OpenLDAPv2. Here are the differences between python-ldap compiled > > against OpenLDAPv1 and v2 using the patches (seen from the point of view > > of a programmer using python-ldap): > > > > * new constants added for v2 (see constants.c.patch); > > * new errors/exceptions added for v2 (see errors.c.patch); > > * a set of LDAP session attributes changed: > > o only in v1: lberoptions (rw), refhoplimit (rw), options (rw), > > valid (ro); > > o only in v2: version (rw), referrals (rw), restart (rw); > > o in both versions: deref (rw), timelimit (rw), sizelimit (rw), > > errno (ro), error (ro), matched (ro). > > * new type of data added to the Python dictionary returned as a > > result of ldap_result: > > Dictionary keys are DNs, values are entry objects. If the key is > > empty, the value is the list of referrals (URL text strings). -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW: http://www.dante.net From Konstantin.Chuguev at dante.org.uk Tue Jul 10 10:59:59 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Tue, 10 Jul 2001 09:59:59 +0100 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> Message-ID: <3B4AC40F.9142E153@dante.org.uk> Hi Michael, Michael Str?der wrote: > David was working to incorporate your patches but did not commit > anything so far. The diffs based on your work he sent me does not > seem to work with recent OpenLDAP 2.0.11. It seems to me that the Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS repository require a new version of patches. I've attached them. The patches don't change the behaviour of python-ldap when compiled against OpenLDAPv1, but create an alternative code when used with OpenLDAPv2. Here are the differences between python-ldap compiled against OpenLDAPv1 and v2 using the patches (seen from the point of view of a programmer using python-ldap): * new constants added for v2 (see constants.c.patch); * new errors/exceptions added for v2 (see errors.c.patch); * a set of LDAP session attributes changed: o only in v1: lberoptions (rw), refhoplimit (rw), options (rw), valid (ro); o only in v2: version (rw), referrals (rw), restart (rw); o in both versions: deref (rw), timelimit (rw), sizelimit (rw), errno (ro), error (ro), matched (ro). * new type of data added to the Python dictionary returned as a result of ldap_result: Dictionary keys are DNs, values are entry objects. If the key is empty, the value is the list of referrals (URL text strings). > > OpenLDAP 2 API is still subject to minor changes (e.g. > ldap_set_rebind_proc()). Unfortunately David is not available to I haven't touched set_rebind_proc in python-ldap yet, because that would change its API. At the moment you'll get a compile time warning and possible crash if you use rebind_proc with python-ldap + OpenLDAPv2. It is impossible to use the v1 set_rebind_proc syntax in v2. It is theoretically possible to use the OpenLDAPv2 syntax of the function with the OpenLDAPv1 library, using an internal conversion function. It would require some programming and (needs your approval) a change to the python-ldap API. Suggestions? 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 -------------- --- constants.c.orig Sat May 12 09:05:09 2001 +++ constants.c Mon Jun 11 11:05:12 2001 @@ -79,6 +79,27 @@ add_int(d,REQ_COMPARE); add_int(d,REQ_ABANDON); +#if LDAP_API_VERSION >= 2000 + /* 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_EXTENDED); +#endif +#if LDAP_API_VERSION >= 2004 + add_int(d,TAG_NEWSUPERIOR); + add_int(d,TAG_EXOP_REQ_OID); + add_int(d,TAG_EXOP_REQ_VALUE); + add_int(d,TAG_EXOP_RES_OID); + add_int(d,TAG_EXOP_RES_VALUE); + add_int(d,TAG_SASL_RES_CREDS); +#endif + /* reversibles */ zero = PyInt_FromLong( 0 ); @@ -95,6 +116,14 @@ add_int_r(d,RES_COMPARE); add_int(d,RES_ANY); +#if LDAP_API_VERSION >= 2000 + /* OpenLDAPv2 */ + add_int_r(d,RES_SEARCH_REFERENCE); + add_int_r(d,RES_EXTENDED); + add_int_r(d,RES_EXTENDED_PARTIAL); + add_int_r(d,RES_UNSOLICITED); +#endif + /* non-reversibles */ add_int(d,AUTH_NONE); @@ -121,6 +150,21 @@ add_int(d,MOD_DELETE); add_int(d,MOD_REPLACE); add_int(d,MOD_BVALUES); + +#if LDAP_API_VERSION >= 2000 + /* OpenLDAPv2 */ + add_int(d,FILTER_EXT); + add_int(d,FILTER_EXT_OID); + add_int(d,FILTER_EXT_TYPE); + add_int(d,FILTER_EXT_VALUE); + add_int(d,FILTER_EXT_DNATTRS); + + add_int(d,SCOPE_DEFAULT); + + add_int(d,MSG_ONE); + add_int(d,MSG_ALL); + add_int(d,MSG_RECEIVED); +#endif /* (errors.c contains the error constants) */ -------------- next part -------------- --- errors.c.orig Mon Aug 14 23:37:37 2000 +++ errors.c Tue Jun 5 11:43:59 2001 @@ -17,7 +17,12 @@ /* list of error objects */ +#if LDAP_API_VERSION >= 2000 + /* OpenLDAPv2 */ +#define NUM_LDAP_ERRORS LDAP_REFERRAL_LIMIT_EXCEEDED+1 +#else #define NUM_LDAP_ERRORS LDAP_NO_MEMORY+1 +#endif static PyObject* errobjects[ NUM_LDAP_ERRORS ]; @@ -30,21 +35,26 @@ PyErr_SetFromErrno( LDAPexception_class ); return NULL; } -#ifdef LDAP_TYPE_IS_OPAQUE +#if defined(LDAP_TYPE_IS_OPAQUE) && LDAP_API_VERSION < 2000 else { PyErr_SetString(LDAPexception_class, "unknown error (C API does not expose error)"); return NULL; } -#else +#else /* defined(LDAP_TYPE_IS_OPAQUE) && LDAP_API_VERSION < 2000 */ else { int errnum; PyObject *errobj; PyObject *info; PyObject *str; +#if LDAP_API_VERSION >= 2000 + 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 errobj = LDAPexception_class; /* unknown error XXX */ else errobj = errobjects[errnum]; @@ -61,6 +71,34 @@ PyDict_SetItemString( info, "desc", str ); Py_XDECREF(str); +#if LDAP_API_VERSION >= 2000 + 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 /* LDAP_API_VERSION >= 2000 */ if (l->ld_matched != NULL && *l->ld_matched != '\0') { str = PyString_FromString(l->ld_matched); @@ -76,11 +114,12 @@ PyDict_SetItemString( info, "info", str ); Py_XDECREF(str); } +#endif /* LDAP_API_VERSION >= 2000 */ PyErr_SetObject( errobj, info ); Py_DECREF(info); return NULL; } -#endif +#endif /* defined(LDAP_TYPE_IS_OPAQUE) && LDAP_API_VERSION < 2000 */ } @@ -163,4 +202,20 @@ seterrobj(USER_CANCELLED); seterrobj(PARAM_ERROR); seterrobj(NO_MEMORY); +#if LDAP_API_VERSION >= 2000 + /* OpenLDAPv2 */ + 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 Thu Jun 7 00:40:04 2001 +++ LDAPObject.c Mon Jun 11 10:57:59 2001 @@ -1211,9 +1211,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; @@ -1239,28 +1239,49 @@ return Py_None; } - /* thanks to Konstantin Chuguev for this */ - if (res_type != LDAP_RES_SEARCH_ENTRY) { + if (res_type == LDAP_RES_SEARCH_ENTRY +#if LDAP_API_VERSION >= 2000 + || res_type == LDAP_RES_SEARCH_REFERENCE +#endif + ) + pmsg = LDAPmessage_to_python( self->ldap, msg ); + else { + int result; +#if LDAP_API_VERSION >= 2000 + char **refs = NULL; + LDAP_BEGIN_ALLOW_THREADS( self ); + ldap_parse_result( self->ldap, msg, &result, NULL, NULL, &refs, NULL, 0 ); +#else LDAP_BEGIN_ALLOW_THREADS( self ); result = ldap_result2error( self->ldap, msg, 0 ); +#endif LDAP_END_ALLOW_THREADS( self ); if (result != LDAP_SUCCESS) { /* result error */ +#if LDAP_API_VERSION >= 2000 + char *e, 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"; + return LDAPerror( self->ldap, e ); +#else return LDAPerror( self->ldap, "ldap_result2error" ); +#endif } + 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; @@ -1451,6 +1472,9 @@ /* ldap_search_s == ldap_search_st */ +#if LDAP_API_VERSION < 2000 +/* OpenLDAPv1 */ + /* ldap_ufn_search_c */ /* ldap_ufn_search_ct */ @@ -1534,6 +1558,8 @@ "\tSee the LDAP library manual pages for more information on these\n" "\t`user-friendly name' functions."; +#endif /* LDAP_API_VERSION < 2000 */ + /* ldap_sort_entries */ /* ldap_url_search */ @@ -1631,7 +1657,7 @@ {"add_s", (PyCFunction)l_ldap_add_s, METH_VARARGS, doc_add}, {"bind", (PyCFunction)l_ldap_bind, METH_VARARGS, doc_bind}, {"bind_s", (PyCFunction)l_ldap_bind_s, METH_VARARGS, doc_bind}, -#ifdef LDAP_REFERRALS +#if defined(LDAP_REFERRALS) || LDAP_API_VERSION >= 2000 {"set_rebind_proc", (PyCFunction)l_ldap_set_rebind_proc, METH_VARARGS, doc_set_rebind_proc}, #endif /* LDAP_REFERRALS */ {"simple_bind", (PyCFunction)l_ldap_simple_bind, METH_VARARGS, doc_bind}, @@ -1688,9 +1714,11 @@ {"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 LDAP_API_VERSION < 2000 {"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) @@ -1766,6 +1794,47 @@ getattr( LDAPObject* self, char* name ) { +#if LDAP_API_VERSION >= 2000 +/* 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); @@ -1798,6 +1867,7 @@ return PyInt_FromLong(self->valid); return Py_FindMethod( methods, (PyObject*)self, name ); +#endif /* LDAP_API_VERSION >= 2000 */ } /* set attribute */ @@ -1805,7 +1875,12 @@ static int setattr( LDAPObject* self, char* name, PyObject* value ) { +#if LDAP_API_VERSION >= 2000 + int res, intval, option; + int *intptr = &intval; +#else long intval; +#endif if (streq(name,"errno") || streq(name,"error") || @@ -1821,6 +1896,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 ) \ @@ -1844,6 +1947,7 @@ /* it fell through to here */ PyErr_SetString( PyExc_NameError, "cannot set that field" ); return -1; +#endif /* LDAP_API_VERSION >= 2000 */ } /* type entry */ -------------- next part -------------- --- message.c.orig Fri Aug 18 01:21:46 2000 +++ message.c Tue Jun 5 09:59:29 2001 @@ -114,6 +114,40 @@ PyList_Append(result, entrytuple); Py_DECREF(entrytuple); } +#if LDAP_API_VERSION >= 2000 + 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 michael at stroeder.com Tue Jul 10 21:33:55 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 10 Jul 2001 21:33:55 +0200 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <000201c10927$2a80e770$0281640a@redeemer> <3B4B2333.BE4DC8FE@dante.org.uk> Message-ID: <3B4B58A3.27243E7@stroeder.com> Konstantin Chuguev wrote: > > David Leonard wrote: > > > this is good - commit it David, take care of your PhD-ing and please let me test Konstantin's patches first. ;-) > I doubt I can do that: I'm not a python-ldap developer... :-) Being a python-ldap developer can happen to come true faster than you think these days... ;-) Anyone did notice the forwarded warning message by Stig about possible memory leaks with OpenLDAP 2.0.x API? Please glance over it: http://www.geocrawler.com/archives/3/1568/2001/6/0/6036658/ > > will the documentation need updating? > > I'll prepare another patch for python-ldap/Doc/libldap.tex. Urrgs. I think I should at least publish a "python setup.py sdist" of recent snapshot to make a 1.11 distribution before the commits. Comments? Ciao, Michael. From michael at stroeder.com Wed Jul 11 11:56:27 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 11 Jul 2001 11:56:27 +0200 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <000201c10927$2a80e770$0281640a@redeemer> <3B4B2333.BE4DC8FE@dante.org.uk> <3B4B58A3.27243E7@stroeder.com> Message-ID: <3B4C22CB.CD6E5E8C@stroeder.com> Steffen, thanks a lot for your patches. Steffen Ries wrote: > > Michael Str?der writes: > > > Anyone did notice the forwarded warning message by Stig about > > possible memory leaks with OpenLDAP 2.0.x API? > > Please glance over it: > > http://www.geocrawler.com/archives/3/1568/2001/6/0/6036658/ > > I looked through it. > [..] > The attached patch should fix both issues. I tried to merge your patches with the patches provided by Konstantin but it seg faults with OpenLDAP 2.0.11 libs. Since your diff is not against recent CVS version there might be a problem with some small differences. E.g. there's a call "free(dn);" before "return NULL;" in recent CVS version of message.c which affects your first diff. Since I have no idea about the C sources I'd appreciate if you could take a look at the recent CVS version in which some memory leaks were fixed since python-ldap-1.10alpha3. Ciao, Michael. From michael at stroeder.com Wed Jul 11 11:29:20 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 11 Jul 2001 11:29:20 +0200 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> Message-ID: <3B4C1C70.73CCF0BB@stroeder.com> Konstantin Chuguev wrote: > > Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS > repository require a new version of patches. I've attached them. I tried these patches. They seem to work (LDAPv3 connects with recent web2ldap 0.9.x :-). But still there's the problem that LDAP URLs in referrals are not properly formatted. From some discussions on openldap-software I suspect the OpenLDAP 2 libs. Example: When searching ldap://ldap.surfnet.nl/c=BE?ou,mail,uid,telephoneNumber,labeledurl,cn,objectClass,displayName?one the OpenLDAP 2 lib returns the referral URL ldap://tor.dante.org.uk:1389?ou,mail,uid,telephoneNumber,labeledurl,cn,objectClass,displayName?one This LDAP URL does not contain a slash behind the hostport part. My LDAP URL parser (usually in nitpicking mode) expects a trailing slash after hostport (which might be empty) if there are any parameters after hostport. Glancing at RFC2255 seems to confirm this assumption: ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attributes] ["?" [scope] ["?" [filter] ["?" extensions]]]]]] I tried to raise this at the OpenLDAP 2 libs but it was rather ignored since I could not provide a detailed example. I could only provide a python-ldap example there but surely Kurt would have pointed me back to bugs in python-ldap. Anybody willing to write a short C source example confirming this possible bug? Search something which returns a referral LDAP URL and look at the LDAP URL returned (switch off automatic referral chasing). > The patches don't change the behaviour of python-ldap when compiled > against OpenLDAPv1, but create an alternative code when used with > OpenLDAPv2. That's great! > Here are the differences between python-ldap compiled > [..] > * new type of data added to the Python dictionary returned as a > result of ldap_result: > Dictionary keys are DNs, values are entry objects. If the key is > empty, the value is the list of referrals (URL text strings). I completely forgot what we've defined in November but web2ldap seems to display the search continuations nicely. ;-) E.g. ldap://ldap.nameflow.net:1389/c%3DFI??base?%28objectclass%3D%2A%29 shows Referral => ldap://193.166.0.77:389/dmdName=FunetDir,%20c=FI??base in search result table. Sorry Konstantin, the on-line demo at http://sites.inka.de:8002/web2ldap is still running with python-ldap built against OpenLDAP 1.2.x. You have to install web2ldap locally to do the testing. Make sure to look at the output of the ConnInfo button to confirm that it says "LDAPv3 connection to:". Ciao, Michael. From steffen.ries at sympatico.ca Wed Jul 11 02:32:07 2001 From: steffen.ries at sympatico.ca (Steffen Ries) Date: 10 Jul 2001 20:32:07 -0400 Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: Michael =?iso-8859-1?q?Str=F6der's?= message of "Tue, 10 Jul 2001 21:33:55 +0200" References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <000201c10927$2a80e770$0281640a@redeemer> <3B4B2333.BE4DC8FE@dante.org.uk> <3B4B58A3.27243E7@stroeder.com> Message-ID: Michael Str?der writes: > Anyone did notice the forwarded warning message by Stig about > possible memory leaks with OpenLDAP 2.0.x API? > Please glance over it: > http://www.geocrawler.com/archives/3/1568/2001/6/0/6036658/ I looked through it. The first issue (ldap_first_attribute) has changed from OpenLDAP 1.2 to 2.0.x so that the memory is *never* freed by the library. In 1.1 it was freed, when the last attribute was read. However, the current python-ldap code did never free the memory. IOW, there is a possible memory leak in error cases. The second issue (ldap_get_dn) has *not* changed between OpenLDAP 1.2 and 2.0.x, i.e. the same kind of memory leak exists for both API versions. The attached patch should fix both issues. The last "ber_free()" should be surrounded by some #ifdef OPENLDAP_2_0_X conditional... I scanned through the documentation and did not notice any further changes in memory handling, but then again, I did not really look too hard. *** python-ldap-1.10alpha3/Modules/message.c Mon Aug 14 18:37:37 2000 --- python-ldap-openldap-2/Modules/message.c Mon Jul 2 10:55:30 2001 *************** *** 78,84 **** --- 78,86 ---- if (valuelist == NULL) { Py_DECREF(attrdict); Py_DECREF(result); + ber_free(ber, 0); ldap_msgfree( m ); + ldap_memfree(attr); return NULL; } *************** *** 95,101 **** --- 97,105 ---- Py_DECREF(result); Py_DECREF(valuestr); Py_DECREF(valuelist); + ber_free(ber, 0); ldap_msgfree( m ); + ldap_memfree(attr); return NULL; } Py_DECREF(valuestr); *************** *** 103,114 **** --- 107,121 ---- ldap_value_free_len(bvals); } Py_DECREF( valuelist ); + ldap_memfree(attr); } entrytuple = Py_BuildValue("(sO)", dn, attrdict); + ldap_memfree(dn); Py_DECREF(attrdict); PyList_Append(result, entrytuple); Py_DECREF(entrytuple); + ber_free(ber, 0); } ldap_msgfree( m ); return result; /steffen -- steffen.ries at sympatico.ca <> Gravity is a myth -- the Earth sucks! From michael at stroeder.com Wed Jul 11 13:26:07 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 11 Jul 2001 13:26:07 +0200 Subject: Subtle changes in error handling with OpenLDAP 2 (was: compiling against OpenLDAP 2.0.11) References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <3B4C1C70.73CCF0BB@stroeder.com> Message-ID: <3B4C37CF.AFC69C31@stroeder.com> Michael Str?der wrote: > > Konstantin Chuguev wrote: > > > > Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS > > repository require a new version of patches. I've attached them. > > I tried these patches. They seem to work I noticed another subtle change in the OpenLDAP 2 behaviour: When adding an attribute to an entry which is unknown to the server (schema violation) there's just the base expection class ldap.LDAPError returned containing message ("Undefined attribute type..."). This makes it impossible to specifically catch e.g. ldap.OBJECT_CLASS_VIOLATION. (web2ldap makes extensive use of catching ldap.OBJECT_CLASS_VIOLATION, ldap.NAMING_VIOLATION and friends to enable the user to re-edit the input etc.) I experienced similar behaviour with exceptions raised in case of referrals received. The ldap.LDAPError base class was raised with OpenLDAP 2.0.x lib instead of e.g. ldap.PARTIAL_RESULTS raised in case of OpenLDAP 1.2.x lib. I thought that in this special case it has to do with the migration from LDAPv2+ pseudo referrals to real LDAPv3 knowledge references. Not sure about this issue though. (web2ldap 0.9.x already contains code to handle both cases but I'd like to get rid of that bloat in the future.) It seems that the whole exception-based error catching needs to be tested thoroughly because there are probably other subtle changes in the OpenLDAP 2 libs as well. Ciao, Michael. From michael at stroeder.com Wed Jul 11 18:22:01 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 11 Jul 2001 18:22:01 +0200 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <3B4C1C70.73CCF0BB@stroeder.com> Message-ID: <3B4C7D29.ADC1C709@stroeder.com> Michael Str?der wrote: > > Konstantin Chuguev wrote: > > > > Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS > > repository require a new version of patches. I've attached them. > > I tried these patches. BTW: I see a lot of hex dump output (ber_dump) to stdin when using these patches to python-ldap. Can I influence the debugging level anywhere? Ciao, Michael. From michael at stroeder.com Thu Jul 12 02:06:14 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 12 Jul 2001 02:06:14 +0200 Subject: Subtle changes in error handling with OpenLDAP 2 (was: compiling against OpenLDAP 2.0.11) References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <3B4C1C70.73CCF0BB@stroeder.com> <3B4C37CF.AFC69C31@stroeder.com> Message-ID: <3B4CE9F6.9DAAD1E3@stroeder.com> Michael Str?der wrote: > > The ldap.LDAPError base class was raised with > OpenLDAP 2.0.x lib instead of e.g. ldap.PARTIAL_RESULTS raised in > case of OpenLDAP 1.2.x lib. Discovered exception class ldap.REFERRAL introduced with LDAPv3 by looking at ldap.h of OpenLDAP 2 and errors.c... Ciao, Michael. From michael at stroeder.com Thu Jul 12 11:38:49 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 12 Jul 2001 11:38:49 +0200 Subject: More memory freeing patches to message.c Message-ID: <3B4D7029.967E2259@stroeder.com> HI! Following some more advice by Stig Venaas (see message below) I've ifdef'ed some memory freeing calls provided by Steffen in message.c to keep the source compatible to OpenLDAP 1.2.x libs. I've attached my recent message.c. Backwards compability is not assumed to be crucial in the long run but seems nice if we can achieve it with fairly low efforts. Ciao, Michael. -------- Original Message -------- Subject: Re: python-ldap and OpenLDAP 2 Date: Thu, 12 Jul 2001 10:47:35 +0200 From: Stig Venaas To: Michael Str?der References: <3B4382DD.C9B6A780 at stroeder.com> <20010711184821.A6433 at sverresborg.uninett.no> <3B4C94B9.5885D132 at stroeder.com> <20010712090618.A7043 at sverresborg.uninett.no> <3B4D525B.47107DC7 at stroeder.com> On Thu, Jul 12, 2001 at 09:31:39AM +0200, Michael Str?der wrote: > Stig Venaas wrote: > > > > These memory leaks was also reported and discussed > > in the OpenLDAP ITS system a few days ago. Someone reported memory > > leaks and Kurt and I responded. See > > http://www.OpenLDAP.org/lists/openldap-bugs/200107/msg00018.html > > for my respons. > > According to this and Steffen's message the ldap_memfree(attr) and > ber_free(ber, 0) should be ifdef'ed. What about the free(dn) call? > > Well, we have no problems dropping support for linking against > OpenLDAP 1.x completely if we will have a really stable version and > it's clear that we can achieve all goals on this track. PHP supports OpenLDAP 1.x and others that use the RFC1823 API, as well as Netscape SDK and OpenLDAP 2.x and others that use the new API. The same should be possible for Python. I think I've found a bug in PHP when using old API and ldap_get_dn(). It's not freed! I've never tested much with old API. The PHP code looks like this: #if ( LDAP_API_VERSION > 2000 ) || HAVE_NSLDAP || WINDOWS ldap_memfree(dn); #endif For Python you could use: #if ( LDAP_API_VERSION > 2000 ) ldap_memfree(dn); #else free(dn); #endif ldap_memfree() is currently the same as free() but it should be done this way anyway. Regarding the other leaks, you can use code like: #if ( LDAP_API_VERSION > 2000 ) ldap_memfree(attribute); #endif and #if ( LDAP_API_VERSION > 2000 ) if (ber != NULL) ber_free(ber, 0); #endif This way it should work with both old and new APIs. > I have changed the calls to free() to ldap_memfree(), which means > the > code will compile only against OpenLDAP 2.0.x, since 1.2 does not > define ldap_memfree(). Hence the trick above. Stig -------------- next part -------------- /* David Leonard , 1999. Public domain. */ /* * LDAPMessageObject - wrapper around an LDAPMessage* * $Id: message.c,v 1.6 2000/08/18 00:21:46 leonard Exp $ */ #include "common.h" #include "message.h" #include "errors.h" #include "CIDict.h" PyObject* LDAPmessage_to_python( LDAP*ld, LDAPMessage*m ) { /* we convert an LDAP message into a python structure. * It is always a list of dictionaries. * We always free m. */ PyObject* result; LDAPMessage* entry; result = PyList_New(0); if (result == NULL) { ldap_msgfree( m ); return NULL; } for(entry = ldap_first_entry(ld,m); entry != NULL; entry = ldap_next_entry(ld,entry)) { char *dn; char *attr; BerElement *ber = NULL; PyObject* entrytuple; PyObject* attrdict; dn = ldap_get_dn( ld, entry ); if (dn == NULL) { Py_DECREF(result); ldap_msgfree( m ); return LDAPerror( ld, "ldap_get_dn" ); } #ifdef USE_CIDICT attrdict = CIDict_New(); #else /* use standard python dictionary */ attrdict = PyDict_New(); #endif /* !CIDICT */ if (attrdict == NULL) { Py_DECREF(result); ldap_msgfree( m ); #if LDAP_API_VERSION >= 2000 ldap_memfree(dn); #else free(dn); #endif return NULL; } /* Fill attrdict with lists */ for( attr = ldap_first_attribute( ld, entry, &ber ); attr != NULL; attr = ldap_next_attribute( ld, entry, ber ) ) { PyObject* valuelist; struct berval ** bvals = ldap_get_values_len( ld, entry, attr ); /* Find which list to append to */ if ( PyMapping_HasKeyString( attrdict, attr ) ) { valuelist = PyMapping_GetItemString( attrdict, attr ); } else { valuelist = PyList_New(0); if (valuelist != NULL && PyMapping_SetItemString(attrdict, attr, valuelist) == -1) { Py_DECREF(valuelist); valuelist = NULL; /* catch error later */ } } if (valuelist == NULL) { Py_DECREF(attrdict); Py_DECREF(result); #if ( LDAP_API_VERSION > 2000 ) if (ber != NULL) ber_free(ber, 0); #endif ldap_msgfree( m ); #if LDAP_API_VERSION >= 2000 ldap_memfree(attr); ldap_memfree(dn); #else free(dn); #endif return NULL; } if (bvals != NULL) { int i; for (i=0; bvals[i]; i++) { PyObject *valuestr; valuestr = PyString_FromStringAndSize( bvals[i]->bv_val, bvals[i]->bv_len ); if (PyList_Append( valuelist, valuestr ) == -1) { Py_DECREF(attrdict); Py_DECREF(result); Py_DECREF(valuestr); Py_DECREF(valuelist); ldap_msgfree( m ); #if LDAP_API_VERSION >= 2000 ldap_memfree(attr); ldap_memfree(dn); #else free(dn); #endif return NULL; } Py_DECREF(valuestr); } ldap_value_free_len(bvals); } Py_DECREF( valuelist ); #if LDAP_API_VERSION >= 2000 ldap_memfree(attr); #endif } entrytuple = Py_BuildValue("(sO)", dn, attrdict); #if LDAP_API_VERSION >= 2000 ldap_memfree(dn); #else free(dn); #endif Py_DECREF(attrdict); PyList_Append(result, entrytuple); Py_DECREF(entrytuple); #if ( LDAP_API_VERSION > 2000 ) if (ber != NULL) ber_free(ber, 0); #endif } #if LDAP_API_VERSION >= 2000 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 Konstantin.Chuguev at dante.org.uk Thu Jul 12 11:22:06 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Thu, 12 Jul 2001 10:22:06 +0100 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <000201c10927$2a80e770$0281640a@redeemer> <3B4B2333.BE4DC8FE@dante.org.uk> <3B4B58A3.27243E7@stroeder.com> Message-ID: <3B4D6C3E.1821960D@dante.org.uk> Michael Str?der wrote: > David, take care of your PhD-ing and please let me test Konstantin's > patches first. ;-) > Agree, I'm also going to test them, although just in a few configurations... > > I'll prepare another patch for python-ldap/Doc/libldap.tex. > > Urrgs. I think I should at least publish a "python setup.py sdist" > of recent snapshot to make a 1.11 distribution before the commits. > Comments? > As I can see, the current version from CVS hasn't got new features for a long time, just bug fixes. So, it's a good candidate for a release. After that, we could add OpenLDAPv2 functionality to the currnet branch of the repository. 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 From Konstantin.Chuguev at dante.org.uk Thu Jul 12 11:31:53 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Thu, 12 Jul 2001 10:31:53 +0100 Subject: compiling against OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <000201c10927$2a80e770$0281640a@redeemer> <3B4B2333.BE4DC8FE@dante.org.uk> <3B4B58A3.27243E7@stroeder.com> Message-ID: <3B4D6E89.E7A61E7D@dante.org.uk> Hi Steffen, Steffen Ries wrote: > Michael Str?der writes: > > > Anyone did notice the forwarded warning message by Stig about > > possible memory leaks with OpenLDAP 2.0.x API? > > Please glance over it: > > http://www.geocrawler.com/archives/3/1568/2001/6/0/6036658/ > > I looked through it. > > The first issue (ldap_first_attribute) has changed from OpenLDAP 1.2 > to 2.0.x so that the memory is *never* freed by the library. In 1.1 it > was freed, when the last attribute was read. However, the current > python-ldap code did never free the memory. IOW, there is a possible > memory leak in error cases. > > The second issue (ldap_get_dn) has *not* changed between OpenLDAP 1.2 > and 2.0.x, i.e. the same kind of memory leak exists for both API > versions. > If we are going to release the latest snapshot without OpenLDAPv2 support (which I think is a good idea), we would still like to eliminate any memory leaks :-) In that case, could you please update your patch to do The Right Thing (TM) for OpenLDAPv1 only? If you don't have enough time, I could do it myself. I'd just like to get a hint in this case: is it only message.c that needs to be patched? > > The attached patch should fix both issues. The last "ber_free()" > should be surrounded by some #ifdef OPENLDAP_2_0_X conditional... > > I scanned through the documentation and did not notice any further > changes in memory handling, but then again, I did not really look too > hard. > After that, I would add memory leak fixes to my OpenLDAPv2 patches. 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 From steffen.ries at sympatico.ca Thu Jul 12 13:36:40 2001 From: steffen.ries at sympatico.ca (Steffen Ries) Date: 12 Jul 2001 07:36:40 -0400 Subject: More memory freeing patches to message.c In-Reply-To: Michael =?iso-8859-1?q?Str=F6der's?= message of "Thu, 12 Jul 2001 11:38:49 +0200" References: <3B4D7029.967E2259@stroeder.com> Message-ID: Michael Str?der writes: > HI! > > Following some more advice by Stig Venaas (see message below) I've > ifdef'ed some memory freeing calls provided by Steffen in message.c > to keep the source compatible to OpenLDAP 1.2.x libs. I've attached > my recent message.c. > > Backwards compability is not assumed to be crucial in the long run > but seems nice if we can achieve it with fairly low efforts. We need two changes to this version of 'message.c': "ber_free(ber, 0)" needs to be called for API version 1.2.x too, *except* when the ldap_next_attribute() has returned NULL. See the complete patch against CVS below. Looks like we are closing in now... :-) /steffen Index: message.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/message.c,v retrieving revision 1.6 diff -u -w -r1.6 message.c --- message.c 2000/08/18 00:21:46 1.6 +++ message.c 2001/07/12 11:31:00 @@ -51,7 +51,11 @@ if (attrdict == NULL) { Py_DECREF(result); ldap_msgfree( m ); +#if LDAP_API_VERSION >= 2000 + ldap_memfree(dn); +#else free(dn); +#endif return NULL; } @@ -79,8 +83,15 @@ if (valuelist == NULL) { Py_DECREF(attrdict); Py_DECREF(result); + if (ber != NULL) + ber_free(ber, 0); ldap_msgfree( m ); +#if LDAP_API_VERSION >= 2000 + ldap_memfree(attr); + ldap_memfree(dn); +#else free(dn); +#endif return NULL; } @@ -97,8 +108,15 @@ Py_DECREF(result); Py_DECREF(valuestr); Py_DECREF(valuelist); + if (ber != NULL) + ber_free(ber, 0); ldap_msgfree( m ); +#if LDAP_API_VERSION >= 2000 + ldap_memfree(attr); + ldap_memfree(dn); +#else free(dn); +#endif return NULL; } Py_DECREF(valuestr); @@ -106,14 +124,59 @@ ldap_value_free_len(bvals); } Py_DECREF( valuelist ); +#if LDAP_API_VERSION >= 2000 + ldap_memfree(attr); +#endif } entrytuple = Py_BuildValue("(sO)", dn, attrdict); +#if LDAP_API_VERSION >= 2000 + ldap_memfree(dn); +#else free(dn); +#endif Py_DECREF(attrdict); PyList_Append(result, entrytuple); Py_DECREF(entrytuple); +#if ( LDAP_API_VERSION > 2000 ) + if (ber != NULL) + ber_free(ber, 0); +#endif + } +#if LDAP_API_VERSION >= 2000 + 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; } -- steffen.ries at sympatico.ca <> Gravity is a myth -- the Earth sucks! From michael at stroeder.com Fri Jul 13 02:11:01 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 13 Jul 2001 02:11:01 +0200 Subject: Tagging the CVS archive Message-ID: <3B4E3C95.D6490DF6@stroeder.com> HI! Could we find some meaningful set of tags to mark the python-ldap CVS archive? Maybe we can borrow some ideas from http://www.openldap.org/software/repo.html ? I'd like to check in the new OpenLDAP 2-related patches and memory leak fixes since I spent some time sending patch mails around. But before that I'd like to mark the current CVS version with PYTHONLDAP_REL_ENG_1_2 or something alike. Not being a CVS expert though... :-/ Ciao, Michael. From michael at stroeder.com Fri Jul 13 17:37:09 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 13 Jul 2001 17:37:09 +0200 Subject: Module package ldaputil Message-ID: <3B4F15A5.8529E7C3@stroeder.com> HI! I'd like to contribute some stuff to python-ldap I've implemented for web2ldap after having it cleaned up. Find attached a small module package containing two sub-modules. These modules need Python 2.0+ (e.g. for Unicode support). passwd Class implementing client-side password setting for various syntaxes. unicodePwd not yet implemented. ldapurl Class for LDAP URL handling. Off course both modules needs testing! More to come in the future. I'd appreciate if some feedback would come from the list members. - How to stuff that into python-ldap - the APIs are ok? - Licensing issues (also concering python-ldap in general) Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: ldaputil-20010713.tar.gz Type: application/x-gzip Size: 7452 bytes Desc: not available URL: From michael at stroeder.com Sun Jul 15 01:19:35 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 15 Jul 2001 01:19:35 +0200 Subject: OpenLDAP 2.0.x's libldap_r Message-ID: <3B50D387.FFC34520@stroeder.com> HI! While we're at it: One thing which might bite other python-ldap developers as well is that the OpenLDAP libs are not reentrant. Despite the ugly hack with my wrapper module ldapthreadlock the problem is still not really solved. The message from Kurt Zeilenga (attached below) made me curious. Unfortunately Kurt refused to be more verbose on that. Could anybody look into this? One idea might be to wrap the lower-level function calls of libldap_r and write a Python wrapper module above it which takes care about how libldap_r has to be used. Ciao, Michael. -------- Original Message -------- Subject: Re: OpenLDAP libs thread-safe? Date: Fri, 13 Apr 2001 09:57:05 -0700 From: "Kurt D. Zeilenga" To: michael at stroeder.com CC: openldap-software References: <5.0.2.1.0.20010413085505.00a97600 at 127.0.0.1> At 06:43 PM 4/13/01 +0200, Michael Str?der wrote: >"Kurt D. Zeilenga" wrote: >> >> At 02:42 PM 4/13/01 +0200, Michael Str?der wrote: >> >The OpenLDAP 1.2.11 libs does not seem to be thread-safe. How about >> >OpenLDAP 2.0.x libs? >> >> While 2.0 provides an experimental -lldap_r. It is not generally >> thread-safe, but thread-safe if used in a specific manner. > >Can you please elaborate on that? No easily. Use of -lldap_r really requires one understands how it is implemented and how its being used. I won't attempt to generalize the cases where it might be used. Kurt From Stig.Venaas at uninett.no Sun Jul 15 10:31:38 2001 From: Stig.Venaas at uninett.no (Stig Venaas) Date: Sun, 15 Jul 2001 10:31:38 +0200 Subject: OpenLDAP 2.0.x's libldap_r In-Reply-To: <3B50D387.FFC34520@stroeder.com>; from michael@stroeder.com on Sun, Jul 15, 2001 at 01:19:35AM +0200 References: <3B50D387.FFC34520@stroeder.com> Message-ID: <20010715103138.A15368@sverresborg.uninett.no> On Sun, Jul 15, 2001 at 01:19:35AM +0200, Michael Str?der wrote: > HI! > > While we're at it: One thing which might bite other python-ldap > developers as well is that the OpenLDAP libs are not reentrant. > Despite the ugly hack with my wrapper module ldapthreadlock the > problem is still not really solved. I don't know much about this, it is something that I'll have to look into for PHP as well when it's used with Apache 2.0 etc. I generally thought that the API was thread safe if one made sure all threads used different links, and that the _r lib was for the case with several on the same link. But this is more or less guessing. The new API is more threading friendly since there are less use of static buffers. I can't think of any place with static buffers right now. One way of writing the Python LDAP API might be to map the low level Python functions and write some higher level functions in Python if they are needed. PHP has both high and low level LDAP functions, but they are all written in C. And I suppose we should try to make that thread safe. I have still not looked at the Python API, so I don't really know what I'm talking about (: Stig From michael at stroeder.com Sun Jul 15 20:53:30 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 15 Jul 2001 20:53:30 +0200 Subject: Drop CIDict (was: start tls) References: Message-ID: <3B51E6AA.19D9BD2D@stroeder.com> Steffen Ries wrote: > > David's CIDict patches > are not included, so I disabled CIDict to get it running with > python2.1. BTW: Shouldn't we drop the CIDict thingy completely? It can be easily implemented in Python by deriving from UserDict.UserDict. IMHO we should leave that up to the Python part for avoiding code bloat at the C wrapper level. Also CIDict is not capable of handling more of the upcoming aliases problems with attribute type names. Therefore it's almost useless anyway. Ciao, Michael. From michael at stroeder.com Mon Jul 16 13:26:28 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 16 Jul 2001 13:26:28 +0200 Subject: Tagging the CVS archive References: <3B52BD03.C86316BB@dante.org.uk> Message-ID: <3B52CF64.6AAA5AE1@stroeder.com> Konstantin Chuguev wrote: > > In any case, if we're going to have branches dependant on the OpenLDAP > API support, they could be called just OPENLDAP_1 or similar, while > releases could be named REL_1_11 and REL_1_10. Today nobody is building with Netscape or Novell libs anymore, I guess. Branches for OpenLDAP API (e.g OPENLDAP_1 and OPENLDAP_2) and tags for releases (e.g. REL_1_11). Does that make sense to you folks? > Unfortunately, I don't have enough experience in CVS to make branches. Me too. > Could somebody do that? David? Ciao, Michael. From steffen.ries at sympatico.ca Sun Jul 15 15:17:50 2001 From: steffen.ries at sympatico.ca (Steffen Ries) Date: 15 Jul 2001 09:17:50 -0400 Subject: Tagging the CVS archive In-Reply-To: Michael =?iso-8859-1?q?Str=F6der's?= message of "Fri, 13 Jul 2001 02:11:01 +0200" References: <3B4E3C95.D6490DF6@stroeder.com> Message-ID: Michael Str?der writes: > HI! > > Could we find some meaningful set of tags to mark the python-ldap > CVS archive? Maybe we can borrow some ideas from > http://www.openldap.org/software/repo.html ? > > I'd like to check in the new OpenLDAP 2-related patches and memory > leak fixes since I spent some time sending patch mails around. But > before that I'd like to mark the current CVS version with > PYTHONLDAP_REL_ENG_1_2 or something alike. Not being a CVS expert > though... :-/ I think you should create a branch tag for OpenLDAP 1 related stuff. That way both fixes for the "old" API and new stuff can go in in parallel. I would suggest a scheme where upper case tags are applied to releases, and lower case tags are branches. e.g.: REL-1-10ALPHA3 REL-1-11 ... openldap-1-api ... The head revision ("main trunk") holds the latest and greatest version, leading towards the next major release. The side branch is for fixing bugs in the current release (memory leaks...). The openldap-1-api branch should lead to a 1.10final release. /steffen -- steffen.ries at sympatico.ca <> Gravity is a myth -- the Earth sucks! From Konstantin.Chuguev at dante.org.uk Mon Jul 16 12:08:03 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Mon, 16 Jul 2001 11:08:03 +0100 Subject: Tagging the CVS archive Message-ID: <3B52BD03.C86316BB@dante.org.uk> Hi All, I can't understand why I haven't received a few recent messages sent to the mailing list. I've checked that I'm subscribed. Anyway, > FROM: Steffen Ries > DATE: 07/15/2001 06:17:50 > SUBJECT: RE: Tagging the CVS archive > > Michael Str?der <> writes: > > > Could we find some meaningful set of tags to mark the python-ldap > > CVS archive? Maybe we can borrow some ideas from > > http://www.openldap.org/software/repo.html ? > > > I think you should create a branch tag for OpenLDAP 1 related > stuff. That way both fixes for the "old" API and new stuff can go in > in parallel. > > I would suggest a scheme where upper case tags are applied to > releases, and lower case tags are branches. > > e.g.: > REL-1-10ALPHA3 > REL-1-11 > ... > openldap-1-api > ... > Are you sure the tags are case sensitive? The other thing: I'd personally prefer (I'm not insisting though :-) "_" instead of "-". In any case, if we're going to have branches dependant on the OpenLDAP API support, they could be called just OPENLDAP_1 or similar, while releases could be named REL_1_11 and REL_1_10. Unfortunately, I don't have enough experience in CVS to make branches. Could somebody do that? 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 From steffen.ries at sympatico.ca Mon Jul 16 15:32:03 2001 From: steffen.ries at sympatico.ca (Steffen Ries) Date: 16 Jul 2001 09:32:03 -0400 Subject: Tagging the CVS archive In-Reply-To: Konstantin Chuguev's message of "Mon, 16 Jul 2001 11:08:03 +0100" References: <3B52BD03.C86316BB@dante.org.uk> Message-ID: Konstantin Chuguev writes: ... > > I would suggest a scheme where upper case tags are applied to > > releases, and lower case tags are branches. > > > > e.g.: > > REL-1-10ALPHA3 > > REL-1-11 > > ... > > openldap-1-api > > ... > > > Are you sure the tags are case sensitive? Yes. > The other thing: I'd personally prefer (I'm not insisting though :-) "_" > instead of "-". Works for me too :-) (I was used to "." for separating parts of tags, but this works with ClearCase, not with CVS, so I started to use - instead...) > In any case, if we're going to have branches dependant on the OpenLDAP > API support, they could be called just OPENLDAP_1 or similar, while > releases could be named REL_1_11 and REL_1_10. I think it is better to have some naming convention which distinguishes branches from releases. E.g. "openldap_1_branch". > Unfortunately, I don't have enough experience in CVS to make branches. > Could somebody do that? cvs tag -b vs. cvs tag I don't have access to CVS... /steffen -- steffen.ries at sympatico.ca <> Gravity is a myth -- the Earth sucks! From michael at stroeder.com Fri Jul 13 12:58:47 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 13 Jul 2001 12:58:47 +0200 Subject: Commits for python-ldap 1.11 (was: Referral handling in OpenLDAP 2.0.11) References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <000201c10927$2a80e770$0281640a@redeemer> <3B4B2333.BE4DC8FE@dante.org.uk> <3B4B58A3.27243E7@stroeder.com> <3B4D6E89.E7A61E7D@dante.org.uk> <3B4D71B2.E1979850@stroeder.com> <20010712123007.A7254@sverresborg.uninett.no> <3B4EC45C.FCDC8FC@stroeder.com> <3B4ECE37.F62F4462@dante.org.uk> Message-ID: <3B4ED467.960C5A09@stroeder.com> Konstantin Chuguev wrote: > > I've just committed the memory leak fix for OpenLDAPv1 only, Great! > to avoid dealing with OpenLDAPv2 before we get a new release. > After that, I'll start committing OpenLDAPv2 patches with memory leak > fixes included. Yepp. > > See also my inquiry about CVS tagging on the list. > > Haven't received it yet. I already received it through the list. Attached it again below. > The new OpenLDAPv1-only version: should it be 1.10beta1 or 1.11? People were used to 1.10alpha3 as a release and refer to it as version 1.10. To avoid a mess the next release should be 1.11 as already set in CVS. Ciao, Michael. -------- Original Message -------- Subject: Tagging the CVS archive Date: Fri, 13 Jul 2001 02:11:01 +0200 From: Michael Str?der Reply-To: michael at stroeder.com Organization: stroeder.com To: python-ldap-dev HI! Could we find some meaningful set of tags to mark the python-ldap CVS archive? Maybe we can borrow some ideas from http://www.openldap.org/software/repo.html ? I'd like to check in the new OpenLDAP 2-related patches and memory leak fixes since I spent some time sending patch mails around. But before that I'd like to mark the current CVS version with PYTHONLDAP_REL_ENG_1_2 or something alike. Not being a CVS expert though... :-/ Ciao, Michael. From Konstantin.Chuguev at dante.org.uk Fri Jul 13 12:32:23 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Fri, 13 Jul 2001 11:32:23 +0100 Subject: Referral handling in OpenLDAP 2.0.11 References: <3B2C7BF2.147B9F21@stroeder.com> <3B49B6B2.517691E6@dante.org.uk> <3B49C7CE.D36A2164@stroeder.com> <3B4AC40F.9142E153@dante.org.uk> <000201c10927$2a80e770$0281640a@redeemer> <3B4B2333.BE4DC8FE@dante.org.uk> <3B4B58A3.27243E7@stroeder.com> <3B4D6E89.E7A61E7D@dante.org.uk> <3B4D71B2.E1979850@stroeder.com> <20010712123007.A7254@sverresborg.uninett.no> <3B4EC45C.FCDC8FC@stroeder.com> Message-ID: <3B4ECE37.F62F4462@dante.org.uk> Hi Michael, Michael Str?der wrote: > Konstantin, > > I've attached the latest patched message.c which hopefully contains > all fixes for the memory leaks in python-ldap. Hm, it's time to > check-in something to avoid all these patch mails... :-/ > Thanks for the file. I've just committed the memory leak fix for OpenLDAPv1 only, to avoid dealing with OpenLDAPv2 before we get a new release. After that, I'll start committing OpenLDAPv2 patches with memory leak fixes included. > > See also my inquiry about CVS tagging on the list. > Haven't received it yet. The new OpenLDAPv1-only version: should it be 1.10beta1 or 1.11? 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 From jens at zope.com Fri Jul 27 15:53:01 2001 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 27 Jul 2001 09:53:01 -0400 Subject: _ldap.SIZELIMIT_EXCEEDED Message-ID: <200107271353.f6RDr0X29161@smtp.zope.com> hi everyone, i am coming across the SIZELIMIT_EXCEEDED exception in some of my code and i was wondering what the limit actually is and if there is a way to code around it when using python-ldap, or maybe even a switch in the python-ldap code that i could change and then recompile? jens From michael at stroeder.com Fri Jul 27 16:00:29 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 27 Jul 2001 16:00:29 +0200 Subject: _ldap.SIZELIMIT_EXCEEDED References: <200107271353.f6RDr0X29161@smtp.zope.com> Message-ID: <3B6173FD.4BCDF515@stroeder.com> Jens Vagelpohl wrote: > > i am coming across the SIZELIMIT_EXCEEDED exception in some of my code and > i was wondering what the limit actually is This is the server-side limit of maximum search results. You usually do not have any influence on that because it depends on the LDAP server's configuration. Ciao, Michael. From Robert_Craven-RZTZ20 at email.mot.com Mon Jul 30 19:39:43 2001 From: Robert_Craven-RZTZ20 at email.mot.com (Robert Craven) Date: Mon, 30 Jul 2001 12:39:43 -0500 Subject: Solaris 8 & python_ldap for Zope/Python Message-ID: <3B659BDF.D88E7CFF@motorola.com> Has anyone tried to get this to work? Sorry if this has been covered, I am new to the list. I am trying to get Zope 2.4 + Python 2.1.1 + LDAP to work. The LDAP libraries native to Solaris 8 seem to be missing a real reference to ldap_name2template. At least that is what zope complains about when it starts up. I have the python-ldap-1.10alpha3. I have also tried to compile openldap (versions 1.2.12 and 2.0.11) without any real success. Any help would be greatly appreciated. Thanks, Bob Craven -- ============================================================================= Robert Craven AVS DSCS (Design Software & Computer Services) Motorola, Inc. 6501 William Cannon Dr. West MS.OE-320 (512) 895-4440 Austin, TX 78735-8598 <>< Robert.Craven at motorola.com From michael at stroeder.com Tue Jul 31 17:49:10 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 31 Jul 2001 17:49:10 +0200 Subject: Solaris 8 & python_ldap for Zope/Python References: <3B659BDF.D88E7CFF@motorola.com> Message-ID: <3B66D376.5CB07AAF@stroeder.com> Robert, sorry for answering so late. Robert Craven wrote: > > Has anyone tried to get this to work? > > Sorry if this has been covered, I am new to the list. I am > trying to get Zope 2.4 + Python 2.1.1 + LDAP to work. > The LDAP libraries native to Solaris 8 seem to be missing a real > reference to ldap_name2template. At least that is what zope > complains about when it starts up. I have the > python-ldap-1.10alpha3. I have also tried to compile openldap > (versions 1.2.12 and 2.0.11) without any real success. I can't give you specific hints about building under Solaris 8 and the native LDAP libs with Solaris 8 (AFAIK it's the Netscape LDAP SDK). But I'd suggest that you check out the latest snapshot of python-ldap and try to build that against a local copy of the OpenLDAP 1.2.12 tree. Support for OpenLDAP 2 libs is work in progress and currently very experimental. If you have problems the most promising way is to come up with the build log on this mailing list. Ciao, Michael. From jlittle at open-it.org Tue Jul 31 18:14:20 2001 From: jlittle at open-it.org (Joe Little) Date: Tue, 31 Jul 2001 09:14:20 -0700 Subject: Solaris 8 & python_ldap for Zope/Python In-Reply-To: <3B66D376.5CB07AAF@stroeder.com> Message-ID: <200107311612.f6VGCJ711203@kodama.stanford.edu> Robert, as an addendum, the Solaris 8 libs aren't the netscape libs (Sun has their own working code base). So, alternatively, you could use the netscape libraries or the mozilla versions if the OpenLDAP ones do not work. Michael is correct in that any logs of the builds will help out list readers. to the rest: yeah, I'm back in action, and happy to see a lot of list traffic of late in positive directions. It looks like I may get to focus most of my energies on Zope since the effort on the OpenLDAP 2.x stuff is progressing nicely. One note: I'm hoping to resolve darwin/MacOSX dynamic library issues since Zope folks seem to like MacOSX. On Tuesday, July 31, 2001, at 08:49 AM, Michael Str?der wrote: > Robert, > > sorry for answering so late. > > Robert Craven wrote: >> >> Has anyone tried to get this to work? >> >> Sorry if this has been covered, I am new to the list. I am >> trying to get Zope 2.4 + Python 2.1.1 + LDAP to work. >> The LDAP libraries native to Solaris 8 seem to be missing a real >> reference to ldap_name2template. At least that is what zope >> complains about when it starts up. I have the >> python-ldap-1.10alpha3. I have also tried to compile openldap >> (versions 1.2.12 and 2.0.11) without any real success. > > I can't give you specific hints about building under Solaris 8 and > the native LDAP libs with Solaris 8 (AFAIK it's the Netscape LDAP > SDK). > > But I'd suggest that you check out the latest snapshot of > python-ldap and try to build that against a local copy of the > OpenLDAP 1.2.12 tree. Support for OpenLDAP 2 libs is work in > progress and currently very experimental. > > If you have problems the most promising way is to come up with the > build log on this mailing list. > > Ciao, Michael. > > From michael at stroeder.com Thu Aug 2 18:20:42 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 02 Aug 2001 18:20:42 +0200 Subject: Python-ldap32 module for Zope References: <3B69683C.DF382F89@motorola.com> Message-ID: <3B697DDA.C48FA4F2@stroeder.com> Steve Jones wrote: > > I have just installed the Win32 version of Zope 2.4.0 and it ships with > Python 2.1. Your python-ldap module requires Python2.0 and apparently > won't work with python2.1. Any chance of making a python2.1 verion of > the ldap code available? Sorry, I just provide the ZIP file for download. I have no Win32 environment for building python-ldap. Maybe you can convince Mauro who did it or another person. Ciao, Michael. From michael at stroeder.com Fri Aug 3 17:31:55 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 03 Aug 2001 17:31:55 +0200 Subject: Returning sorted sets References: <3B69683C.DF382F89@motorola.com> <3B697DDA.C48FA4F2@stroeder.com> <3B6AB6D0.8ECBDAC4@brainstorm.co.uk> Message-ID: <3B6AC3EB.24173F9F@stroeder.com> nick at Brainstorm.co.uk wrote: > > Ideally, I want my search interface to return just 20 records at a time, > which are a sorted subset of a larger result set. Does the LDAP > protocol allow this? The right solution would require deploying two LDAP extended controls: - paged results (OID 1.2.840.113556.1.4.319, see RFC2696) - Server Side Sorting of Search Results (OID 1.2.840.113556.1.4.473, see RFC2891) But unfortunately 1. with python-ldap you can't currently make use of extended controls and 2. the server has to support both controls (which you can check by looking at attribute supportedControl of its RootDSE). > I'm trying to think how else to do a multiple-page > search interface, ala current search engines with the footer Well, you could retrieve all search results, sort them on the client side and cache it for the next page hits. But take care of security considerations! My web2ldap cheats: It simply invokes a async search and retrieves the search results for the currently viewed page without doing any sorting. I considered the user to give up looking through the search results on the first page anyway. ;-) Ciao, Michael. From nick at Brainstorm.co.uk Fri Aug 3 16:36:00 2001 From: nick at Brainstorm.co.uk (nick at Brainstorm.co.uk) Date: Fri, 03 Aug 2001 15:36:00 +0100 Subject: Returning sorted sets References: <3B69683C.DF382F89@motorola.com> <3B697DDA.C48FA4F2@stroeder.com> Message-ID: <3B6AB6D0.8ECBDAC4@brainstorm.co.uk> This one should really go in the FAQ for LDAP beginners like me :-) I've implemented an LDAP search interface, but as we know, results are returned unsorted. Python doesn't do too badly at this (although I can't help thinking it would be faster if underlying C routines did it). But sorting on the client side becomes problematic in a cgi which wants to show just 20 results at a time. Ideally, I want my search interface to return just 20 records at a time, which are a sorted subset of a larger result set. Does the LDAP protocol allow this? I'm trying to think how else to do a multiple-page search interface, ala current search engines with the footer [ 1 | 2 | 3 | 4 | next --> ] Any ideas? Cheers, nick PS - Thanks for a useful tool. Michael Str?der wrote: > > Steve Jones wrote: > > > > I have just installed the Win32 version of Zope 2.4.0 and it ships with > > Python 2.1. Your python-ldap module requires Python2.0 and apparently > > won't work with python2.1. Any chance of making a python2.1 verion of > > the ldap code available? > > Sorry, I just provide the ZIP file for download. I have no Win32 > environment for building python-ldap. Maybe you can convince Mauro > who did it or another person. > > Ciao, Michael. > > From michael at stroeder.com Fri Aug 3 18:34:04 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 03 Aug 2001 18:34:04 +0200 Subject: Returning sorted sets References: <3B69683C.DF382F89@motorola.com> <3B697DDA.C48FA4F2@stroeder.com> <3B6AB6D0.8ECBDAC4@brainstorm.co.uk> <3B6AC3EB.24173F9F@stroeder.com> <3B6AC9F9.7930468D@brainstorm.co.uk> Message-ID: <3B6AD27C.6C5809F9@stroeder.com> nick at brainstorm.co.uk wrote: > > thanks for the anwer. i 'm using openldap (not sure if this has server > side sorting), My OpenLDAP does not announce it in supportedControl. You can check yourself with e.g. web2ldap: http://sites.inka.de:8002/web2ldap/ldapurl?ldap://ldap.openldap.org > but if it does, it may be worth me looking into the jndi > before using caching. boo hiss ;-) Boooooo! Maybe Jython? Ciao, Michael. From nick at brainstorm.co.uk Fri Aug 3 17:57:45 2001 From: nick at brainstorm.co.uk (nick at brainstorm.co.uk) Date: Fri, 03 Aug 2001 16:57:45 +0100 Subject: Returning sorted sets References: <3B69683C.DF382F89@motorola.com> <3B697DDA.C48FA4F2@stroeder.com> <3B6AB6D0.8ECBDAC4@brainstorm.co.uk> <3B6AC3EB.24173F9F@stroeder.com> Message-ID: <3B6AC9F9.7930468D@brainstorm.co.uk> thanks for the anwer. i 'm using openldap (not sure if this has server side sorting), but if it does, it may be worth me looking into the jndi before using caching. boo hiss ;-) nick Michael Str?der wrote: > > nick at Brainstorm.co.uk wrote: > > > > Ideally, I want my search interface to return just 20 records at a time, > > which are a sorted subset of a larger result set. Does the LDAP > > protocol allow this? > > The right solution would require deploying two LDAP extended > controls: > - paged results (OID 1.2.840.113556.1.4.319, see RFC2696) > - Server Side Sorting of Search Results > (OID 1.2.840.113556.1.4.473, see RFC2891) > > But unfortunately > 1. with python-ldap you can't currently make use of extended > controls and > 2. the server has to support both controls (which you can > check by looking at attribute supportedControl of its > RootDSE). > > > I'm trying to think how else to do a multiple-page > > search interface, ala current search engines with the footer > > Well, you could retrieve all search results, sort them on the client > side and cache it for the next page hits. But take care of security > considerations! > > My web2ldap cheats: It simply invokes a async search and retrieves > the search results for the currently viewed page without doing any > sorting. I considered the user to give up looking through the search > results on the first page anyway. ;-) > > Ciao, Michael. -- Nick Bower, Intranet Developer nick at brainstorm.co.uk Brainstorm 388 - 396 Oxford St London W1N 9EH United Kingdom Tel 020 7074 7000 Mob 0790 5405 443 Fax 020 7074 7070 http://www.brainstorm.co.uk From Konstantin.Chuguev at dante.org.uk Mon Jul 23 12:24:32 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Mon, 23 Jul 2001 11:24:32 +0100 Subject: Tagging the CVS archive References: <3B52BD03.C86316BB@dante.org.uk> <3B52CF64.6AAA5AE1@stroeder.com> Message-ID: <3B5BFB60.AC1ED025@dante.org.uk> Hi All, I think there's no point to postpone introduction of the OpenLDAPv1 branch in the CVS. I can do that, I just need an approval from one of the project admins. The proposed name is openldap_1_branch. It will be made on both python-ldap and htdocs directories. After that we could just reflect branching in htdocs/faq.shtml (or somewhere else) and then update the latter in the current branch to reflect LDAPv3/OpenLDAPv2 support (after submitting the corresponding patches, of course :-) Any objections? A small question: there are HTML links to files in htdocs/doc/ directory from htdocs/docs.shtml file, while there's no such directory. Why? Regards, Konstantin. -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.net United Kingdom From michael at stroeder.com Thu Aug 9 03:03:51 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 09 Aug 2001 03:03:51 +0200 Subject: Tagging the CVS archive References: <3B52BD03.C86316BB@dante.org.uk> <3B52CF64.6AAA5AE1@stroeder.com> <3B5BFB60.AC1ED025@dante.org.uk> Message-ID: <3B71E177.F4E290F6@stroeder.com> Konstantin, sorry for answering that late. Konstantin Chuguev wrote: > > I think there's no point to postpone introduction of the OpenLDAPv1 branch > in the CVS. Agreed. > I can do that, I just need an approval from one of the project > admins. Hmm, not sure if I'm a project admin. Well, I'm listed there... > The proposed name is openldap_1_branch. It will be made on both > python-ldap and htdocs directories. Please use capital letters OPENLDAP_1_BRANCH but not on the htdocs/ directory. Go for it. > A small question: there are HTML links to files in htdocs/doc/ directory > from htdocs/docs.shtml file, while there's no such directory. Why? The directory htdocs/ is solely dedicated to manage the web pages on http://python-ldap.sf.net. Leave that out. It's not part of a release tar-ball. Ciao, Michael. From steffen.ries at sympatico.ca Sun Jul 15 19:46:58 2001 From: steffen.ries at sympatico.ca (Steffen Ries) Date: 15 Jul 2001 13:46:58 -0400 Subject: start tls Message-ID: Hi, attached is a small (experimental) patch, which enables 'start_tls_s()' in python-ldap. The patch requires OpenLDAP 2.0.x (I tested it only against 2.0.11 on Redhat 6.2). I included Konstanin's patches and the memory leak fixes and have run the diff against the current CVS version. David's CIDict patches are not included, so I disabled CIDict to get it running with python2.1. To use it, you will need OpenLDAP 2.0.x with TLS support built in (see http://www.openldap.org/faq/data/cache/185.html). A simple demonstration looks like this: >>> server = ldap.open('localhost') >>> server.version = ldap.VERSION3 >>> server.start_tls_s() >>> server.simple_bind_s(...) If the ldap server supports startTLS and the Certificate maps to the host, the call to start_tls_s() succeeds, otherwise an exception is thrown. /steffen -- steffen.ries at sympatico.ca <> Gravity is a myth -- the Earth sucks! -------------- next part -------------- A non-text attachment was scrubbed... Name: diffs Type: application/octet-stream Size: 16556 bytes Desc: not available URL: From michael at stroeder.com Thu Aug 9 03:34:58 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 09 Aug 2001 03:34:58 +0200 Subject: start tls References: Message-ID: <3B71E8C2.60B0B088@stroeder.com> Steffen, sorry for following-up so late. Steffen Ries wrote: > > attached is a small (experimental) patch, which enables > 'start_tls_s()' in python-ldap. I built with your patch against OpenLDAP 2.0.11 and did some tests without StartTLS first. Everything went well running (with web2ldap) against ldap.openldap.org but it failed when accessing www.nldap.com (Novell DS) or ldap.surfnet.nl (Netscape DS). I got segmentation faults. The OpenLDAP 2.0-patches by Konstantin for python-ldap posted before on the mailing list worked. Maybe you already have a newer version of your patch? I checked the shared libs. Seems ok to me. $ ldd _ldap.so libldap.so.2 => /usr/local/openldap2/lib/libldap.so.2 (0x40023000) liblber.so.2 => /usr/local/openldap2/lib/liblber.so.2 (0x4004e000) libc.so.6 => /lib/libc.so.6 (0x40058000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4016b000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40176000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4022e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x402f2000) libdl.so.2 => /lib/libdl.so.2 (0x402fa000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x402fd000) libpam.so.0 => /lib/libpam.so.0 (0x4032b000) libresolv.so.2 => /lib/libresolv.so.2 (0x40333000) > I included Konstanin's patches and the memory leak fixes and have run > the diff against the current CVS version. David's CIDict patches > are not included, so I disabled CIDict to get it running with > python2.1. We'll drop CIDict anyway. Ciao, Michael. From steffen.ries at sympatico.ca Thu Aug 9 13:07:05 2001 From: steffen.ries at sympatico.ca (Steffen Ries) Date: 09 Aug 2001 07:07:05 -0400 Subject: start tls References: <3B71E8C2.60B0B088@stroeder.com> Message-ID: Michael Str?der writes: > Everything went well running (with web2ldap) against > ldap.openldap.org but it failed when accessing www.nldap.com (Novell > DS) or ldap.surfnet.nl (Netscape DS). I got segmentation faults. Hmmmm. I don't have problems with it: >>> import ldap >>> s = ldap.open('ldap.surfnet.nl') >>> s.simple_bind_s('','') >>> s.search_s('', ldap.SCOPE_ONELEVEL, 'objectclass=*', ['objectclass']) [('C=NL', {'objectclass': ['top',... Can you run python inside gdb to get a traceback? Or give me more details how you got the segfaults? > The OpenLDAP 2.0-patches by Konstantin for python-ldap posted before > on the mailing list worked. Maybe you already have a newer version > of your patch? No newer version, I can redo the diffs against CVS, but I'm not sure whether this would help. > I checked the shared libs. Seems ok to me. > > $ ldd _ldap.so > libldap.so.2 => /usr/local/openldap2/lib/libldap.so.2 > (0x40023000) > liblber.so.2 => /usr/local/openldap2/lib/liblber.so.2 > (0x4004e000) > libc.so.6 => /lib/libc.so.6 (0x40058000) > libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4016b000) > libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40176000) > libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 > (0x4022e000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x402f2000) > libdl.so.2 => /lib/libdl.so.2 (0x402fa000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x402fd000) > libpam.so.0 => /lib/libpam.so.0 (0x4032b000) > libresolv.so.2 => /lib/libresolv.so.2 (0x40333000) looks fine. on my Redhat 7.1 system I get libssl.so.1 and libcrypt.so.1 instead, but I don't think that would make a difference. libldap.so.2 is symlinked to libldap.so.2.0.6 (same for liblber.so), i.e. openldap-2.0.11 /steffen From michael at stroeder.com Thu Aug 9 14:51:38 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 09 Aug 2001 14:51:38 +0200 Subject: start tls References: <3B71E8C2.60B0B088@stroeder.com> Message-ID: <3B72875A.C7BBEFFA@stroeder.com> Steffen Ries wrote: > > Can you run python inside gdb to get a traceback? Or give me more > details how you got the segfaults? I tried it but I'm a complete newbie regarding gdb. The seg faults seem to happen at various places. Maybe it has to do with threading problems? web2ldap can run threaded or "single-threaded". In latter mode only a clean-up thread is running besides the main thread. In multi-threaded mode each HTTP request is handled by an own handler thread (my wrapper module ldapthreadlock is used in this case to avoid re-entrant calls into the LDAP libs). I've started the web2ldap stand-alone demon non-detached and attached gdb to it by issuing $ sbin/web2ldap.py -d off -t off $ gdb /usr/bin/python [web2ldap's PID] [.. snipped a lot of gdb-output related to shared lib loading ..] 0x4012b772 in __libc_accept () from /lib/libc.so.6 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1026 (LWP 2840)] 0x4002da78 in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0x4002da78 in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x400d223b in free () from /lib/libc.so.6 #2 0x4038c47c in dealloc (self=0x4055ea10) at Modules/LDAPObject.c:46 #3 0x808ea38 in dict_dealloc (mp=0x405d517c) at Objects/dictobject.c:629 #4 0x807fad9 in instance_dealloc (inst=0x405d4ccc) at Objects/classobject.c:583 #5 0x805772d in eval_code2 (co=0x4018c120, globals=0x40190b3c, locals=0x0, args=0x819e0b0, argcount=1, kws=0x819e0b4, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1673 #6 0x80598fd in fast_function (func=0x401f309c, pp_stack=0xbf7ff9dc, n=1, na=1, nk=0) at Python/ceval.c:3022 #7 0x8057f85 in eval_code2 (co=0x401a54a0, globals=0x401a735c, locals=0x0, args=0x4051a438, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1972 #8 0x80597e7 in call_eval_code2 (func=0x401af72c, arg=0x4051a42c, kw=0x0) at Python/ceval.c:2966 #9 0x80593e2 in call_object (func=0x401af72c, arg=0x4051a42c, kw=0x0) at Python/ceval.c:2805 #10 0x805969c in call_method (func=0x401af72c, arg=0x40177074, kw=0x0) at Python/ceval.c:2923 #11 0x80593c6 in call_object (func=0x4055f98c, arg=0x40177074, kw=0x0) at Python/ceval.c:2803 #12 0x80592ae in PyEval_CallObjectWithKeywords (func=0x4055f98c, arg=0x40177074, kw=0x0) at Python/ceval.c:2740 #13 0x8072d19 in t_bootstrap (boot_raw=0x8165fc8) at ./Modules/threadmodule.c:190 #14 0x4002cca3 in pthread_start_thread () from /lib/libpthread.so.0 (gdb) Ciao, Michael. From michael at stroeder.com Thu Aug 16 17:24:51 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 16 Aug 2001 17:24:51 +0200 Subject: Handling of Unicode objects (was: start tls) References: Message-ID: <3B7BE5C3.3CF37555@stroeder.com> Steffen Ries wrote: > > attached is a small (experimental) patch, which enables > 'start_tls_s()' in python-ldap. The patch requires OpenLDAP 2.0.x (I > tested it only against 2.0.11 on Redhat 6.2). > > I included Konstanin's patches and the memory leak fixes and have run > the diff against the current CVS version. David's CIDict patches > are not included, so I disabled CIDict to get it running with > python2.1. BTW: It seems that in opposite to the former python-ldap Unicode strings are accepted by e.g. the modify() call when these patches are applied. In the beginning I considered this also to be a good idea. But now I think this is flawed since we don't have a way to define how the Unicode objects are encoded to strings. Note that this would require knowledge about the syntax of a certain attribute type => the LDAP application should handle that. If you examine RFC2251 (Lightweight Directory Access Protocol (v3)) you will notice that all transmitted strings are encoded as OCTET STRING no matter what attribute value they contain. Therefore the best bet seems to me to solely accept type('') at python-ldap's API level for attribute values. The calling application should be responsible for handle Unicode objects. Ciao, Michael. From michael at stroeder.com Sat Sep 8 16:08:06 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sat, 08 Sep 2001 16:08:06 +0200 Subject: =?iso-8859-1?Q?R=E9p=2E?= : Re: NDS library linking References: Message-ID: <3B9A2646.C750C0F0@stroeder.com> Timothy Wilson wrote: > > On Thu, 6 Sep 2001, Olivier Dewit wrote: > > > Thank you for your explanation. I'm not sure it is a NDS/LDAP problem. > > I'm not a python-ldap expert by any stretch of the imagination, but have > you tried accessing your NDS using http://web2ldap.de/ ? I use it to query > our public directory occasionally. Sorry for jumping on this so late. Always use recent CVS version tagged with OPENLDAP_1_BRANCH for linking against OpenLDAP 1.2.x libs or old Netscape/Novell libs since there were some serious bug fixes done during the last months. AFAIK old Netscape 3 and old Novell libs are not available anymore. Following the discussion thread I'm not sure what the question with Novell NDS really was. 1. If you want to link python-ldap against Novell's NDS libs you might be lost. As I understand some press releases the Novell LDAP libs are based on OpenLDAP libs though I'm not sure. If Novell's lib is based on OpenLDAP 2.0.x libs (likely for leveraging LDAPv3) the same issues arise like linking python-ldap against OpenLDAP 2.0.x libs: You will need a proper patch for HEAD branch but you're on your own working with that. I'd like to hear experiences on that including exact version numbers! 2. You should be able to use python-ldap to access a NDS server. You might wanna try web2ldap's online demo for checking your server, e.g. http://sites.inka.de:8002/web2ldap/ldapurl?ldap://www.nldap.com (note that the demo is running with a patched python-ldap built against OpenLDAP 2.0.x libs). Ciao, Michael. From ODewit at isagri.fr Wed Sep 12 16:05:21 2001 From: ODewit at isagri.fr (Olivier Dewit) Date: Wed, 12 Sep 2001 16:05:21 +0200 Subject: =?ISO-8859-1?Q?Re:=20Re:=20R=E9p.=20:=20Re:=20NDS=20library=20li?= =?ISO-8859-1?Q?nking?= Message-ID: Hello Tim, Novell has probably adjusted security policy on the NDS LDAP test site, and now, authentication with simple_bind_s() works for admin account. Now python-ldap and Novell's LDAP library work the same. Some problems remain, but they are caused by NDS, not by python-ldap. So python-ldap works with NDS, without needing to compile a Novell library. It is the answer to my initial question. Thank you very much for your help. Olivier odewit at isagri.fr >>> Timothy Wilson 07/09/01 19:56:52 >>> On Thu, 6 Sep 2001, Olivier Dewit wrote: > Thank you for your explanation. I'm not sure it is a NDS/LDAP problem. I'm not a python-ldap expert by any stretch of the imagination, but have you tried accessing your NDS using http://web2ldap.de/ ? I use it to query our public directory occasionally. -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.com W. St. Paul, MN | | http://slashdot.org wilson at visi.com | | http://linux.com From Shahram.Kaeidinejad at dgn-service.de Wed Sep 12 09:45:00 2001 From: Shahram.Kaeidinejad at dgn-service.de (Kaeidinejad, Shahram) Date: Wed, 12 Sep 2001 09:45:00 +0200 Subject: make error an sun solaris 5.6 Message-ID: <2D783717DD91D3118CB50090274DBB9058DBF6@NTSMSX01> hi, i try to compile python-ldap-1.10alpha3 for python-2.1.1 an sun solaris 5.6 but i got error by the make. can you help me? the ./configure entired: creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for python... /usr/local/bin/python checking python version... 2.1 checking python install prefix... /opt/python-2.1.1 checking for socket in -lnsl... no checking for socket in -lnet... no checking for socket in -lsocket... yes checking for gethostbyname... no checking for gethostbyname in -lnsl... yes checking for inet_addr... yes checking for inet_ntoa... yes checking for connect... yes checking for fmod... no checking for fmod in -lm... yes checking for floor... yes checking for krb_mk_req... no checking for krb_mk_req in -lkrb... yes checking for des_setkey... no checking for des_setkey in -ldes... no Using LDAP libraries from /usr/site/openldap-1.2.11/lib Using LDAP includes from /usr/site/openldap-1.2.11/include checking for library containing ber_free... -llber checking for library containing ldap_open... -lldap checking for ldap_open... yes checking how to run the C preprocessor... gcc -E checking for ldap.h... yes checking for lber.h... yes checking number of arguments to ldap_set_rebind_proc()... 2 checking for ldap_kerberos_bind_s... no checking for ldap_kerberos_bind1... no checking for ldap_kerberos_bind1_s... no checking for ldap_kerberos_bind2... no checking for ldap_kerberos_bind2_s... no checking for ldap_enable_cache... yes checking for ldap_disable_cache... yes checking for ldap_set_cache_options... yes checking for ldap_destroy_cache... yes checking for ldap_flush_cache... yes checking for ldap_uncache_entry... yes checking for ldap_uncache_request... yes checking whether the LDAP type is opaque... no checking for ldap_modrdn2_s... yes checking for ldap_modrdn2... yes checking for ldap_init_templates... yes checking for disptmpl.h... yes checking python makefile... /opt/python-2.1.1/lib/python2.1/config/Makefile.pre.in updating cache ./config.cache creating ./config.status creating Modules/Setup creating Makefile creating Modules/config.h bootstrapping makefile rm -f *.o *~ rm -f *.a tags TAGS config.c Makefile.pre python sedscript rm -f *.so *.sl so_locations VERSION=`/usr/local/bin/python -c "import sys; print sys.version[:3]"`; \ installdir=`/usr/local/bin/python -c "import sys; print sys.prefix"`; \ exec_installdir=`/usr/local/bin/python -c "import sys; print sys.exec_prefix"`; \ make -f ./Makefile.pre.in VPATH=. srcdir=. \ VERSION=$VERSION \ installdir=$installdir \ exec_installdir=$exec_installdir \ Makefile make[1]: Entering directory `/temp/site/source/python-ldap-1.10alpha3/Modules' sed -n \ -e '1s/.*/1i\\/p' \ -e '2s%.*%# Generated automatically from Makefile.pre.in by sedscript.%p' \ -e '/^VERSION=/s/^VERSION=[ ]*\(.*\)/s%@VERSION[@]%\1%/p' \ -e '/^CC=/s/^CC=[ ]*\(.*\)/s%@CC[@]%\1%/p' \ -e '/^CXX=/s/^CXX=[ ]*\(.*\)/s%@CXX[@]%\1%/p' \ -e '/^LINKCC=/s/^LINKCC=[ ]*\(.*\)/s%@LINKCC[@]%\1%/p' \ -e '/^OPT=/s/^OPT=[ ]*\(.*\)/s%@OPT[@]%\1%/p' \ -e '/^LDFLAGS=/s/^LDFLAGS=[ ]*\(.*\)/s%@LDFLAGS[@]%\1%/p' \ -e '/^LDLAST=/s/^LDLAST=[ ]*\(.*\)/s%@LDLAST[@]%\1%/p' \ -e '/^DEFS=/s/^DEFS=[ ]*\(.*\)/s%@DEFS[@]%\1%/p' \ -e '/^LIBS=/s/^LIBS=[ ]*\(.*\)/s%@LIBS[@]%\1%/p' \ -e '/^LIBM=/s/^LIBM=[ ]*\(.*\)/s%@LIBM[@]%\1%/p' \ -e '/^LIBC=/s/^LIBC=[ ]*\(.*\)/s%@LIBC[@]%\1%/p' \ -e '/^RANLIB=/s/^RANLIB=[ ]*\(.*\)/s%@RANLIB[@]%\1%/p' \ -e '/^MACHDEP=/s/^MACHDEP=[ ]*\(.*\)/s%@MACHDEP[@]%\1%/p' \ -e '/^SO=/s/^SO=[ ]*\(.*\)/s%@SO[@]%\1%/p' \ -e '/^LDSHARED=/s/^LDSHARED=[ ]*\(.*\)/s%@LDSHARED[@]%\1%/p' \ -e '/^CCSHARED=/s/^CCSHARED=[ ]*\(.*\)/s%@CCSHARED[@]%\1%/p' \ -e '/^SGI_ABI=/s/^SGI_ABI=[ ]*\(.*\)/s%@SGI_ABI[@]%\1%/p' \ -e '/^LINKFORSHARED=/s/^LINKFORSHARED=[ ]*\(.*\)/s%@LINKFORSHARED[@]%\1%/p' \ -e '/^prefix=/s/^prefix=\(.*\)/s%^prefix=.*%prefix=\1%/p' \ -e '/^exec_prefix=/s/^exec_prefix=\(.*\)/s%^exec_prefix=.*%exec_prefix=\1%/p' \ /opt/python-2.1.1/lib/python2.1/config/Makefile >sedscript echo "/^installdir=/s%=.*%= /opt/python-2.1.1%" >>sedscript echo "/^exec_installdir=/s%=.*%=/opt/python-2.1.1%" >>sedscript echo "/^srcdir=/s%=.*%= .%" >>sedscript echo "/^VPATH=/s%=.*%= .%" >>sedscript echo "/^LINKPATH=/s%=.*%= %" >>sedscript echo "/^BASELIB=/s%=.*%= %" >>sedscript echo "/^BASESETUP=/s%=.*%= %" >>sedscript sed -f sedscript ./Makefile.pre.in >Makefile.pre /opt/python-2.1.1/lib/python2.1/config/makesetup \ -m Makefile.pre -c /opt/python-2.1.1/lib/python2.1/config/config.c.in Setup -n /opt/python-2.1.1/lib/python2.1/config/Setup.config /opt/python-2.1.1/lib/python2.1/config/Setup.local /opt/python-2.1.1/lib/python2.1/config/Setup make -f Makefile do-it-again make[2]: Entering directory `/temp/site/source/python-ldap-1.10alpha3/Modules' /opt/python-2.1.1/lib/python2.1/config/makesetup \ -m Makefile.pre -c /opt/python-2.1.1/lib/python2.1/config/config.c.in Setup -n /opt/python-2.1.1/lib/python2.1/config/Setup.config /opt/python-2.1.1/lib/python2.1/config/Setup.local /opt/python-2.1.1/lib/python2.1/config/Setup make[2]: Leaving directory `/temp/site/source/python-ldap-1.10alpha3/Modules' make[1]: Leaving directory `/temp/site/source/python-ldap-1.10alpha3/Modules' and the make entired:( there was to big but i cut it) ............ 0x440 /usr/site/openldap-1.2.11/lib/libldap.a(getfilter.o) 0xb30 /usr/site/openldap-1.2.11/lib/liblber.a(decode.o) 0xb38 /usr/site/openldap-1.2.11/lib/liblber.a(decode.o) 0xb3c /usr/site/openldap-1.2.11/lib/liblber.a(decode.o) 0xb40 /usr/site/openldap-1.2.11/lib/liblber.a(decode.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make[1]: *** [_ldapmodule.so] Error 1 make[1]: Leaving directory `/temp/site/source/python-ldap-1.10alpha3/Modules' make: *** [_ldapmodule-build] Error 2 thanks Shahram From Konstantin.Chuguev at dante.org.uk Wed Aug 29 15:33:14 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Wed, 29 Aug 2001 14:33:14 +0100 Subject: Tagging the CVS archive References: <3B52BD03.C86316BB@dante.org.uk> <3B52CF64.6AAA5AE1@stroeder.com> <3B5BFB60.AC1ED025@dante.org.uk> <3B71E177.F4E290F6@stroeder.com> Message-ID: <3B8CEF19.89FD9B5E@dante.org.uk> Hi Michael and All, Michael Str?der wrote: > sorry for answering that late. > No worries, same problem here: I have been too busy last couple of months... I have just tagged the repository with the OPENLDAP_1_BRANCH tag. Everything seems to be OK, at least I can see and choose that tag in the Sourceforge web-to-CVS gateway. Anybody willing to roll out the release for OpenLDAPv1? I'm going to add OpenLDAPv2 patches soon. The first goal is to handle referrals, the second one is a new version of the rebind_proc callback. Note that in the C API, OpenLDAPv1 rebind_proc is incompatible with OpenLDAPv2. I do not see the way of providing compatibility between them, because the callback mechanism itself has changed completely. So I think we need a change in python-ldap API as well. Do you have any suggestions about it? Regards, Konstantin. > > Konstantin Chuguev wrote: > > > > I think there's no point to postpone introduction of the OpenLDAPv1 branch > > in the CVS. > > Agreed. > > > I can do that, I just need an approval from one of the project > > admins. > > Hmm, not sure if I'm a project admin. Well, I'm listed there... > > > The proposed name is openldap_1_branch. It will be made on both > > python-ldap and htdocs directories. > > Please use capital letters OPENLDAP_1_BRANCH but not on the htdocs/ > directory. Go for it. > > > A small question: there are HTML links to files in htdocs/doc/ directory > > from htdocs/docs.shtml file, while there's no such directory. Why? > > The directory htdocs/ is solely dedicated to manage the web pages on > http://python-ldap.sf.net. Leave that out. It's not part of a > release tar-ball. > > Ciao, Michael. -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.net United Kingdom From arnaud.fausse1 at libertysurf.fr Wed Sep 26 03:26:16 2001 From: arnaud.fausse1 at libertysurf.fr (Arnaud Fausse) Date: Tue, 25 Sep 2001 21:26:16 -0400 Subject: Make problem: Makefile target missing in "Modules" directory Message-ID: <01092521261601.03527@wang> Hi, I would like to use the LDAP_Python library and I downloaded the sources. My platform is x86 Linux Mandrake 8.0. I built the full OpenLDAP 2.0.11 package without difficulties, same for LDAP- 3.3. By the way, I use Python 2.0. I try to build the Python-Ldap in my home directory (name '/home/poussin') I run the configure command: ./configure ...with tokens for lib and include locations. Configuration script seems OK, but 'make' fails on the 'Modules' part where there is no target. (same effect being root or not). Below you find: - the console display - the config log as attached doc. Can you help me ? Did I miss something obvious ? Is there anyboday who can help me ? Thanks in advance for your help Arnaud ------------------------------- console log [poussin at wang python-ldap-1.10alpha3]$ ./configure loading cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes (cached) checking python version... (cached) 2.0 checking python install prefix... (cached) /usr checking for /tmp/ldap-pfx... no checking for socket... (cached) yes checking for gethostbyname... (cached) yes checking for inet_addr... (cached) yes checking for inet_ntoa... (cached) yes checking for connect... (cached) yes checking for fmod... (cached) no checking for fmod in -lm... (cached) yes checking for floor... (cached) yes checking for krb_mk_req... (cached) no checking for krb_mk_req in -lkrb... (cached) no checking for des_setkey... (cached) no checking for des_setkey in -ldes... (cached) no checking for library containing ber_free... (cached) -llber checking for library containing ldap_open... (cached) -lldap checking for ldap_open... (cached) yes checking how to run the C preprocessor... (cached) gcc -E checking for ldap.h... (cached) yes checking for lber.h... (cached) yes checking number of arguments to ldap_set_rebind_proc()... (cached) 2 checking for ldap_kerberos_bind_s... (cached) no checking for ldap_kerberos_bind1... (cached) no checking for ldap_kerberos_bind1_s... (cached) no checking for ldap_kerberos_bind2... (cached) no checking for ldap_kerberos_bind2_s... (cached) no checking for ldap_enable_cache... (cached) yes checking for ldap_disable_cache... (cached) yes checking for ldap_set_cache_options... (cached) yes checking for ldap_destroy_cache... (cached) yes checking for ldap_flush_cache... (cached) yes checking for ldap_uncache_entry... (cached) yes checking for ldap_uncache_request... (cached) yes checking whether the LDAP type is opaque... (cached) yes checking for ldap_modrdn2_s... (cached) yes checking for ldap_modrdn2... (cached) yes checking for ldap_init_templates... (cached) yes checking for disptmpl.h... (cached) yes checking python makefile... ./Misc/Makefile.python-1.4 creating ./config.status creating Modules/Setup creating Makefile creating Modules/config.h Modules/config.h is unchanged bootstrapping makefile rm -f *.o *~ rm -f *.a tags TAGS config.c Makefile.pre python sedscript rm -f *.so *.sl so_locations VERSION=`python -c "import sys; print sys.version[:3]"`; \ installdir=`python -c "import sys; print sys.prefix"`; \ exec_installdir=`python -c "import sys; print sys.exec_prefix"`; \ make -f ./Makefile.pre.in VPATH=. srcdir=. \ VERSION=$VERSION \ installdir=$installdir \ exec_installdir=$exec_installdir \ Makefile make[1]: Entering directory `/home/poussin/python/python-ldap-1.10alpha3/Modules' make[1]: *** No rule to make target `/usr/lib/python2.0/config/Makefile', needed by `sedscript'. Stop. make[1]: Leaving directory `/home/poussin/python/python-ldap-1.10alpha3/Modules'make: *** [boot] Error 2 [poussin at wang python-ldap-1.10alpha3]$ -------------- next part -------------- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:601: checking for gcc configure:714: checking whether the C compiler (gcc ) works configure:730: gcc -o conftest conftest.c 1>&5 configure:756: checking whether the C compiler (gcc ) is a cross-compiler configure:761: checking whether we are using GNU C configure:770: gcc -E conftest.c configure:789: checking whether gcc accepts -g configure:827: checking for python configure:862: checking python version configure:872: checking python install prefix configure:925: checking for socket configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:925: checking for gethostbyname configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:925: checking for inet_addr configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:925: checking for inet_ntoa configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:925: checking for connect configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:1027: checking for fmod configure:1055: gcc -o conftest -g -O2 conftest.c 1>&5 /tmp/ccGWSUSA.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1049: undefined reference to `fmod' collect2: ld returned 1 exit status configure: failed program was: #line 1032 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char fmod(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char fmod(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_fmod) || defined (__stub___fmod) choke me #else fmod(); #endif ; return 0; } configure:1082: checking for fmod in -lm configure:1101: gcc -o conftest -g -O2 conftest.c -lm 1>&5 configure:1027: checking for floor configure:1055: gcc -o conftest -g -O2 conftest.c -lm 1>&5 configure:1136: checking for krb_mk_req configure:1164: gcc -o conftest -g -O2 conftest.c -lm 1>&5 /tmp/cckAtyNl.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1158: undefined reference to `krb_mk_req' collect2: ld returned 1 exit status configure: failed program was: #line 1141 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char krb_mk_req(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char krb_mk_req(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_krb_mk_req) || defined (__stub___krb_mk_req) choke me #else krb_mk_req(); #endif ; return 0; } configure:1190: checking for krb_mk_req in -lkrb configure:1209: gcc -o conftest -g -O2 conftest.c -lkrb -lm 1>&5 /usr/bin/ld: cannot find -lkrb collect2: ld returned 1 exit status configure: failed program was: #line 1198 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char krb_mk_req(); int main() { krb_mk_req() ; return 0; } configure:1233: checking for des_setkey configure:1261: gcc -o conftest -g -O2 conftest.c -lm 1>&5 /tmp/ccMKB5Ag.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1255: undefined reference to `des_setkey' collect2: ld returned 1 exit status configure: failed program was: #line 1238 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char des_setkey(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char des_setkey(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_des_setkey) || defined (__stub___des_setkey) choke me #else des_setkey(); #endif ; return 0; } configure:1287: checking for des_setkey in -ldes configure:1306: gcc -o conftest -g -O2 conftest.c -ldes -lm 1>&5 /usr/bin/ld: cannot find -ldes collect2: ld returned 1 exit status configure: failed program was: #line 1295 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char des_setkey(); int main() { des_setkey() ; return 0; } configure:1353: checking for library containing ber_free configure:1371: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lm 1>&5 /tmp/ccbq1MWm.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1367: undefined reference to `ber_free' collect2: ld returned 1 exit status configure: failed program was: #line 1360 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ber_free(); int main() { ber_free() ; return 0; } configure:1393: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -llber -lm 1>&5 configure:1415: checking for library containing ldap_open configure:1433: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -llber -lm 1>&5 /tmp/ccYdFuKr.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1429: undefined reference to `ldap_open' collect2: ld returned 1 exit status configure: failed program was: #line 1422 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_open(); int main() { ldap_open() ; return 0; } configure:1455: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1476: checking for ldap_open configure:1504: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1525: checking how to run the C preprocessor configure:1546: gcc -E -I/home/poussin/ldap-3.3/include conftest.c >/dev/null 2>conftest.out configure:1606: checking for ldap.h configure:1616: gcc -E -I/home/poussin/ldap-3.3/include conftest.c >/dev/null 2>conftest.out configure:1640: checking for lber.h configure:1650: gcc -E -I/home/poussin/ldap-3.3/include conftest.c >/dev/null 2>conftest.out configure:1675: checking number of arguments to ldap_set_rebind_proc() configure:1688: gcc -c -g -O2 -I/home/poussin/ldap-3.3/include conftest.c 1>&5 configure:1714: checking for ldap_kerberos_bind_s configure:1742: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 /tmp/ccxsOz0J.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1736: undefined reference to `ldap_kerberos_bind_s' collect2: ld returned 1 exit status configure: failed program was: #line 1719 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char ldap_kerberos_bind_s(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_kerberos_bind_s(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_ldap_kerberos_bind_s) || defined (__stub___ldap_kerberos_bind_s) choke me #else ldap_kerberos_bind_s(); #endif ; return 0; } configure:1714: checking for ldap_kerberos_bind1 configure:1742: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 /tmp/ccXmynxo.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1736: undefined reference to `ldap_kerberos_bind1' collect2: ld returned 1 exit status configure: failed program was: #line 1719 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char ldap_kerberos_bind1(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_kerberos_bind1(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_ldap_kerberos_bind1) || defined (__stub___ldap_kerberos_bind1) choke me #else ldap_kerberos_bind1(); #endif ; return 0; } configure:1714: checking for ldap_kerberos_bind1_s configure:1742: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 /tmp/ccfvtyV2.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1736: undefined reference to `ldap_kerberos_bind1_s' collect2: ld returned 1 exit status configure: failed program was: #line 1719 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char ldap_kerberos_bind1_s(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_kerberos_bind1_s(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_ldap_kerberos_bind1_s) || defined (__stub___ldap_kerberos_bind1_s) choke me #else ldap_kerberos_bind1_s(); #endif ; return 0; } configure:1714: checking for ldap_kerberos_bind2 configure:1742: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 /tmp/ccb0RtYJ.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1736: undefined reference to `ldap_kerberos_bind2' collect2: ld returned 1 exit status configure: failed program was: #line 1719 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char ldap_kerberos_bind2(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_kerberos_bind2(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_ldap_kerberos_bind2) || defined (__stub___ldap_kerberos_bind2) choke me #else ldap_kerberos_bind2(); #endif ; return 0; } configure:1714: checking for ldap_kerberos_bind2_s configure:1742: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 /tmp/ccJSOPNq.o: In function `main': /home/poussin/python-ldap-1.10alpha3/configure:1736: undefined reference to `ldap_kerberos_bind2_s' collect2: ld returned 1 exit status configure: failed program was: #line 1719 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char ldap_kerberos_bind2_s(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_kerberos_bind2_s(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_ldap_kerberos_bind2_s) || defined (__stub___ldap_kerberos_bind2_s) choke me #else ldap_kerberos_bind2_s(); #endif ; return 0; } configure:1773: checking for ldap_enable_cache configure:1801: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1773: checking for ldap_disable_cache configure:1801: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1773: checking for ldap_set_cache_options configure:1801: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1773: checking for ldap_destroy_cache configure:1801: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1773: checking for ldap_flush_cache configure:1801: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1773: checking for ldap_uncache_entry configure:1801: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1773: checking for ldap_uncache_request configure:1801: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1827: checking whether the LDAP type is opaque configure:1840: gcc -c -g -O2 -I/home/poussin/ldap-3.3/include conftest.c 1>&5 configure:1864: checking for ldap_modrdn2_s configure:1892: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1864: checking for ldap_modrdn2 configure:1892: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1864: checking for ldap_init_templates configure:1892: gcc -o conftest -g -O2 -I/home/poussin/ldap-3.3/include -L/home/poussin/ldap-3.3/libraries conftest.c -lldap -llber -lm 1>&5 configure:1920: checking for disptmpl.h configure:1930: gcc -E -I/home/poussin/ldap-3.3/include conftest.c >/dev/null 2>conftest.out configure:2038: checking python makefile From jmlittle at mac.com Tue Sep 25 21:39:22 2001 From: jmlittle at mac.com (jmlittle at mac.com) Date: Tue, 25 Sep 2001 12:39:22 -0700 Subject: Make problem: Makefile target missing in "Modules" directory In-Reply-To: <01092521261601.03527@wang> Message-ID: <050026BD-B1ED-11D5-9700-0003930B38C0@mac.com> the latest open-it.org SRPMs for python-ldap do let you specify the version of Python to build against based on the PYTHON environment variable. These changes to the spec were submitted to me and so I can't take credit for them, but it may go along way to solving your problems. On Tuesday, September 25, 2001, at 06:26 PM, Arnaud Fausse wrote: > Hi, > > I would like to use the LDAP_Python library and I downloaded the > sources. > My platform is x86 Linux Mandrake 8.0. > I built the full OpenLDAP 2.0.11 package without difficulties, same for > LDAP- > 3.3. By the way, I use Python 2.0. > I try to build the Python-Ldap in my home directory (name > '/home/poussin') > I run the configure command: ./configure ...with tokens for lib and > include > locations. > Configuration script seems OK, but 'make' fails on the 'Modules' part > where > there is no target. (same effect being root or not). > Below you find: > - the console display > - the config log as attached doc. > Can you help me ? > Did I miss something obvious ? > Is there anyboday who can help me ? > Thanks in advance for your help > Arnaud > ------------------------------- > console log > > [poussin at wang python-ldap-1.10alpha3]$ ./configure > loading cache ./config.cache > checking for gcc... (cached) gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... (cached) yes > checking whether gcc accepts -g... (cached) yes > (cached) checking python version... (cached) 2.0 > checking python install prefix... (cached) /usr > checking for /tmp/ldap-pfx... no > checking for socket... (cached) yes > checking for gethostbyname... (cached) yes > checking for inet_addr... (cached) yes > checking for inet_ntoa... (cached) yes > checking for connect... (cached) yes > checking for fmod... (cached) no > checking for fmod in -lm... (cached) yes > checking for floor... (cached) yes > checking for krb_mk_req... (cached) no > checking for krb_mk_req in -lkrb... (cached) no > checking for des_setkey... (cached) no > checking for des_setkey in -ldes... (cached) no > checking for library containing ber_free... (cached) -llber > checking for library containing ldap_open... (cached) -lldap > checking for ldap_open... (cached) yes > checking how to run the C preprocessor... (cached) gcc -E > checking for ldap.h... (cached) yes > checking for lber.h... (cached) yes > checking number of arguments to ldap_set_rebind_proc()... (cached) 2 > checking for ldap_kerberos_bind_s... (cached) no > checking for ldap_kerberos_bind1... (cached) no > checking for ldap_kerberos_bind1_s... (cached) no > checking for ldap_kerberos_bind2... (cached) no > checking for ldap_kerberos_bind2_s... (cached) no > checking for ldap_enable_cache... (cached) yes > checking for ldap_disable_cache... (cached) yes > checking for ldap_set_cache_options... (cached) yes > checking for ldap_destroy_cache... (cached) yes > checking for ldap_flush_cache... (cached) yes > checking for ldap_uncache_entry... (cached) yes > checking for ldap_uncache_request... (cached) yes > checking whether the LDAP type is opaque... (cached) yes > checking for ldap_modrdn2_s... (cached) yes > checking for ldap_modrdn2... (cached) yes > checking for ldap_init_templates... (cached) yes > checking for disptmpl.h... (cached) yes > checking python makefile... ./Misc/Makefile.python-1.4 > creating ./config.status > creating Modules/Setup > creating Makefile > creating Modules/config.h > Modules/config.h is unchanged > bootstrapping makefile > rm -f *.o *~ > rm -f *.a tags TAGS config.c Makefile.pre python sedscript > rm -f *.so *.sl so_locations > VERSION=`python -c "import sys; print sys.version[:3]"`; \ > installdir=`python -c "import sys; print sys.prefix"`; \ > exec_installdir=`python -c "import sys; print sys.exec_prefix"`; \ > make -f ./Makefile.pre.in VPATH=. srcdir=. \ > VERSION=$VERSION \ > installdir=$installdir \ > exec_installdir=$exec_installdir \ > Makefile > make[1]: Entering directory > `/home/poussin/python/python-ldap-1.10alpha3/Modules' > make[1]: *** No rule to make target > `/usr/lib/python2.0/config/Makefile', > needed by `sedscript'. Stop. > make[1]: Leaving directory > `/home/poussin/python/python-ldap-1.10alpha3/Modules'make: *** [boot] > Error 2 > [poussin at wang python-ldap-1.10alpha3]$ > From michael at stroeder.com Thu Sep 27 17:32:43 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Sep 2001 17:32:43 +0200 Subject: Make problem: Makefile target missing in "Modules" directory References: <01092521261601.03527@wang> Message-ID: <3BB3469B.4CB0A744@stroeder.com> Arnaud Fausse wrote: > > I would like to use the LDAP_Python library and I downloaded the sources. > My platform is x86 Linux Mandrake 8.0. > I built the full OpenLDAP 2.0.11 package without difficulties, BTW: You can't build the current python-ldap with OpenLDAP 2.0.x libs without applying additional patches. Grabbing the right patches is somewhat tricky. Ciao, Michael P.S.: I'm somewhat sick of people asking why this or that premature Red Hat RPM built with OpenLDAP 2 libs and issued months ago is not working with web2ldap... From jmlittle at mac.com Thu Sep 27 17:40:04 2001 From: jmlittle at mac.com (jmlittle at mac.com) Date: Thu, 27 Sep 2001 08:40:04 -0700 Subject: Make problem: Makefile target missing in "Modules" directory In-Reply-To: <3BB3469B.4CB0A744@stroeder.com> Message-ID: please then comment on why _MY_ RPMs are not mature and/or lack which patches to not work with web2ldap. I'm here to help make them stable and not make them useless, afterall. On Thursday, September 27, 2001, at 08:32 AM, Michael Str?der wrote: > Arnaud Fausse wrote: >> >> I would like to use the LDAP_Python library and I downloaded the >> sources. >> My platform is x86 Linux Mandrake 8.0. >> I built the full OpenLDAP 2.0.11 package without difficulties, > > BTW: You can't build the current python-ldap with OpenLDAP 2.0.x > libs without applying additional patches. Grabbing the right patches > is somewhat tricky. > > Ciao, Michael > > P.S.: I'm somewhat sick of people asking why this or that premature > Red Hat RPM built with OpenLDAP 2 libs and issued months ago is not > working with web2ldap... > > From michael at stroeder.com Thu Sep 27 21:03:52 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Sep 2001 21:03:52 +0200 Subject: Make problem: Makefile target missing in "Modules" directory References: Message-ID: <3BB37818.4B406AE9@stroeder.com> jmlittle at mac.com wrote: > > please then comment on why _MY_ RPMs are not mature and/or lack which > patches to not work with web2ldap. I'm here to help make them stable and > not make them useless, afterall. 1. I'm not sure if these RPMs are _your_ RPMs. 2. I have no clue which patches you are providing nowadays with _your_ RPMs. But many people are asking why web2ldap chokes with an exception when setting some attributes which are not available with OpenLDAP 2 libs. Most times it turns out that they are using (older?) pre-built RPMs linked against OpenLDAP 2 libs. I usually don't track down which particular RPMs they are using. Nor do I track down which attributes are supported and which are not by that RPM version. Unfortunately they are reaching my mailbox. Not the mailbox of the package maintainer. Whoever that is... Ciao, Michael. From jlittle at open-it.org Thu Sep 27 21:09:20 2001 From: jlittle at open-it.org (Joe Little) Date: Thu, 27 Sep 2001 12:09:20 -0700 Subject: Make problem: Makefile target missing in "Modules" directory In-Reply-To: <3BB37818.4B406AE9@stroeder.com> Message-ID: <27D5A03A-B37B-11D5-B842-0003930B38C0@open-it.org> How about you direct them to me.. I'll make sure that they try/use my RPMs, and if they don't match up well enough, we'll work on them until they do.. On Thursday, September 27, 2001, at 12:03 PM, Michael Str?der wrote: > jmlittle at mac.com wrote: >> >> please then comment on why _MY_ RPMs are not mature and/or lack which >> patches to not work with web2ldap. I'm here to help make them stable >> and >> not make them useless, afterall. > > 1. I'm not sure if these RPMs are _your_ RPMs. > 2. I have no clue which patches you are providing nowadays with > _your_ RPMs. > > But many people are asking why web2ldap chokes with an exception > when setting some attributes which are not available with OpenLDAP 2 > libs. Most times it turns out that they are using (older?) pre-built > RPMs linked against OpenLDAP 2 libs. I usually don't track down > which particular RPMs they are using. Nor do I track down which > attributes are supported and which are not by that RPM version. > > Unfortunately they are reaching my mailbox. Not the mailbox of the > package maintainer. Whoever that is... > > Ciao, Michael. > >