python-ldap-dev — discussion among developers

Re: Future of ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered Sascha Gresk's letter:
> 
> > I would suggest that ldapmodule stays as close to the C API as
> > possible with having exception for error handling just as it is
> > right now. Higher level abstractions (all kind of schema handling)
> > can be build into a separate Python class library (e.g. fog's
> > modules).
> > 
> 
> Implementing ...
> Now the discussion is : typemaps or classes ? 

are you duplicationg my work? pls, give a look on it...

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
           Nobody will ever need more than 640k RAM! -- Bill Gates, 1981
           Windows 95 needs at least 8 MB RAM.       -- Bill Gates, 1996
           Nobody will ever need Windows 95.       -- logical conclusion

Re: Future of ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered Michael Ströder's letter:
> I would suggest that ldapmodule stays as close to the C API as
> possible with having exception for error handling just as it is
> right now. Higher level abstractions (all kind of schema handling)
> can be build into a separate Python class library (e.g. fog's
> modules).

i agree. michael, last time you were suggesting various changes to
my implementation, mainly to deal with schema. can you elaborate a
little bit more? i think you had better ideas then me on the argument
and i don't want to start piling up code without your 

some general questions:

has somebody tried my wrapper module or the lappo client? i didn't
received any comments on both.

any release of python-ldap at the horizon? i like much better to release
and get feedback than try do do all right from the start :)

ciao,
federico

> For me as a LDAP client programmer there are two main issues which
> can only be solved within the C module:
> 
> - LDAPv3
>   (I have to at least be able to tell the server that my program
>   is a LDAPv3 client.)
> - SSL
> 
> Both features can be achieved by sitting on top of the Netscape
> library found on http://www.mozilla.org/. I think we should reach
> the same level like PerlLDAP (also found on Mozilla).

yes, but i think the best thing is to not force a particular library
upon the user but let him choose... (autoconf/automake?)

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
              All programmers are optimists. -- Frederick P. Brooks, Jr.

Re: Future of ldapmodule

[Sascha G. <sa...@fr...>]

> I would suggest that ldapmodule stays as close to the C API as
> possible with having exception for error handling just as it is
> right now. Higher level abstractions (all kind of schema handling)
> can be build into a separate Python class library (e.g. fog's
> modules).
> 

Implementing ...
Now the discussion is : typemaps or classes ? 

> Note that there's a new upcoming C-API standard which will replace
> RFC1823. 

Now its on my task-list to read it !

>There was a posting on ld...@um... or one of the
> OpenLDAP lists about this a couple of days ago with hints how to use
> autoconfigure to determine the C-API capabilities.
> 

I dont really like the idea of running huge shell-skripts every time I
change
the platform, but anyway - could you be so kind to forward some of these
e-mails
so I can see how to determine the C-API capabilities ?

> For me as a LDAP client programmer there are two main issues which
> can only be solved within the C module:
> 
> - LDAPv3
>   (I have to at least be able to tell the server that my program
>   is a LDAPv3 client.)

Well SWIG can wrap this for you ...

> - SSL

Again SWIG can wrap this for you....

> 
> Both features can be achieved by sitting on top of the Netscape
> library found on http://www.mozilla.org/. 

Thanx for this pointer, I absolutly can agree SSL and LDAPv3 are 
features which should be supported.

I think we should reach
> the same level like PerlLDAP (also found on Mozilla).
> 

I'll have a look at this - bye,  Sascha


> Ciao, Michael.
> 
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/python-ldap-dev

Re: Future of ldapmodule

[Sascha G. <sa...@fr...>]

[...]
> Sasha,
> 
> this looks like a great start!  much smaller and understandable. and even
> the lber interface is exposed.

Dynamic loading complained about missing lber functions - so I fixed it
by supporting it ... 

> 
> but which particular LDAP library was this created against? 

Freebsd:	openldap-1.2.9 without kerberos-support (its no problem to
support kerberos)
Linux:		slapd 1.2.7-Release (Tue Nov  9 01:18:47 GMT 1999)
Solaris:        version=slapd 1.2.7-Release (Thu Jan 13 21:52:44 MET
2000)

>the various ldap
> header files that are around (netscape/openldap/umich) may not work with
> what you have - as not all those functions would be available everywhere
> i reckon.

Thats right. I'll be installing an additional (netscape/umich) -
environment on all
my three platforms - then I need to be automatically running "cvs
checkout swig-ldap; make test" 
every day on each platform to see what I have done to the sources ...

