From david.leonard at csee.uq.edu.au Wed Jul 26 02:10:47 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Wed, 26 Jul 2000 10:10:47 +1000 (EST) Subject: PerLDAP compat Message-ID: I was looking at OO models of X.500 directories and came acrosss Perl's LDAP module and wondered if a compatibility library could be useful to anyone converting their perl code to python :) :) its not finished yet but you can see the gist of the api below. any comments? a waste of time? The Perl API is documented at http://developer.netscape.com/tech/directory/perldap_docs/Conn.html http://developer.netscape.com/tech/directory/perldap_docs/Entry.html # python '''PerLDAP-like interface to the Python LDAP library ''' class Conn: def __init__(self, host, port = str(_ldap.PORT), bind = '', pswd = '', cert = ldap.AUTH_SIMPLE): self.host, self.port, self.binf = host, port, bind self._l = _ldap.open(host, int(port)) self._l.bind_s(bind, pswd, cert) def search(self, base, scope, pattern): '''search(base, scope, pattern) -> Entry''' self._context = self._l.search(scope, pattern) return self.nextEntry() def searchURL(self, url): '''searchURL(url) -> Entry''' def nextEntry(self): '''nextEntry() -> Entry''' ret = self._l.result(self._context) if ret[0] == _ldap.RES_SEARCH_RESULT: del self._context return None assert ret[0] == _ldap.RES_SEARCH_ENTRY return Entry(ret[1]) def update(self, entry): '''update(entry) -> int''' def add(self, entry): '''add(entry) -> int''' def delete(self, entry): '''delete(entry) -> int''' def close(self): '''close() -> Entry''' def modifyRDN(self, rdn, dn): '''modifyRDN(rdn, dn) -> Entry''' def isURL(self, url): '''isURL(url) -> int''' def getLD(self): '''getLD() -> fd int''' def getErrorCode(self): '''getErrorCode() -> int''' def getErrorString(self): '''getErrorString() -> string''' def printError(self): '''printError()''' def setRebindProc(self, func): '''setRebindProc(func)''' def setDefaultRebindProc(self): '''setDefaultRebindProc()''' class Entry: def attrModified(self, attr): '''attrModified(attr)''' def isModified(self, attr): '''isModified(attr) -> int''' def remove(self, attr): '''remove(attr)''' def removeValue(self, attr, val): '''removeValue(attr, val)''' def addValue(self, attr, val): '''addValue(attr, val)''' def hasValue(self, attr, val, ignorecase = 0): '''hasValue(attr, val [, ignorecase]) -> int''' def matchValue(self, attr, ignorecase = 0): '''matchValue(attr [, ignorecase]) -> int''' def setDN(self, dn): '''setDN(dn)''' def getDN(self, dn): '''getDN(dn) -> string''' def size(self, attr): '''size(attr) -> int''' def exists(self, attr): '''exists(attr) -> int''' def printLDIF(self): '''printLDIF(self)''' def __getitem__(self, attr): pass def __setitem__(self, attr, value): pass -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 Curses! - Mojo Jojo From davidma at eskimo.com Tue Jul 4 06:37:34 2000 From: davidma at eskimo.com (David Margrave) Date: Mon, 03 Jul 2000 21:37:34 -0700 Subject: more memory leakage References: Message-ID: <39616A0E.BE697812@eskimo.com> looks like you've got it. I've tested this change, doing thousands of searches and my process doesn't grow in size by one byte (where as before, it grew to 20 MB after about 7k searches) also, that problem I mentioned earlier with ldap.delete_s not working on referrals (though it returned success!) was an openldap bug, that is fixed in 1.2.10 or possibly a bit earlier. David Leonard wrote: > how does this look? > > --- message.c 1999/09/19 01:53:21 1.7 > +++ message.c 2000/07/04 00:48:09 > @@ -45,6 +45,8 @@ > #endif /* !CIDICT */ > > PyTuple_SetItem( entrytuple, 0, PyString_FromString(dn) ); > + free(dn); > + > PyTuple_SetItem( entrytuple, 1, attrdict ); > > PyList_SetItem( result, entry_index, entrytuple ); > @@ -64,7 +66,6 @@ > PyMapping_SetItemString( attrdict, attr, valuelist ); > } > > - Py_INCREF( valuelist ); > if (bvals != NULL) { > int i; > for (i=0; bvals[i]; i++) { > @@ -74,10 +75,10 @@ > bvals[i]->bv_val, bvals[i]->bv_len > ); > PyList_Append( valuelist, valuestr ); > + Py_DECREF(valuestr); > } > ber_bvecfree(bvals); > } > - Py_DECREF( valuelist ); > } > } > ldap_msgfree( m ); > On Mon, 3 Jul 2000, David Leonard typed thusly: > > > > > these look great! i will have to verify them.. > > some C functions incref their args for you, and others don't. there are > > docs on which are which. > > > > i think maybe i should convert things like PyList_Append to PySequence_SetItem > > (with an appropriately allocated List). apparently they all have consistent > > incref semantics and its much easier to visually check.. > > > > having problems with cvs at the moment... > > > > 209.81.8.43: Connection timed out > > > > On Mon, 3 Jul 2000, David Margrave typed thusly: > > > > > line 80 on should be: > > > > > > Py_DECREF( valuelist ); > > > } > > > free(dn); > > > } > > > ldap_msgfree( m ); > > > return result; > > > } > > > > > > this helps a bit, but something is still leaking memory like > > > crazy elsewhere. > > > > > > I'm not able to do CVS just this moment, so could you add > > > that in? > > > > > > > Also in message.c, I added a Py_DECREF for valuestr: > > > > > > for (i=0; bvals[i]; i++) { > > > PyObject *valuestr; > > > > > > valuestr = PyString_FromStringAndSize( > > > bvals[i]->bv_val, bvals[i]->bv_len > > > ); > > > PyList_Append( valuelist, valuestr ); > > > Py_DECREF(valuestr); > > > } > > > > > > I'm not an expert on the python reference counting system, but adding this > > > one has cleared up the memory leak (on openldap 1.2.10, compiled without > > > caching and without threads. Haven't tried with yet..) I did try adding > > > Py_DECREF in a couple other places and got core dumps. For some reason, > > > it seems to be valid to do it here. Perhaps because the object in > > > question is not a mapping or sequence? Anyhow, memory consumption on my > > > program that does thousands of searches no longer goes up monotonically! > > > > > > Dave > > > > > > > > > -- > David Leonard David.Leonard at csee.uq.edu.au > Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 > The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ > QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 From david.leonard at csee.uq.edu.au Wed Jul 26 01:15:54 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Wed, 26 Jul 2000 09:15:54 +1000 (EST) Subject: simple ldap query In-Reply-To: <372E9068C013D211891F00805F9FD1C2047939B9@mail3.oulan.ou.edu> Message-ID: On Tue, 25 Jul 2000, Leichtman, David J typed thusly: > > I was wondering if I could enlist your help with a rather simple thing that > I haven't been able to figure out through the python - LDAP documentation. > > I've been trying to put together a very simple auth module using our LDAP > server at University of Oklahoma. My problem is that I don't know exactly > how to format the dn, but that's not really my problem. The real problem is > that I can't figure out how to get good error info. I can't really figure > out what the right way to call the bind is in order to autheticate with it. > I seem to always get an exception, but it never matches any of the ones that > are listed in the documentation, and I don't know how to just list all > raised exceptions. what exception exactly is raised? > Maybe you can help, or just point out a grossly negligent error on my part. since 1.9, all exceptions raised are subclasses of the base exception _ldap.LDAPError (except for PARAM_ERROR, NO_SUCH_OBJECT and NO_SUCH_ATTRIBUTE which are (incorrectly) mapped to python exceptions ValueError, NameError & AttributeError). This is tersely refered to in the documentation (look for LDAPError). But here is some python code to show all the errors. import types, _ldap for s in dir(_ldap): o = getattr(_ldap, s) if type(o) is types.ClassType and issubclass(o, _ldap.LDAPError): print s, o When an exception object/value/traceback triple is raised from an LDAP error, the value is a dictionary with three string keys: 'desc', 'matched' (optional) and 'info' (also optional). if you have openldap installed, the manual page `ldap_perror(3)' describes each error type in a bit more detail. -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 Curses! - Mojo Jojo From david.leonard at csee.uq.edu.au Wed Jul 26 12:09:21 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Wed, 26 Jul 2000 20:09:21 +1000 (EST) Subject: PerLDAP compat In-Reply-To: <397E9538.BAA56713@stroeder.com> Message-ID: On Wed, 26 Jul 2000, Michael Str?der typed thusly: > David Leonard wrote: > > > > def printLDIF(self): > > '''printLDIF(self)''' > > I can contribute some code for reading and writing LDIF (see > gzipped-attachment). Maybe you want to include this module in your > software repository. yes - looks good. will include. -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 Curses! - Mojo Jojo From michael at stroeder.com Thu Jul 27 11:22:10 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Jul 2000 11:22:10 +0200 Subject: Roadmap for ldapmodule Message-ID: <397FFF42.E0DB9C96@stroeder.com> HI! I see a strong need for a defined roadmap for python-ldap. The current situation on the web pages looks rather confusing for users of the ldapmodule. Some suggestions (and I hope some silent readers of this list jump into this discussion): 1. Module names (high priority): -------------------------------- When renaming was done from ldap to _ldap I did not thought about it thoroughly enough. But now it seems to me that it breaks a lot of existing code and produces much confusion when updating. There are some web articles describing example code etc., too (e.g. http://www.sunworld.com/sunworldonline/swol-01-2000/swol-01-ldap3_p.html). E.g. S.u.S.E. delivers ldapmodule 1.5 with their Linux distribution and it's much easier to explain users how to upgrade if the old naming is used. Please, rename _ldap back to ldap and rename Fog's stuff to LDAPObjects, ldapobj, ldaplib or a similar name since Fog's stuff is not widely used or documented up to now. 2. CVS (high priority): ----------------------- The CVS repository is not very clear for newbies who don't know the history. ldap-module/ Seems to be the old stuff. We should get rid of this directory completely to avoid confusion. python-ldap/ldaplib/ python-ldap/ldapmodule/ These both directories should be at top of CVS tree since the project is already called python-ldap. A sub-directory python-ldap/ seems redundant if ldap-module/ is removed. BTW: ldapmodule and ldaplib should be distributed in separated release packages. IMHO the CVS repository could be simplified and expanded to htdocs/ ldaplib/ ldapmodule/ applications/ demos/ New directories applications/ and demos/ should be created for existing applications (e.g. Fog's lappo going into applications/lappo/) and small example code snippets for tutorial purpose going into demos/. 3. Release of C-module (high priority): --------------------------------------- Make a new stable, well tested and compatible release of the C ldapmodule AS SOON AS POSSIBLE and publish it on the SourceForge web page. Especially the fixes for memory leaking etc. are important for serious application developers. This could contain Fog's stuff marked as still being experimental. This is highly needed as a base for package maintainers like mirko.zeibig at inka.de (see Red Hat-packages on http://www.webideal.de/ldap/) or S.u.S.E (I will trigger them both). 4. SSL (medium priority): ------------------------- There are a lot of applications where confidentiality of transmitted data has to be guaranteed => LDAP over SSL is highly needed. ldapmodule can be linked to Netscape SDK which has SSL support. Also it's worth looking at OpenLDAP 2.0's new API because this will be the new standard API for LDAP. Although I can't help with C programming I can help with investigating the needs for certificate handling etc. 5. LDAPObjects (low priority): ------------------------------ We have to review Fog's work (hopefully I have the time!) to establish a standard Pythonish, re-usable and robust class library for LDAP applications. 6. Distributing with Python's standard lib (low priority): From fog at mixadlive.com Thu Jul 27 11:48:56 2000 From: fog at mixadlive.com (Federico Di Gregorio) Date: Thu, 27 Jul 2000 11:48:56 +0200 Subject: Roadmap for ldapmodule In-Reply-To: <397FFF42.E0DB9C96@stroeder.com>; from michael@stroeder.com on Thu, Jul 27, 2000 at 11:22:10AM +0200 References: <397FFF42.E0DB9C96@stroeder.com> Message-ID: <20000727114855.F19061@mixadlive.com> Scavenging the mail folder uncovered Michael Str?der's letter: > Please, rename _ldap back to ldap and rename Fog's stuff to > LDAPObjects, ldapobj, ldaplib or a similar name since Fog's stuff is > not widely used or documented up to now. standard for python extension written in C is _ldap in a ldapmodule.so library. if you simply do an "import ldap" you automatically get a "from _ldap import *" and all the previous code continues working. **no need** to change a single line of code. > 2. CVS (high priority): > ----------------------- > The CVS repository is not very clear for newbies who don't know the > history. > > ldap-module/ > > Seems to be the old stuff. We should get rid of this directory > completely to avoid confusion. > > python-ldap/ldaplib/ > python-ldap/ldapmodule/ > > These both directories should be at top of CVS tree since the > project is already called python-ldap. A sub-directory python-ldap/ > seems redundant if ldap-module/ is removed. BTW: ldapmodule and > ldaplib should be distributed in separated release packages. i agree. > New directories applications/ and demos/ should be created for > existing applications (e.g. Fog's lappo going into > applications/lappo/) and small example code snippets for tutorial > purpose going into demos/. i would better like to keep code snippets and applications (lappo) requiring ldaplib under ldaplib. else an user will download the C module and demos only and then write us the the demos do not work... > 5. LDAPObjects (low priority): > ------------------------------ > We have to review Fog's work (hopefully I have the time!) to > establish a standard Pythonish, re-usable and robust class library > for LDAP applications. i agree (on the review part.) my work on LDAPObject is stalled mainly because i received no input and (apart from lappo) i don't use my own code very much (waiting for ssl, then we'll move all out ns to ldap and will be a different story...) > 6. Distributing with Python's standard lib (low priority): > From michael at stroeder.com Thu Jul 27 11:53:29 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Jul 2000 11:53:29 +0200 Subject: Error building from CVS Message-ID: <39800699.4151B476@stroeder.com> HI! I updated my CVS directory copy of python-ldap yesterday and tried to build ldapmodule against my installed OpenLDAP 1.2.11 libs. 1. I was confused wether to use ldap-module/ldapmodule/ or python-ldap/ldapmodule/. 2. Without having any seriously knowledge of autoconf I created a configure script by running autoconf in python-ldap/ldapmodule/. I both directories the build failed with: michael at junker:~/temp/python-ldap/ldap-module/ldapmodule > make gcc -fpic -DLDAP_REFERRALS -DWITH_KERBEROS -O2 -m486 -I/usr/include/python1.5 -I/usr/include/python1.5 -DHAVE_CONFIG_H -c ./LDAPObject.c ./LDAPObject.c: In function `l_ldap_modrdn': ./LDAPObject.c:1069: too many arguments to function `ldap_modrdn' ./LDAPObject.c: In function `l_ldap_modrdn_s': ./LDAPObject.c:1093: too many arguments to function `ldap_modrdn_s' make: *** [LDAPObject.o] Error 1 Ciao, Michael. From fog at mixadlive.com Thu Jul 27 12:14:10 2000 From: fog at mixadlive.com (Federico Di Gregorio) Date: Thu, 27 Jul 2000 12:14:10 +0200 Subject: Roadmap for ldapmodule In-Reply-To: <39800AD4.2D85233E@stroeder.com>; from michael@stroeder.com on Thu, Jul 27, 2000 at 12:11:32PM +0200 References: <397FFF42.E0DB9C96@stroeder.com> <20000727114855.F19061@mixadlive.com> <39800AD4.2D85233E@stroeder.com> Message-ID: <20000727121410.I19061@mixadlive.com> Scavenging the mail folder uncovered Michael Str?der's letter: > Federico Di Gregorio wrote: > > i would better like to keep code snippets and applications (lappo) > > requiring ldaplib under ldaplib. > > IMHO packages of the module distributions should be kept small. > Well, simple demos could be integrated into the modules but not > larger applications. > > > else an user will download the C > > module and demos only and then write us the the demos do not work... > > A simple table listing which modules are needed by a specific demo > or application helps with that problem. It's just a matter of proper > docs and it's really simple in this particular case (there won't be > so many different demos and applications, I guess). true. it is fine for me. (as long as David agrees.) > > > 6. Distributing with Python's standard lib (low priority): > > > > i don't agree on that. > > Any good reason why? not really. but maintaining a package inside a bigger one, that works on multiple platforms not widely available to the software author is not an easy task. but that's David's problem, right? ciao, federico -- Federico Di Gregorio MIXAD LIVE System Programmer fog at mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog at debian.org The reverse side also has a reverse side. -- Japanese proverb From michael at stroeder.com Thu Jul 27 12:11:32 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Jul 2000 12:11:32 +0200 Subject: Roadmap for ldapmodule References: <397FFF42.E0DB9C96@stroeder.com> <20000727114855.F19061@mixadlive.com> Message-ID: <39800AD4.2D85233E@stroeder.com> Federico Di Gregorio wrote: > > Scavenging the mail folder uncovered Michael Str?der's letter: > > > Please, rename _ldap back to ldap > > if you simply do an "import ldap" you automatically get a > "from _ldap import *" and all the previous code continues working. > **no need** to change a single line of code. Oh, I see. Didn't know that. > > New directories applications/ and demos/ should be created for > > existing applications (e.g. Fog's lappo going into > > applications/lappo/) and small example code snippets for tutorial > > purpose going into demos/. > > i would better like to keep code snippets and applications (lappo) > requiring ldaplib under ldaplib. IMHO packages of the module distributions should be kept small. Well, simple demos could be integrated into the modules but not larger applications. > else an user will download the C > module and demos only and then write us the the demos do not work... A simple table listing which modules are needed by a specific demo or application helps with that problem. It's just a matter of proper docs and it's really simple in this particular case (there won't be so many different demos and applications, I guess). > > 6. Distributing with Python's standard lib (low priority): > > i don't agree on that. Any good reason why? > distribution makers like redhat or debian will > bundle python-ldap anyway. But think of e.g. a Win32 distribution, FreeBSD ports or Python on AS/400. Up to now there are no package maintainers for those platforms. If python-ldap's modules are integrated into the Python distribution it makes life *much* easier on all platforms. Well, it's just a low-priority goal to be reached during the next year. > ah! and Win2000 Active Directory is not > compatible with standard ldap... There are different scopes of compability with LDAP. But that's another story probably off-topic here. Ciao, Michael. From michael at stroeder.com Thu Jul 27 12:44:56 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Jul 2000 12:44:56 +0200 Subject: Roadmap for ldapmodule References: <397FFF42.E0DB9C96@stroeder.com> <20000727114855.F19061@mixadlive.com> <39800AD4.2D85233E@stroeder.com> <20000727121410.I19061@mixadlive.com> Message-ID: <398012A8.F066232B@stroeder.com> Federico Di Gregorio wrote: > > > > > 6. Distributing with Python's standard lib (low priority): > > > > > > i don't agree on that. > > > > Any good reason why? > > not really. but maintaining a package inside a bigger one, that works > on multiple platforms not widely available to the software author is > not an easy task. but that's David's problem, right? But triggering all package maintainers is not an easy task either. It's not even an easy task to know them all. Ciao, Michael. From michael at stroeder.com Thu Jul 27 13:56:08 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Jul 2000 13:56:08 +0200 Subject: Roadmap for ldapmodule References: Message-ID: <39802358.FF873E60@stroeder.com> David Leonard wrote: > > i think using Python's own source tree structure as > a basis would be best. > > Demo/ > Doc/ > Lib/ > Module/ Ack. Looks reasonable. Let's do it! > Also I really don't think that this is the right place for > applications. Ack. I regarded lappo as application - one can regard it as demo. E.g. I would *not* want to add web2ldap into python-ldap's tree. Ok, what about the rest of the roadmap? Ciao, Michael. From david.leonard at csee.uq.edu.au Thu Jul 27 13:51:19 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Thu, 27 Jul 2000 21:51:19 +1000 (EST) Subject: Roadmap for ldapmodule In-Reply-To: <398012A8.F066232B@stroeder.com> Message-ID: yep. the current CVS directory structure is indeed clumsy. it got that way i think because some bad decisions were made (by me) early on, and with CVS, it is hard to rename directories. (i dont seem to have shell access to the sourceforge machine with the CVS repository otherwise I would do a mv or six!) i think using Python's own source tree structure as a basis would be best. michael's proposed structure is quite similar to this in semantics, and I liked it. renaming his to become consistent with Python's tree you get: Demo/ Doc/ Lib/ Module/ where Module/ contains .c files, Lib/ contains .py libraries, Demo/ contains some sample apps and Doc/ contains .tex files for documentation. This seems really reasonable to me. Also I really don't think that this is the right place for applications. unless you carefully describe such application as convenient ldap libraries :) (which is what the core of fog's gtk code could possible be described as.) otherwise, apps should be independent efforts (not too hard with sourcefogre) or kept in the Demo/ directory. d -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 Curses! - Mojo Jojo From michael at stroeder.com Thu Jul 27 20:23:44 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Jul 2000 20:23:44 +0200 Subject: directory structure changed References: Message-ID: <39807E30.BE0AA3E3@stroeder.com> David Leonard wrote: > > finally moved everything around. I recommend using the -dP flags for > cvs update when you next sync your trees. I did a complete checkout and it seems that all the old dirs are still there. I'm not a CVS expert but "remove" should do it after deleting them in your local dir. I tried a build by going into python-ldap/python-ldap/ and typed "autoheader", "autoconf" and "configure --prefix=/usr". The build failed with: gcc -fpic -DLDAP_REFERRALS -O2 -m486 -I/usr/include/python1.5 -I/usr/include/python1.5 -DHAVE_CONFIG_H -c ./linkedlist.c ./linkedlist.c:106: `objobjproc' undeclared here (not in a function) ./linkedlist.c:106: warning: excess elements in struct initializer ./linkedlist.c:106: warning: (near initialization for `default_methods') ./linkedlist.c:106: parse error before `0' make[1]: *** [linkedlist.o] Error 1 make[1]: Leaving directory `/home/michael/temp/python-ldap/python-ldap/Modules' make: *** [all] Error 2 Ciao, Michael. From david.leonard at csee.uq.edu.au Thu Jul 27 18:15:46 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Fri, 28 Jul 2000 02:15:46 +1000 (EST) Subject: directory structure changed Message-ID: okay, finally moved everything around. I recommend using the -dP flags for cvs update when you next sync your trees. i stuck an ldap.py in Lib, but that will go when fog is ready to move ldaplib/ldap to Lib/ldap also made a few misc changes to configure.. remember, you have to run autoheader before autoconf. d -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 Curses! - Mojo Jojo From david.leonard at csee.uq.edu.au Fri Jul 28 00:26:00 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Fri, 28 Jul 2000 08:26:00 +1000 (EST) Subject: directory structure changed In-Reply-To: <39807E30.BE0AA3E3@stroeder.com> Message-ID: On Thu, 27 Jul 2000, Michael Str?der typed thusly: > > finally moved everything around. I recommend using the -dP flags for > > cvs update when you next sync your trees. > > I did a complete checkout and it seems that all the old dirs are > still there. I'm not a CVS expert but "remove" should do it after > deleting them in your local dir. I tend to use 'cvs up -PAd' which deletes empty directories.. maybe there are leftover non-cvs files in ldapmodule/ ? you have to remove those by hand. or just 'rm -rf ldapmodule'.. :) > I tried a build by going into python-ldap/python-ldap/ and typed > "autoheader", "autoconf" and "configure --prefix=/usr". there's also 'autoreconf' i remember now: it does autoheader and autoconf for you! > The build failed with: > gcc -fpic -DLDAP_REFERRALS -O2 -m486 -I/usr/include/python1.5 > -I/usr/include/python1.5 -DHAVE_CONFIG_H -c ./linkedlist.c > ./linkedlist.c:106: `objobjproc' undeclared here (not in a function) > ./linkedlist.c:106: warning: excess elements in struct initializer > ./linkedlist.c:106: warning: (near initialization for > `default_methods') > ./linkedlist.c:106: parse error before `0' > make[1]: *** [linkedlist.o] Error 1 > make[1]: Leaving directory > `/home/michael/temp/python-ldap/python-ldap/Modules' > make: *** [all] Error 2 oops, I've been building with Python 1.6a2 .. -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 From michael at stroeder.com Thu Jul 27 12:11:32 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 27 Jul 2000 12:11:32 +0200 Subject: Roadmap for ldapmodule References: <397FFF42.E0DB9C96@stroeder.com> <20000727114855.F19061@mixadlive.com> Message-ID: <39800AD4.2D85233E@stroeder.com> Federico Di Gregorio wrote: > > Scavenging the mail folder uncovered Michael Str?der's letter: > > > Please, rename _ldap back to ldap > > if you simply do an "import ldap" you automatically get a > "from _ldap import *" and all the previous code continues working. > **no need** to change a single line of code. Oh, I see. Didn't know that. > > New directories applications/ and demos/ should be created for > > existing applications (e.g. Fog's lappo going into > > applications/lappo/) and small example code snippets for tutorial > > purpose going into demos/. > > i would better like to keep code snippets and applications (lappo) > requiring ldaplib under ldaplib. IMHO packages of the module distributions should be kept small. Well, simple demos could be integrated into the modules but not larger applications. > else an user will download the C > module and demos only and then write us the the demos do not work... A simple table listing which modules are needed by a specific demo or application helps with that problem. It's just a matter of proper docs and it's really simple in this particular case (there won't be so many different demos and applications, I guess). > > 6. Distributing with Python's standard lib (low priority): > > i don't agree on that. Any good reason why? > distribution makers like redhat or debian will > bundle python-ldap anyway. But think of e.g. a Win32 distribution, FreeBSD ports or Python on AS/400. Up to now there are no package maintainers for those platforms. If python-ldap's modules are integrated into the Python distribution it makes life *much* easier on all platforms. Well, it's just a low-priority goal to be reached during the next year. > ah! and Win2000 Active Directory is not > compatible with standard ldap... There are different scopes of compability with LDAP. But that's another story probably off-topic here. Ciao, Michael. From fog at mixadlive.com Thu Jul 27 15:00:44 2000 From: fog at mixadlive.com (Federico Di Gregorio) Date: Thu, 27 Jul 2000 15:00:44 +0200 Subject: Roadmap for ldapmodule In-Reply-To: ; from david.leonard@csee.uq.edu.au on Thu, Jul 27, 2000 at 10:37:41PM +1000 References: <39802358.FF873E60@stroeder.com> Message-ID: <20000727150044.J19061@mixadlive.com> Scavenging the mail folder uncovered David Leonard's letter: > > 5. LDAPObjects (low priority): > > ------------------------------ > > We have to review Fog's work (hopefully I have the time!) to > > establish a standard Pythonish, re-usable and robust class library > > for LDAP applications. > > i would like see a more general X.500 directory class and have > objectClasses more tightly coupled with python classes. that would be cool. > it might also be cool to wrap LDAP as a db give a look at .../ldaplib/ldap/schema. you'll find objectClasses and attributes encapsulated as python classes. they do nothing at now but the code in schema is already able to ask a v3 compatible server and build the full classes/attributes/syntaxes tree. ciao, federico -- Federico Di Gregorio MIXAD LIVE System Programmer fog at mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog at debian.org 99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me From david.leonard at csee.uq.edu.au Fri Aug 11 13:53:53 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Fri, 11 Aug 2000 21:53:53 +1000 (EST) Subject: Behaviour when object is not found In-Reply-To: <3993C4F8.1065608B@stroeder.com> Message-ID: On Fri, 11 Aug 2000, Michael Str?der typed thusly: > OpenLDAP 1.2.x when trying to read a non-existent entry ldapmodule > raised exception ldap.NO_SUCH_OBJECT which is very handy to handle > non-existing entries. > > With OpenLDAP 2.0beta ldapmodule returns an empty result list > instead which breaks existing code. I would expect that this is more > a OpenLDAP 2.0 issue but before I start a discussion on > openldap-devel at openldap.org I would like to understand exactly under > which conditions the exception ldap.NO_SUCH_OBJECT is raised. if ldap_search() or ldap_result() returns -1 AND the LDAP structure has its ld_errno field set to NO_SUCH_OBJECT, then that exception is raised. d -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 Curses! - Mojo Jojo From david.leonard at csee.uq.edu.au Mon Aug 14 05:47:23 2000 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Mon, 14 Aug 2000 13:47:23 +1000 (EST) Subject: 1.10alpha 'release' Message-ID: if you look at http://python-ldap.sourceforge.net/release.php you should be wonderstruck by a 1.10alpha "release". this has heaps of pesky memory leaks fixed, and a package for OpenBSD. if you have CVS access, please check out the new Build directory.. i'm not very up on linux or other OSs, so if you want to contribute a directory there for your favourite system, that would be great. the idea is to make a simple script that will build a release tarball fairly automatically. i've had a go at a linux one - it seems to build on the sourceforge linux server. python isn't installed on the freebsd server though, but when i get time, i'll build it myself. also I revamped the documentation area and will build a spiffy looking doc using the new latex macros. but it has some glitches i notice. so far, all that the package has is whats in Lib and the _ldapmodule. fog, or whoever, if you want the rest to be installed sensibly, please link it into the root Makefile.in. comments? d -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ E2A24DC6446E5779D7AFC41AA04E6401 Curses! - Mojo Jojo From michael at stroeder.com Mon Aug 14 11:40:32 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 14 Aug 2000 11:40:32 +0200 Subject: 1.10alpha 'release' References: Message-ID: <3997BE90.3D5B9628@stroeder.com> David Leonard wrote: > > if you look at http://python-ldap.sourceforge.net/release.php you > should be wonderstruck by a 1.10alpha "release". > > this has heaps of pesky memory leaks fixed, I assume that these sources contains the patches by Johannes. > please check out the new Build directory.. Very fine. I will make RPMs for recent S.u.S.E. Linux. > the idea is to make a > simple script that will build a release tarball fairly automatically. Hmm. I have to learn the RPM-ish things but I will send the shell scripts. > also I revamped the documentation area and will build a spiffy looking > doc using the new latex macros. Great. This leads to the question which things have to be done before releasing 1.10? 1. Testing: I tested the version of Johannes and it seems to work. I tested all operations (search, modify, add, modrdn, delete). Hmm, I'm thinking about writing a Python script which implements the BLITS test suite on a defined data set. This is a pretty boring job but would ease testing in the future. Can anybody else say something about how stable the current version is? 2. Update docs This is pretty much David's job. Especially the web page on his own page. We have to avoid that people download old python-ldap versions and report errors afterwards. > so far, all that the package has is whats in Lib and the _ldapmodule. I'm still not confident regarding the naming. IMHO the C-module should still be called ldapmodule.so and fog's stuff should be called ldaplib or whatever to be able to distribute both modules separately without having to mess with different ldap.py. Different ldap.py will cause nothing but troubles and boring FAQs by users. And I know that there's "from _ldap import *" in ldap.py but this does not import _ldap.__version__ and using "from module import *" is bad behaviour anyway. 3. Fog's schema stuff I had a short look into the schema stuff and after installing OpenLDAP 2.0beta I learned much more about schema definitions etc. It's much more complicated as I expected and current schema support in ldaplib is far from being close to it (hate to say this). E.g. you have to implement some kind of OID registry and reference all objects with numerical OIDs. For exercise purpose I started to write my own schema modules but got stuck by complexity. Supporting ALL features is pretty hard. I'm still learning and thinking. The question is if it's easier going to OpenLDAP 2.0 API with the C-module and get schema stuff from there... Ciao, Michael. From michael at stroeder.com Mon Aug 14 21:13:22 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 14 Aug 2000 21:13:22 +0200 Subject: 1.10alpha 'release' References: <3997BE90.3D5B9628@stroeder.com> <20000814164044.C2491@gmx.net> Message-ID: <399844D2.42340E7E@stroeder.com> Johannes Stezenbach wrote: > > Please also test error conditions/exceptions. It would be nasty > if a missing INCREF/surplus DECREF would make it dump core on > error conditions. When using web2ldap a lot of exceptions are caught. Up to now it looks stable. Yeah, this is not 100% sure. Anyway a BLITS test trys to address all cases. See: http://www.opennc.org/directory/mats/blits24/index.htm Ciao, Michael. From michael at stroeder.com Wed Aug 16 20:44:47 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 16 Aug 2000 20:44:47 +0200 Subject: BLITS Message-ID: <399AE11F.D95D9D8E@stroeder.com> HI! I'm in the process of implementing the BLITS test suite because I think there's a strong need for a well-defined test script. Testing the current and future releases is somewhat difficult because one can't be sure that all aspects are covered. I have a function framework derived from http://www.opennc.org/directory/mats/blits24/index.htm but the (simple) test functions itself have to be impemented now. Well, there are ~ 200(!) tests defined and I won't be able to implement them in a reasonable time frame myself. Here's the deal: For every function another person is willing to contribute I will implement one either. Before you're going to write your own test scripts spend a few minutes on writing a test function for blits.py and get one test function for free! ;-) We will get a nice test script for the Demo/ section of python-ldap. If you have some time send me an e-mail and I will organize who's going to develop which test function. The read-only functions are easy to implement if you have permanent Internet access to the test data set on ldap://nldap.com/O=IMC,C=US (X.500 name set). The test functions which need write access need the test data set uploaded to a LDAPv3 server like OpenLDAP 2.0 (for most tests OpenLDAP 1.2.x will be sufficient, too). Ciao, Michael. From michael at stroeder.com Wed Aug 16 20:44:47 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 16 Aug 2000 20:44:47 +0200 Subject: BLITS Message-ID: <399AE11F.D95D9D8E@stroeder.com> HI! I'm in the process of implementing the BLITS test suite because I think there's a strong need for a well-defined test script. Testing the current and future releases is somewhat difficult because one can't be sure that all aspects are covered. I have a function framework derived from http://www.opennc.org/directory/mats/blits24/index.htm but the (simple) test functions itself have to be impemented now. Well, there are ~ 200(!) tests defined and I won't be able to implement them in a reasonable time frame myself. Here's the deal: For every function another person is willing to contribute I will implement one either. Before you're going to write your own test scripts spend a few minutes on writing a test function for blits.py and get one test function for free! ;-) We will get a nice test script for the Demo/ section of python-ldap. If you have some time send me an e-mail and I will organize who's going to develop which test function. The read-only functions are easy to implement if you have permanent Internet access to the test data set on ldap://nldap.com/O=IMC,C=US (X.500 name set). The test functions which need write access need the test data set uploaded to a LDAPv3 server like OpenLDAP 2.0 (for most tests OpenLDAP 1.2.x will be sufficient, too). Ciao, Michael. From michael at stroeder.com Fri Aug 11 11:18:48 2000 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 11 Aug 2000 11:18:48 +0200 Subject: Behaviour when object is not found Message-ID: <3993C4F8.1065608B@stroeder.com> HI! I'm testing ldapmodule (CVS version) with OpenLDAP 2.0beta. With OpenLDAP 1.2.x when trying to read a non-existent entry ldapmodule raised exception ldap.NO_SUCH_OBJECT which is very handy to handle non-existing entries. With OpenLDAP 2.0beta ldapmodule returns an empty result list instead which breaks existing code. I would expect that this is more a OpenLDAP 2.0 issue but before I start a discussion on openldap-devel at openldap.org I would like to understand exactly under which conditions the exception ldap.NO_SUCH_OBJECT is raised. Ciao, Michael.