PS: Solaris 8 supports ldap as well, so again another lib and some
different header for that as well ...
    ... in a month or two I can have another sun running solaris 8

> 
> also, in order to retain the niceness features that the current module
> has (exceptions, integrated memory management) a lot of wrapping needs to
> happen.

Exceptions are really easy to implement. Memory management and
datastructures need
work. C-datatypes can be mapped to something more useful by "typemaps" -
have a look
at the brandnew site http://swig.cs.uchicago.edu/typemap/index.php3 to
get an idea -
I'll have to consult the manual to understand all this mind-transforming
stuff ...
. 

> while it this is possible and probably a good design, keeping it
> independent, there is still i believe some uncertainty about what the
> 'top level' python LDAP client API should look like.
> 

We can support several API's by providing several kind of
interface-files:

	- low-level C (just survive)
	- classic     (your module-existing programs run without modification)
	- dbm         (cool)
	- corba       (luxus)

> i reckon the API should follow what CORBA are doing. 

Can you please send me an URL or a document to help me understand how
corba supports LDAP ?

>Alternatively, the
> python dbm module interface could be used - but X.500 DNs are just
> so less compatible than most database's free-form keys... 

Okay - i'll be having a look at the dbm interface to get an opinion.

>originally
> I tried to base the python interface on an RFC, but it just doesn't seem
> to fit very where. fo...@so... and mi...@ms... have some good
> ideas in this area, but have been quiet of late.
> 
> > You are welcome to join and/or use this for extending your efforts to
> > convince python to talk LDAP ...
> 
> so the .i files that you have shown me look like a nice way of getting
> rid of a lot of redundant existing code, but at this first glance, i
> think it needs a lot of work to get it to be more portable, and also
> our minds need to be made up on what the LDAP api should really look like..
> 

Which platforms do you want to support - these platforms need the 

	"cvs checkout swig-ldap; make test" ; cvs commit test.out

so I can see if they need help ... 


> i'd encourage you to work this into the python-ldap source tree.

A first step could be implementing the classic interface.

[...]


		Sascha

Re: Future of ldapmodule

[Michael <mic...@in...>]

David Leonard wrote:
> 
> On Tue, 14 Mar 2000, Sascha Gresk raved thusly:
> 
> > This is just a beginning, but now I can start to use python and LDAP .
> > [..]
> > LDAP/lber.i
> > LDAP/ldap.i
> > [..]
> 
> Sasha,
> 
> this looks like a great start!  much smaller and understandable.
> [..]
> while it this is possible and probably a good design, keeping it
> independent, there is still i believe some uncertainty about what the
> 'top level' python LDAP client API should look like.
> [..]
> i reckon the API should follow what CORBA are doing.

I do not exactly know what Corba is doing. But I think the low-level
LDAP C module should not abstract to such a high level (like e.g.
JNDI).

> Alternatively, the
> python dbm module interface could be used

I don't think this is a good idea. If someone has the need for such
a interface he should write a wrapper class.

> fo...@so... and mi...@ms... have some good
> ideas in this area, but have been quiet of late.

I was very busy the last time...

> and also
> our minds need to be made up on what the LDAP api should really look 
> like..

I would suggest that ldapmodule stays as close to the C API as
possible with having exception for error handling just as it is
right now. Higher level abstractions (all kind of schema handling)
can be build into a separate Python class library (e.g. fog's
modules).

Note that there's a new upcoming C-API standard which will replace
RFC1823. There was a posting on ld...@um... or one of the
OpenLDAP lists about this a couple of days ago with hints how to use
autoconfigure to determine the C-API capabilities.

For me as a LDAP client programmer there are two main issues which
can only be solved within the C module:

- LDAPv3
  (I have to at least be able to tell the server that my program
  is a LDAPv3 client.)
- SSL

Both features can be achieved by sitting on top of the Netscape
library found on http://www.mozilla.org/. I think we should reach
the same level like PerlLDAP (also found on Mozilla).

Ciao, Michael.

Future of ldapmodule

[David L. <dav...@cs...>]

On Tue, 14 Mar 2000, Sascha Gresk raved thusly:

> > Future of ldapmodule
> > Since I saw SWIG, I have since realised how much more simple and
> > portable I could have made this module. Most of the work is in
> > converting Python data structures into C data structures and testing
> > for errors and raising exceptions wherever possible.
> 
> This is just a beginning, but now I can start to use python and LDAP .

> LDAP
> LDAP/CVS
> LDAP/CVS/Root
> LDAP/CVS/Repository
> LDAP/CVS/Entries
> LDAP/ldapmodule.h
> LDAP/Makefile
> LDAP/lber.i
> LDAP/ldap.i
> LDAP/test.py
> LDAP/link.conf
> LDAP/link
> LDAP/VERSION
> LDAP/README.static
> LDAP/TODO
> LDAP/README

Sasha,

this looks like a great start!  much smaller and understandable. and even 
the lber interface is exposed.

but which particular LDAP library was this created against? the various ldap
header files that are around (netscape/openldap/umich) may not work with 
what you have - as not all those functions would be available everywhere
i reckon.

also, in order to retain the niceness features that the current module
has (exceptions, integrated memory management) a lot of wrapping needs to
happen. while it this is possible and probably a good design, keeping it
independent, there is still i believe some uncertainty about what the
'top level' python LDAP client API should look like.

i reckon the API should follow what CORBA are doing. Alternatively, the
python dbm module interface could be used - but X.500 DNs are just
so less compatible than most database's free-form keys... originally
I tried to base the python interface on an RFC, but it just doesn't seem
to fit very where. fo...@so... and mi...@ms... have some good
ideas in this area, but have been quiet of late.

> You are welcome to join and/or use this for extending your efforts to
> convince python to talk LDAP ...

so the .i files that you have shown me look like a nice way of getting
rid of a lot of redundant existing code, but at this first glance, i
think it needs a lot of work to get it to be more portable, and also 
our minds need to be made up on what the LDAP api should really look like..

i'd encourage you to work this into the python-ldap source tree.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

les Windows est un système d'exploitation - Babelfish

Re: Specifying max. search hits

[David L. <dav...@cs...>]

On Tue, 29 Feb 2000, Michael Ströder raved thusly:

> David Leonard wrote:
> > 
> >         l = _ldap.open(...)
> >         id = l.search(...blah..blah..)
> >         for num in range(10):
> >                 res = l.result(id, 0)
> >                 print "Got one result", `res`
> 
> Does this always return exactly one result? Or might there be more
> than one entries in the result res?

Yes, that's what the 0 ('all') argument is for.

Print its docstring.

"\tThe all parameter only has meaning for search() responses\n"
"\tand is used to select whether a single entry of the search\n"
"\tresponse should be returned, or to wait for all the results\n"
"\tof the search before returning.\n"

by the way your last sentence has an interesting parse:
> Or might there be ( more than one ) entries in the result res?

d

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Computers save man a lot of guesswork, but so does the bikini - BrightSun

Re: Specifying max. search hits

[Michael <mic...@in...>]

David Leonard wrote:
> 
>         l = _ldap.open(...)
>         id = l.search(...blah..blah..)
>         for num in range(10):
>                 res = l.result(id, 0)
>                 print "Got one result", `res`

Does this always return exactly one result? Or might there be more
than one entries in the result res?

Ciao, Michael.

Re: Specifying max. search hits

[David L. <le...@cs...>]

On Mon, 28 Feb 2000, Michael Ströder wrote:

> I would like to specify the maximum number of hits returned by a
> search call. Is this possible with the _ldap module? I could not
> find something in the docs.

hmm.. i don't know if the LDAP protocol allows limiting the server from
finding >n results, but you could pull results out one at a time by
using  the asynchronous calls

	l = _ldap.open(...)
	id = l.search(...blah..blah..)
	for num in range(10):
		res = l.result(id, 0)
		print "Got one result", `res`
	
but i'm a bit rusty on this.

--
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

The Stick: Second most useful thing ever. -- DNA

Specifying max. search hits

[Michael <mic...@in...>]

HI!

I would like to specify the maximum number of hits returned by a
search call. Is this possible with the _ldap module? I could not
find something in the docs.

Ciao, Michael.

Re: IDL interface for LDAP

[David L. <dav...@cs...>]

On Fri, 25 Feb 2000, David Leonard raved thusly:

> this is a good idea. 
> can you reply with an URL to the published Java API please?

ok, after a quick search, i think i found what you refer to:
* http://search.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-09.txt

Also for others on this list to compare

* http://developer.netscape.com/docs/manuals/dirsdk/jsdk40/contents.htm
* http://developer.netscape.com/docs/manuals/dirsdk/jsdk40/Reference/
	Netscape's LDAP client api

* http://java.sun.com/products/jndi/docs.html
* http://java.sun.com/products/jdk/1.3/docs/guide/jndi/spec/jndi/
	Java JNDI

And maybe this guy should be contacted

* http://www.omg.org/archives/comp-object-corba/msg03280.html
	Uwe v. Lukas <uv...@ro...> has IDL for an LDAP interface

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Computers save man a lot of guesswork, but so does the bikini - BrightSun

Re: IDL interface for LDAP

[David L. <dav...@cs...>]

Dave,

this is a good idea. 
can you reply with an URL to the published Java API please?

thanks

On Thu, 24 Feb 2000, lcspub raved thusly:

> Hi Dave...:)
> 
> I  emailed Kurt Zelinega of OpenLDAP about his desire for a C++ api for
> LDAP.
> 
> I thought I'd run some ideas by you and the Python folks.
> 
> I'm heavily involved in the Berlin Project which is an OO gui written in
> C++ and using CORBA.
> 
> In investigating what a C++ api might look like I decided that a CORBA
> binding would be necessary.
> 
> Given the published JAVA api for LDAP and your desire to see a Python
> one, maybe we can/should come up with a uniform set of IDL interfaces
> that can generate the proper stubs and skeletons for the various
> language bindings.
> 
> We at Berlin Project use omniORB as our orb and it now has Python
> support as well as C++ and Java.
> 
> A good IDL interface would standardize across the three languages and
> might form the basis for an extention to CORBAservices or IIOP for
> support of  networked directory objects.
> 
> Let me know what you think...:)
> 
> Arrow (Dave Archer)
> 

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Computers save man a lot of guesswork, but so does the bikini - BrightSun

Re: autoconf fails ...

[David L. <dav...@cs...>]

you are right.  

On Thu, 24 Feb 2000, Sascha Gresk raved thusly:

> # this *just* wont work - sascha
> #
> # AC_SEARCH_LIBS(ber_free, lber)
> # AC_SEARCH_LIBS(ldap_open, ldap)
> # AC_CHECK_FUNC(ldap_open,, [no_ldap "Couldn't find ldap_open()"])
> # AC_CHECK_HEADER(ldap.h,, [no_ldap "Couldn't find ldap.h"])
> #
> 
> 
> ldap_open hides in a different lib which your suggested configure-script
> wouldn_t try to link ... I would rather prefer using TRY_COMPILE to
> check
> everything ... and/or set some linkerflags differently ...
> 
> 
> 	Greetings,
> 
> 		Sascha
> 
> 
> 
> % nm  liblber.a|grep ldap_open
> % nm libldap.a|grep ldap_open
> 00000000 T ldap_open
> % pwd
> /tmp/ldap-pfx/lib
> 
> 
> This is what I see in my config.log on my freebsd3.4-STABLE BOX:
> 
> /tmp/ldap-pfx/src/ldap/libraries/libldap/kbind.c(.text+0x367): undefined
> reference to `krb_mk_req'
> configure: failed program was:
> #line 1448 "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:1480: checking for ldap_open
> configure:1508: gcc -o conftest -g -O2 -I/tmp/ldap-pfx/include 
> -DWITH_KERBEROS -L/tmp/ldap-pfx/lib  c
> onftest.c -llber  -lm 1>&5
> /var/tmp/ccq519781.o: In function `main':
> /home/sascha/projekte/LDAP/python/ldapmodule-cvs/python-ldap/ldapmodule/configure(.text+0x4):
> undefine
> d reference to `ldap_open'
> configure: failed program was:
> #line 1485 "configure"
> #include "confdefs.h"
> /* System header to define __stub macros and hopefully few prototypes,
>     which can conflict with char ldap_open(); below.  */
> #include <assert.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() {
> 
> /* 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_open) || defined (__stub___ldap_open)
> choke me
> #else
> ldap_open();
> #endif
> 
> ; return 0; }
> 

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Computers save man a lot of guesswork, but so does the bikini - BrightSun

Re: LDAPError

[David L. <le...@cs...>]

On Tue, 22 Feb 2000, Suki Chana wrote:

> I am trying to write an LDAP extension for one of our products. I have
> incorporated your ldap module into this extension to provide the ldap
> services needed by our product. Unfortunately I don't seem to be able to
> find enough detail in your documentation regarding the LDAPError base
> class. Do you have any more details or know where I can find them.

See section 7 of RFC1823.  I don't know what the semantics are. They are
simply converted into python exceptions. Perhaps they are better documented
in the OpenLDAP documentation?

The class inheritance heirarchy as I recall is

   + Exception
   	+ ldap.error
		+ ldap.SUCCESS			# never raised!
		+ ldap.OERATIONS_ERROR
		+ ldap.PROTOCOL_ERROR
		...

--
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Hey you! Don't disrespect our legal system. Ours is the best legal system 
that money can buy. - Anonymous Coward

Re: Error with web2ldap and libldap.so.1

[David L. <dav...@cs...>]

On Mon, 21 Feb 2000, Michael Ströder raved thusly:

> > but
> > I am attempting to get web2ldap installed but have come across the
> > following problem;
> > 
> > the apache log gives the following error -
> > 
> > headers: /home/httpd/cgi-bin/web2ldap.py
> > Traceback (innermost last):headers: /home/httpd/cgi-bin/web2ldap.py
> > Traceback (innermost last):
> >   File "/home/httpd/cgi-bin/web2ldap.py", line 62, in ?
> >     import msbase, cgiforms, cgissl, ldap, ldapbase, charset
> > ImportError: /usr/lib/libldap.so.1: undefined symbol: res_search
> > [Fri Feb  4 13:35:48 2000] [error] [client 192.168.0.3] Premature end of
> > script headers: /home/httpd/cgi-bin/web2ldap.py

it looks like -lresolver isn't being dynamically loaded.

| arkansas:d$ nm  /usr/lib/libresolv.a | grep res_search
|          U res_search
| 00000100 T res_search

and it know that ldapmodule's configure didn't even looking for it...
I don't know if it should either. If you used the openldap.sh script to
build ldapmodule, it steals the LIBS variable from openldap's 
config.status and trusts it!

| Checking for LIBS in /tmp/ldap-pfx/src/ldap/config.status... yes

A crude work-around might be to import the socket module early? Dunno if 
that will work though. You can try it.

	import socket, ldap

or if you have the 'dl' module, you can try this truly evil code

	import dl
	_rhandle = dl.open("/usr/lib/libresolv.so")
	import ldap

I didn't see the original message so I can't be sure what version of 
ldapmodule or linux Craig is using. Is it ELF? Does ELF carry around
shared-library dependencies? does your rtld/ld.so/dlopen automatically
follow dependencies? etc etc etc.

> This is a problem with importing the ldapmodule.so. I saw this error
> several times when ldapmodule.so was not build correctly or shared
> libs are messed up from older installations. Since you're running
> Red Hat Linux you might wanna grab a pre-compiled RPM found on
> http://www.webideal.de/ldap/ and try again with that one.

yep - that seems like probably the best solution. 
please let me know if this or anything else fixes the problem for you Craig.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Computers save man a lot of guesswork, but so does the bikini - BrightSun

Re: Error with web2ldap and libldap.so.1

[Michael <mic...@in...>]

Craig Silva wrote:
> 
> not sure whether  this is the right mailing list to deal with this,

ope...@op... is only for discussing
OpenLDAP-Software from http://www.openldap.org/.

ope...@op... might be a good choice for discussing
web2ldap if Kurt agrees with that.

> but
> I am attempting to get web2ldap installed but have come across the
> following problem;
> 
> the apache log gives the following error -
> 
> headers: /home/httpd/cgi-bin/web2ldap.py
> Traceback (innermost last):headers: /home/httpd/cgi-bin/web2ldap.py
> Traceback (innermost last):
>   File "/home/httpd/cgi-bin/web2ldap.py", line 62, in ?
>     import msbase, cgiforms, cgissl, ldap, ldapbase, charset
> ImportError: /usr/lib/libldap.so.1: undefined symbol: res_search
> [Fri Feb  4 13:35:48 2000] [error] [client 192.168.0.3] Premature end of
> script headers: /home/httpd/cgi-bin/web2ldap.py

This is a problem with importing the ldapmodule.so. I saw this error
several times when ldapmodule.so was not build correctly or shared
libs are messed up from older installations. Since you're running
Red Hat Linux you might wanna grab a pre-compiled RPM found on
http://www.webideal.de/ldap/ and try again with that one.

For testing you can invoke the Python interpreter and just type:

  import ldap

There's also a new developers mailing list for python-ldap on
SourceForge (Cc:-ed, see
http://lists.sourceforge.net/mailman/listinfo/python-ldap-dev).

Ciao, Michael.

Re: ssl, terminology and htdocs (was: ok)

[Michael <mic...@in...>]

David Leonard wrote:
> 
> i notice that SSL support is now part of the socket module in 
> python-current,
> but I don't think it made it into 1.5.2.
> 
> regardless, the underlying ldap C library would have to support SSL...
> especially in ldap_open... i'm going to

Yes, the LDAP C libary has to support SSL and especially the
certificate handling stuff has to be visible to the application.
E.g. if an application wants to authenicate with a client cert the
application is responsible to guide the user choosing his cert
file/data etc.

Ciao, Michael.

Re: openldap ssl

[Michael <mic...@in...>]

David Leonard wrote:
> 
> there is an openldap faq regarding ssl
> 
>         http://www.openldap.org/faq/data/cache/185.html

IMHO this is not true for OpenLDAP 1.2.x

Ciao, Michael.

Re: ssl, terminology and htdocs (was: ok)

[Michael <mic...@in...>]

David Leonard wrote:
> 
> On Sat, 12 Feb 2000, David Leonard raved thusly:
> > regardless, the underlying ldap C library would have to support SSL...
> > especially in ldap_open... i'm going to
> 
> ... i'm going to start tracking OpenLDAP-devel to see how rich their
> interface is now.

1.2.x series?

IMHO the Netscape SDK is a more promising solution.
It's well tested and widely used. And it's already available.

Ciao, Michael.

openldap ssl

[David L. <dav...@cs...>]

there is an openldap faq regarding ssl

	http://www.openldap.org/faq/data/cache/185.html

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

setenv COPTS -Dnotyet

Re: ssl, terminology and htdocs (was: ok)

[David L. <dav...@cs...>]

On Sat, 12 Feb 2000, David Leonard raved thusly:
> regardless, the underlying ldap C library would have to support SSL... 
> especially in ldap_open... i'm going to 

... i'm going to start tracking OpenLDAP-devel to see how rich their 
interface is now.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

setenv COPTS -Dnotyet

ssl, terminology and htdocs (was: ok)

[David L. <dav...@cs...>]

On Fri, 11 Feb 2000, Federico Di Gregorio raved thusly:

> Scavenging the mail folder uncovered Michael Ströder's letter:
> > I would like several things to appear in the cmodule:
> > - LDAPv3 access
> >   (the client should at least be recognized as LDAPv3
> >   client by a LDAPv3 server)
> > - SSL access
> ssl access would be very nice.

i notice that SSL support is now part of the socket module in python-current,
but I don't think it made it into 1.5.2.

regardless, the underlying ldap C library would have to support SSL... 
especially in ldap_open... i'm going to 

oh by the way, this is my terminology for the layers of this project:

		
		ldap application
		ldap python library 		<- fog's stuff, etc
		ldap c module			<- _ldap
		ldap c library			<- OpenLDAP, Netscape, etc
		operating system

bascially to avoid confusion, a layer name includes the name of 
the language in which it was written...

plus, if you check out the 'htdocs' cvs module you can commit to the
web directory. I have set up a cron job on sourceforge to periodically
update the project's web pages from cvs :)

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

setenv COPTS -Dnotyet

Re: A first look at ldaplib.connection.LDAPConnection

[Michael <mic...@in...>]

Federico Di Gregorio wrote:
> 
> btw, is there a way to search
> the dn and not the data of the entry?

Not in general.

Ciao, Michael.

Re: ldaplib and LDAPv3

[<fo...@mi...>]

Scavenging the mail folder uncovered Michael Ströder's letter:
> Federico Di Gregorio wrote:
> > 
> >         i've just populated the ldaplib subtree of the cvs with my code.
> > it is still alpha, beware! but, togheter with the new _ldap module, it
> > works. i didn't commit lappo, the ldap browser. as i told you before,
> > david, we plan to host its page on our website (they pay me to code what i
> > want, but they want a little publicity back...)
> 
> Why not commit lappo into the CVS repository on sourceforge.net and
> make nice colored, blinky-winky web page for regular downloading on
> your web site? Well, just a suggestion.

done.

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
                             Best friends are often failed lovers. -- Me

Re: ldaplib and LDAPv3

[<fo...@mi...>]

Scavenging the mail folder uncovered Michael Ströder's letter:
> Federico Di Gregorio wrote:
[snip snap]
> This should give you an idea of how powerful this mechanism is for
> generic LDAP clients. I already started writing a parser for this
> but got stuck because up to now I do not have a good class library.

ok. download the code and just tell me what modifications you
think are needed.

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
                             Best friends are often failed lovers. -- Me