python-ldap-dev — discussion among developers

web2ldap 0.9.0

[Michael <mi...@st...>]

HI!

I'm pleased to announce a new release of web2ldap. Grab it from:

  http://www.web2ldap.de/download.html

web2ldap is a web gateway to LDAP servers. Check out
http://www.web2ldap.de to learn more about it.

Ciao, Michael.

Summary of changes since 0.8.3 (see
http://www.web2ldap.de/changes.html for details):

Runs as multithreaded HTTP server or FastCGIServer. Web session
managment with persistent LDAP connections. Displays images inline,
updated documentation and many bug fixes.

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Joe L. <jl...@op...>]

I'll try to be a bit more concise...


On Wednesday, May 9, 2001, at 10:44  AM, Michael Str=F6der wrote:

> Joe Little wrote:
>>
>> regarding LDAP thread safety, etc.. Luke Howard and other people
>> associated with Open-IT have had ideas about this, and thus the =
project
>> "kodama" was born to fix issues with OpenLDAP, including referrals.
>
> Can you give us an URL of "kodama"?
> Can you describe how they wanted to solve thread safety? (one of my
> urgent requirements!)
> Why to "fix issues with OpenLDAP" in a separate project and not as
> direct contributions to OpenLDAP? (No offense, just curiousity.)
>

Here's a spew of URLs discussing ActiveDirectory on UNIX and how it=20
would be built:

http://openit.stanford.edu/access/article/_02/article.html (discuss item=20=

on old site)
http://openit.stanford.edu/access/article/_00/article.html (same, more=20=

on OpenLDAP issues)

http://kodama.open-it.org/pipermail/core-dev/2000-October/thread.html =20=

(this month was busy with lots-o-discussions)

Our big presentation is

http://kodama.open-it.org/roadmap/index.html

this probably has the most concrete aspect of what kodama is.

In the end, we had people in the OpenLDAP project, but there was a=20
difference of opinion of what was "LDAP" the protocol and "LDAP" the=20
server with the OpenLDAP folks. The solution to some issues would be a=20=

better backend for OpenLDAP than ldbm and perhaps increases features=20
that may not be kosher for OpenLDAP now but could be directly used for=20=

our ActiveDirectory purposes through a straight API -- development use=20=

only and all that.


>> Some things can/will need to be done in python instead of the c-level
>> api. As to vendor specific ACL's, etc., that is a decision that will =
be
>> hard to make. One proposal would be ideal for Zope, bad for Python:
>> Using zope-based ACL primitives (dare I call it that) to handle ACLs=20=

>> and
>> then simple use SSL-certs (client and server) to authenticate.
>
> I'm not sure about which ACLs and authentication you're talking.
> Authorization schemes at your client/gateway side or at the LDAP
> server side? I don't understand how Zope is involved at that level.

It has its own interface for users, access, and such, and so one can=20
mask LDAP link up simple LDAP ACLs and access (groups, and such) and=20
form different access rules in Zope of possibly finer grain via=20
abstraction... It would be zope specific, but would allow use to make a=20=

secure conduit from Zope to OpenLDAP and provide the most access via the=20=

web only through Zope.

>
> As I understand you specify ACLs on some LDAP servers by setting
> operational attributes (e.g. attribute aci on Netscape server). Most
> times this is done by a vendor-specific directory managing software.
>
> Do you plan to write an ACL managing software for OpenLDAP? AFAIK in
> OpenLDAP ACLs are solely defined in the configuration file (see
> http://www.openldap.org/doc/admin/slapdconfig.html#Access Control).
> Therefore I don't see how python-ldap could be involved at all.
>

Part of Open-IT, "shiido" is designed to seed a directory server. Luke=20=

Howard has already be working on ldapprofile support (sun draft) and a=20=

few other things that would allow one to create the slapd.conf file.=20
Thus, we'd get into the business of generating slapd.conf file ACLs,=20
likely out of some schema def.

> Anyway, for the upcoming I-D on LDAP ACLs it is interesting that
> =
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-07.txt
> states in section ABSTRACT: "The current LDAP APIs are sufficient
> for the access control operations."
>
>> Kurt and
>> others keep on saying that OpenLDAP should not be the authentication
>> server, and we should rely upon 3rd party auth (Krb5, etc). The end
>> result is have OpenLDAP use some external auth and some external
>> ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like
>> the sound of this approach as an engineered solution. Instead, work =
is
>> still progressing on OpenLDAP's ACL, and again it may be a backend=20
>> issue
>> (thats were ACLs/transactions are implemented in OpenLDAP). A true
>> solution could be in kodama, in that kodama-specific API calls could =
be
>> used by a python-ldap to systems that can use kodama (more and more
>> development here). Alternatively, native ACL support would be used on
>> others. All of this decided from some config key in the LDAP server
>> itself. Yes, its one big hairy #ifdef. I'm babbling here simply on =
some
>> of that ideas thrown out about this. Suffice it to say that it won't =
be
>> easily solved, but that creating mature python-objects that contain =
the
>> solution will sufficiently hide these details from a higher level app
>> environment like Zope. And at the end of the day, that is all that
>> matters.
>
> Sorry, I can't figure out what exactly you're talking about.
>
> Most of us simply need the following: Authenticate a user by binding
> with the user entry's DN and a credential against an arbitrary LDAP
> server. How the LDAP server performs authentication (external or
> internal or whatever) is not of interest for your application
> (except having to provide the necessary credential data). E.g.
> strong authentication with client certs is handled via SASL. But
> again that's a special bind call.
>

It is a problem when the application you are making is supposed to=20
manage LDAP (data, configs, etc,), Samba-TNG, cyrus, etc.. We'd be=20
mucking with the auth and stuff, and the app would likely even need to=20=

"de-auth, test, and re-auth" to the LDAP after executing a change. Most=20=

of this is outside the scope of the ldap-python specific module, but=20
full support will need to be there to not duplicate code unnecessarily.

>> As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue
>> with configuration and compiled versions. Basically, you have
>> configuration files that point to an LDAP server with port, hostname,
>> etc. Pointing to port 636 for all traffic fails for LDAP v2
>> configurations.
>
> ???
>
> If you really take care of security I doubt that you want to leave
> use of SSL/TLS as option. Simply use a SSL wrapper (e.g. stunnel)
> running on that port you can
> mandate the use of LDAP over SSL even on non-SSL LDAP servers.
>

when LDAP is used with configuration services, many implementations are=20=

v2 or v3, and the v3 are not necessarily SSL-enabled. I don't but the=20
stunnel approach. It needs to use the protocol support path and not a=20
wrapper. I can't easily get access to the firmware of a cisco=20
DEN-enabled device to add stunnel to its LDAP queries :)

>> You will generally find that for large deployed
>> environments, you must support StartTLS and a configuration of port =
389
>> since multiple apps will key off the same "ldap seed" info and only a
>> percentage will be SSL-aware.
>
> Run the server on both ports...
>

Server is not the issue.. its the client config file. Most clients refer=20=

to one config file and accept only the first LDAP port value listed=20
there. We can't rewrite ALL the ldap enabled-apps :)

>> Also, its always ugly when you have
>> distros/OSes (like Solaris!) that support LDAP v3 but have the SSL
>> libraries as optional installs that are configured at run-time by=20
>> config
>> files, etc.
>
> Well, we're really getting off-topic.
>
>> In the end, StartTLS and port 389 is the way to go...
>
> See also for a discussion about RFC 2817:
> http://marc.theaimsgroup.com/?l=3Dopenssl-users&m=3D97733852307779&w=3D2=

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

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Michael <mi...@st...>]

Joe Little wrote:
> 
> regarding LDAP thread safety, etc.. Luke Howard and other people
> associated with Open-IT have had ideas about this, and thus the project
> "kodama" was born to fix issues with OpenLDAP, including referrals.

Can you give us an URL of "kodama"?
Can you describe how they wanted to solve thread safety? (one of my
urgent requirements!)
Why to "fix issues with OpenLDAP" in a separate project and not as
direct contributions to OpenLDAP? (No offense, just curiousity.)

> Some things can/will need to be done in python instead of the c-level
> api. As to vendor specific ACL's, etc., that is a decision that will be
> hard to make. One proposal would be ideal for Zope, bad for Python:
> Using zope-based ACL primitives (dare I call it that) to handle ACLs and
> then simple use SSL-certs (client and server) to authenticate.

I'm not sure about which ACLs and authentication you're talking.
Authorization schemes at your client/gateway side or at the LDAP
server side? I don't understand how Zope is involved at that level.

As I understand you specify ACLs on some LDAP servers by setting
operational attributes (e.g. attribute aci on Netscape server). Most
times this is done by a vendor-specific directory managing software.

Do you plan to write an ACL managing software for OpenLDAP? AFAIK in
OpenLDAP ACLs are solely defined in the configuration file (see
http://www.openldap.org/doc/admin/slapdconfig.html#Access Control).
Therefore I don't see how python-ldap could be involved at all.

Anyway, for the upcoming I-D on LDAP ACLs it is interesting that
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-07.txt
states in section ABSTRACT: "The current LDAP APIs are sufficient
for the access control operations."

> Kurt and
> others keep on saying that OpenLDAP should not be the authentication
> server, and we should rely upon 3rd party auth (Krb5, etc). The end
> result is have OpenLDAP use some external auth and some external
> ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like
> the sound of this approach as an engineered solution. Instead, work is
> still progressing on OpenLDAP's ACL, and again it may be a backend issue
> (thats were ACLs/transactions are implemented in OpenLDAP). A true
> solution could be in kodama, in that kodama-specific API calls could be
> used by a python-ldap to systems that can use kodama (more and more
> development here). Alternatively, native ACL support would be used on
> others. All of this decided from some config key in the LDAP server
> itself. Yes, its one big hairy #ifdef. I'm babbling here simply on some
> of that ideas thrown out about this. Suffice it to say that it won't be
> easily solved, but that creating mature python-objects that contain the
> solution will sufficiently hide these details from a higher level app
> environment like Zope. And at the end of the day, that is all that
> matters.

Sorry, I can't figure out what exactly you're talking about.

Most of us simply need the following: Authenticate a user by binding
with the user entry's DN and a credential against an arbitrary LDAP
server. How the LDAP server performs authentication (external or
internal or whatever) is not of interest for your application
(except having to provide the necessary credential data). E.g.
strong authentication with client certs is handled via SASL. But
again that's a special bind call.

> As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue
> with configuration and compiled versions. Basically, you have
> configuration files that point to an LDAP server with port, hostname,
> etc. Pointing to port 636 for all traffic fails for LDAP v2
> configurations.

???

If you really take care of security I doubt that you want to leave
use of SSL/TLS as option. Simply use a SSL wrapper (e.g. stunnel)
running on that port you can
mandate the use of LDAP over SSL even on non-SSL LDAP servers.

> You will generally find that for large deployed
> environments, you must support StartTLS and a configuration of port 389
> since multiple apps will key off the same "ldap seed" info and only a
> percentage will be SSL-aware.

Run the server on both ports...

> Also, its always ugly when you have
> distros/OSes (like Solaris!) that support LDAP v3 but have the SSL
> libraries as optional installs that are configured at run-time by config
> files, etc.

Well, we're really getting off-topic.

> In the end, StartTLS and port 389 is the way to go...

See also for a discussion about RFC 2817:
http://marc.theaimsgroup.com/?l=openssl-users&m=97733852307779&w=2

Ciao, Michael.

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Joe L. <jl...@op...>]

yeah..

regarding LDAP thread safety, etc.. Luke Howard and other people=20
associated with Open-IT have had ideas about this, and thus the project=20=

"kodama" was born to fix issues with OpenLDAP, including referrals.=20
Kodama has stagnated since the various qualified people are too busy and=20=

I'm not up to par to handle that bit.

Some things can/will need to be done in python instead of the c-level=20
api. As to vendor specific ACL's, etc., that is a decision that will be=20=

hard to make. One proposal would be ideal for Zope, bad for Python:=20
Using zope-based ACL primitives (dare I call it that) to handle ACLs and=20=

then simple use SSL-certs (client and server) to authenticate. Kurt and=20=

others keep on saying that OpenLDAP should not be the authentication=20
server, and we should rely upon 3rd party auth (Krb5, etc). The end=20
result is have OpenLDAP use some external auth and some external=20
ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like=20
the sound of this approach as an engineered solution. Instead, work is=20=

still progressing on OpenLDAP's ACL, and again it may be a backend issue=20=

(thats were ACLs/transactions are implemented in OpenLDAP). A true=20
solution could be in kodama, in that kodama-specific API calls could be=20=

used by a python-ldap to systems that can use kodama (more and more=20
development here). Alternatively, native ACL support would be used on=20
others. All of this decided from some config key in the LDAP server=20
itself. Yes, its one big hairy #ifdef. I'm babbling here simply on some=20=

of that ideas thrown out about this. Suffice it to say that it won't be=20=

easily solved, but that creating mature python-objects that contain the=20=

solution will sufficiently hide these details from a higher level app=20
environment like Zope. And at the end of the day, that is all that=20
matters.

As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue=20
with configuration and compiled versions. Basically, you have=20
configuration files that point to an LDAP server with port, hostname,=20
etc. Pointing to port 636 for all traffic fails for LDAP v2=20
configurations. You will generally find that for large deployed=20
environments, you must support StartTLS and a configuration of port 389=20=

since multiple apps will key off the same "ldap seed" info and only a=20
percentage will be SSL-aware. Also, its always ugly when you have=20
distros/OSes (like Solaris!) that support LDAP v3 but have the SSL=20
libraries as optional installs that are configured at run-time by config=20=

files, etc.

In the end, StartTLS and port 389 is the way to go...

On Wednesday, May 9, 2001, at 09:25  AM, Michael Str=F6der wrote:

> Joe Little wrote:
>>
>> I'm not complaining..
>
> Joe, since you are really contributing code be assured that I did
> not point to you.
>
>> we need specifically to support v3 schema,
>
> Could be done in higher-level Python modules. (Not trivial though.)
> Not sure if you won't have to fiddle with BER-encoded data
> (implementing syntax matching).
>
>> OpenLDAP v2 ACLs,
>
> Currently this whole ACL thing is vendor-specific =3D> you would have
> to write a specific module for each LDAP server. Finding a good
> abstraction level would be required. See also "Access Control Model
> for LDAP" on http://www.ietf.org/html.charters/ldapext-charter.html
> for an attempt to define a standard. There's no need for a modified
> C extension module. You could also implement this in Python.
>
>> StartTLS,
>
> Or LDAP over SSL (ldaps://..). IMHO STARTTLS is not widely
> implemented up to now.
>
> Let me add two things.
>
> Thread-safety/reentrant: Would require to go with the Mozilla SDK or
> use ldap_r of OpenLDAP 2.0.x (experimental, see my other posting
> with Kurt's not about it).
>
> Proper handling of referrals / search continuations: Konstantin's
> patch already provides this but there are sometimes strange LDAP
> referral URLs returned. Might be a bug of the OpenLDAP 2.0.x libs.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Michael <mi...@st...>]

Joe Little wrote:
> 
> I'm not complaining..

Joe, since you are really contributing code be assured that I did
not point to you.

> we need specifically to support v3 schema,

Could be done in higher-level Python modules. (Not trivial though.)
Not sure if you won't have to fiddle with BER-encoded data
(implementing syntax matching).

> OpenLDAP v2 ACLs,

Currently this whole ACL thing is vendor-specific => you would have
to write a specific module for each LDAP server. Finding a good
abstraction level would be required. See also "Access Control Model
for LDAP" on http://www.ietf.org/html.charters/ldapext-charter.html
for an attempt to define a standard. There's no need for a modified
C extension module. You could also implement this in Python.

> StartTLS,

Or LDAP over SSL (ldaps://..). IMHO STARTTLS is not widely
implemented up to now.

Let me add two things.

Thread-safety/reentrant: Would require to go with the Mozilla SDK or
use ldap_r of OpenLDAP 2.0.x (experimental, see my other posting
with Kurt's not about it).

Proper handling of referrals / search continuations: Konstantin's
patch already provides this but there are sometimes strange LDAP
referral URLs returned. Might be a bug of the OpenLDAP 2.0.x libs.

Ciao, Michael.

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Joe L. <jl...@op...>]

Yes, Open-IT would "love" help :)

BTW -- I'm new to the list and not entirely interested in doing work 
already done by others. I'm not complaining.. just trying to gauge 
current level of functionality and interest. First, let me state that

a) Open-IT, if it does port something or create something, it will be 
maintained by the group.. all our other software kinda depends on it :)

b) check out http://open-it.org/LDAPAdaptor
-- Ryan did this work for me back in the OpenLDAP 1.x days. It was an EO 
adaptor for WebObjects which is more similar to Zope than not. 
NeXT/Apple didn't think the abstraction necessary to treat an LDAP 
server as a DB for its enterprise objects was possible, so we stupidly 
tried and succeeded. They have since made a commercial version based on 
Ryan's ideas for WebObjects. The key thing was the OO level abstraction 
that was obtained to allow the GUI kit to work. Python-LDAP may be 
suitable to fit this role. But "unmaintained" code is not. I'd either 
need to be assured its maintained or maintain something, the current 
stuff or something new, myself. I just wish an LDAP module was standard 
to Python and/or Zope. Its kind of odd that there isn't one. I may need 
to use SWIG, use the current code, or model connectivity after ZyDB 
style modules (again, it can be done!).

You ask for feature requirements? Since we plan on working on OpenLDAP 
backends (transactions, etc), we need specifically to support v3 schema, 
OpenLDAP v2 ACLs, StartTLS, among others to name a few. I have myself 
put together and "maintain" RPMs for Python-LDAP w/ the patches to work 
against OpenLDAP v2.

David Leonard... I had a nice reply to your last message all written up 
when I experienced my first MacOSX "desktop" crash... apparently the 
internet radio station I was listening to wedged up and there went my 
interface for whatever reason. Most of my long ranting is in the above 
details. People may hate pine, but its disaster-recovery for lost 
sessions would be a nice feature in ALL mailers.

					-Joe

On Wednesday, May 9, 2001, at 05:11  AM, Jens Vagelpohl wrote:

> joe,
>
> i am "hell-bent" on using Zope for managing records in OpenLDAP (or 
> other
> LDAP servers for that matter) myself. at this point i have released the
> LDAPLoginAdapter and LDAPUserManager (see
> http://www.dataflake.org/software/) for authenticating and managing user
> records in Zope but i am thinking about a more generic LDAP record
> management application.
>
> if you would like help (on the zope side, i'm no C programmer ;),
> suggestions, beta testers, etc let me know.
>
> jens
>
>
> Jens Vagelpohl
> Digital Creations
> The Zope Dealers
>
>
>
> On 5/8/01 19:22, "Joe Little" <jl...@op...> wrote:
>
>> So, I put together python-ldap RPMs/SRPMs for redhat 6.2 and 7.0 to go
>> with my OpenLDAP 2.0.x RPMs on open-it.org. these include the patches
>> spoken of before to support OpenLDAP 2.x.
>>
>> http://open-it.org/download   (in either redhat6.2/RPMS or the like you
>> find it)
>>
>> This was done a while ago when I was doing some python-scripts against
>> an LDAP tree (November). I'm now hell bent on using Zope to manage
>> openldap, samba-tng, and other components necessary for Open-IT's 
>> goals.
>> Well, OpenLDAP feature sets do trully need to be supported, since I'll
>> be managing certificates and require TLS and such. Lovely that. So I
>> will either need to figure out how to fix python-ldap for modern ldap
>> libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the
>> SWIG approach may be necessary. What are list member preferences at 
>> this
>> stage. I was not utterly thrilled when I glanced at the current code
>> base. Associated with the swig approach, I may only need specific
>> functions to access LDAP and thus need only build a new simplified API
>> that hides c-specific calls to do the rest.
>>
>> Is python-ldap basically abandon-ware at this point? Being in "a3" for
>> about a year is pretty "abandoned" to me.
>>
>> Just trolling through the list via ZopeLDAP links and realized that I
>> never did post my RPMs...
>

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Jens V. <je...@di...>]

joe,

i am "hell-bent" on using Zope for managing records in OpenLDAP (or other
LDAP servers for that matter) myself. at this point i have released the
LDAPLoginAdapter and LDAPUserManager (see
http://www.dataflake.org/software/) for authenticating and managing user
records in Zope but i am thinking about a more generic LDAP record
management application.

if you would like help (on the zope side, i'm no C programmer ;),
suggestions, beta testers, etc let me know.

jens


Jens Vagelpohl
Digital Creations
The Zope Dealers



On 5/8/01 19:22, "Joe Little" <jl...@op...> wrote:

> So, I put together python-ldap RPMs/SRPMs for redhat 6.2 and 7.0 to go
> with my OpenLDAP 2.0.x RPMs on open-it.org. these include the patches
> spoken of before to support OpenLDAP 2.x.
> 
> http://open-it.org/download   (in either redhat6.2/RPMS or the like you
> find it)
> 
> This was done a while ago when I was doing some python-scripts against
> an LDAP tree (November). I'm now hell bent on using Zope to manage
> openldap, samba-tng, and other components necessary for Open-IT's goals.
> Well, OpenLDAP feature sets do trully need to be supported, since I'll
> be managing certificates and require TLS and such. Lovely that. So I
> will either need to figure out how to fix python-ldap for modern ldap
> libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the
> SWIG approach may be necessary. What are list member preferences at this
> stage. I was not utterly thrilled when I glanced at the current code
> base. Associated with the swig approach, I may only need specific
> functions to access LDAP and thus need only build a new simplified API
> that hides c-specific calls to do the rest.
> 
> Is python-ldap basically abandon-ware at this point? Being in "a3" for
> about a year is pretty "abandoned" to me.
> 
> Just trolling through the list via ZopeLDAP links and realized that I
> never did post my RPMs...

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Michael <mi...@st...>]

Joe Little wrote:
> =

> So I
> will either need to figure out how to fix python-ldap for modern ldap
> libraries (OpenLDAP, mozilla, etc), or redo it completely.

Unfortunately the LDAP C SDKs diverged to incorporate new features
like SASL, SSL, etc. Another thing to take care of: All people are
asking for building against the OpenLDAP 2 libs. Note that the only
thread-safe LDAP C SDK seems to be the Mozilla C SDK.

---------------------- snip ----------------------
Subject: Re: OpenLDAP libs thread-safe?
Date: Fri, 13 Apr 2001 09:00:45 -0700
From: "Kurt D. Zeilenga" <Ku...@Op...>
To: mi...@st...
CC: openldap-software <ope...@Op...>

At 02:42 PM 4/13/01 +0200, Michael Str=F6der 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.  As
use of -lldap_r requires detailed knowledge of how the library
works, I do not recommend developers attempt to make use of it.

You might consider using the Mozilla LDAP C API which has more
general thread-safety features.

Of course, we welcome those wanting to work on the OpenLDAP C
API to improve its thread-safety features.

Kurt
---------------------- snip ----------------------

Ciao, Michael.

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Michael <mi...@st...>]

David Leonard wrote:
> 
> i feel its important to discuss how you'd like to see yourself interacting
> with ldap through python.

Yes!

<rant>

What makes me angry is that most people just complain about
python-ldap being abandonware because it cannot be linked against
OpenLDAP 2 libs. That's definitely not enough! You can write a lot
of standard LDAP applications with python-ldap by reading the
_ldap.pdf carefully. Most of you wouldn't need more. python-ldap
does not do your homework nor cook your coffee off course.

People should really list the particular defecencies they
*personally* experienced. I can easily list a few *I* experienced
(as I already did - see the list archive). But I would like to know
what others have as requirements and discuss them in detail.

On the other side all people are free to come up with their own
home-grown modules and see how they fit into this project. Some
people did and I appreciate this although I might have a different
opinion. But note: getting something to a maturity you all are
expecting from python-ldap is much work (maintaining, support,
documentation) - a quick hack/patch will not do.

</rant>

> there have been some past emails containing my
> suggestions and fog has some work towards a high level X.500 interface
> for python.

I could also release some higher-level modules (e.g. ldapsession
found in web2ldap) with a more relaxed license. But people have to
be willing to at least test them. There's not much feedback on this
list. Just complaints.

> on the other hand, just getting something to work with openldap2 via swig
> would make progress and maybe that's all that you and other people
> really need?

If there's not a requirement list which features of OpenLDAP 2
people really need this will just produce a quick hack/patch of not
much use. And if the producer looses interest it's not maintained.

Ciao, Michael.

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Michael <mi...@st...>]

Joe Little wrote:
> 
> Indeed. I know one of the maintainers of the PerLDAP stuff. Its not very
> pretty, but even the python-ldap code has gotten less pretty than I'd
> like. I definitely want to keep away from the PerLDAP api which doesn't
> provide much abstraction or object-orientation (good, standard
> initialization)

Take a look at "section LDAP APIs" found on:

  http://www.ietf.org/html.charters/ldapext-charter.html

The Java API is still heavily discussed but already on a very
detailed level.

I would like to stick to that.

Ciao, Michael.

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

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

On Tue, 8 May 2001, Joe Little typed thusly:

> Link all you want :)
done!

> Indeed. I know one of the maintainers of the PerLDAP stuff. Its not very
> pretty, but even the python-ldap code has gotten less pretty than I'd
> like. I definitely want to keep away from the PerLDAP api which doesn't
> provide much abstraction or object-orientation (good, standard
> initialization)

i suppose a first question is, how object-oriented do you want the
directory to appear? If you just want an 'ldap' object on which you
call various methods, with DNs and so forth, then that's pretty straight
forward. swig will do it. you get an ldap object per ldap server connection.

on the other hand, if you want every entry in the directory to be an object,
and maybe the attributes too then that's a bit more work and perhaps too
fine grained to get real work done with. for people who want to (say) write
graphical directory browsers, they'd end up using those patterns that
parallel object trees and it will get quite messy.

> > i feel its important to discuss how you'd like to see yourself
> > interacting
> > with ldap through python. there have been some past emails containing my
> > suggestions and fog has some work towards a high level X.500 interface
> > for python.
>
> I'll try and look into it. Any specific time period off hand?

now? ;)

> Full-featured would be great, but you are correct that there are new
> requirements and possibly a secure-access only API may be sufficient (as
> in more LDAP support and less LBER requirements).

sounds good.

different people on this list have different needs.

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

Why are apartments so close together?

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Joe L. <jl...@op...>]

Comments are below


On Tuesday, May 8, 2001, at 06:01  PM, David Leonard wrote:

>
>> http://open-it.org/download   (in either redhat6.2/RPMS or the like you
>> find it)
>
> ok to link to this from the 'download' page?
>

Link all you want :)

> I've used swig before, and ended up writing such python-specific code
> that swig was becoming a nusiance. You may have different experience,
> or maybe swig has gotten better.
>

It would appear that both SWIG and Zope's python-scripting have gotten 
better. The key definitely is making ldap OO enough...

> the point of using swig is to make it accessible in more scripting 
> languages
> than just python.. which is admittedly a nice thing. it means that more
> thought has to be put into the api.
>
>> Is python-ldap basically abandon-ware at this point? Being in "a3" for
>> about a year is pretty "abandoned" to me.
>
> yes its pretty close to abandonware :)
> with openldap2 a rewrite is a good idea. i personally just don't have
> much time nor motivation to do it all again. that's why its in 
> sourceforge :)
>
> the other thing that i do not track, but that stroeder seems to, is what
> o-o apis are emerging for ldap. there is the java-ldap ietf draft, there
> is also perl's (ugly imho).
>

Indeed. I know one of the maintainers of the PerLDAP stuff. Its not very 
pretty, but even the python-ldap code has gotten less pretty than I'd 
like. I definitely want to keep away from the PerLDAP api which doesn't 
provide much abstraction or object-orientation (good, standard 
initialization)

> i feel its important to discuss how you'd like to see yourself 
> interacting
> with ldap through python. there have been some past emails containing my
> suggestions and fog has some work towards a high level X.500 interface
> for python.
>

I'll try and look into it. Any specific time period off hand?

> on the other hand, just getting something to work with openldap2 via 
> swig
> would make progress and maybe that's all that you and other people
> really need?
>

Full-featured would be great, but you are correct that there are new 
requirements and possibly a secure-access only API may be sufficient (as 
in more LDAP support and less LBER requirements).

> go for it.
>
> d
>
> On Tue, 8 May 2001, Joe Little typed thusly:
>
>> Well, OpenLDAP feature sets do trully need to be supported, since I'll
>> be managing certificates and require TLS and such. Lovely that. So I
>> will either need to figure out how to fix python-ldap for modern ldap
>> libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the
>> SWIG approach may be necessary. What are list member preferences at 
>> this
>> stage. I was not utterly thrilled when I glanced at the current code
>> base. Associated with the swig approach, I may only need specific
>> functions to access LDAP and thus need only build a new simplified API
>> that hides c-specific calls to do the rest.
>
>
> --
> David Leonard                           Dav...@cs...
> Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
> The University of Queensland       |+|  
> http://www.csee.uq.edu.au/~leonard/
> QLD 4072  AUSTRALIA               ~` '~ 
> B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8
>
> Why are apartments so close together?
>

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

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

> http://open-it.org/download   (in either redhat6.2/RPMS or the like you
> find it)

ok to link to this from the 'download' page?

I've used swig before, and ended up writing such python-specific code
that swig was becoming a nusiance. You may have different experience,
or maybe swig has gotten better.

the point of using swig is to make it accessible in more scripting languages
than just python.. which is admittedly a nice thing. it means that more
thought has to be put into the api.

> Is python-ldap basically abandon-ware at this point? Being in "a3" for
> about a year is pretty "abandoned" to me.

yes its pretty close to abandonware :)
with openldap2 a rewrite is a good idea. i personally just don't have
much time nor motivation to do it all again. that's why its in sourceforge :)

the other thing that i do not track, but that stroeder seems to, is what
o-o apis are emerging for ldap. there is the java-ldap ietf draft, there
is also perl's (ugly imho).

i feel its important to discuss how you'd like to see yourself interacting
with ldap through python. there have been some past emails containing my
suggestions and fog has some work towards a high level X.500 interface
for python.

on the other hand, just getting something to work with openldap2 via swig
would make progress and maybe that's all that you and other people
really need?

go for it.

d

On Tue, 8 May 2001, Joe Little typed thusly:

> Well, OpenLDAP feature sets do trully need to be supported, since I'll
> be managing certificates and require TLS and such. Lovely that. So I
> will either need to figure out how to fix python-ldap for modern ldap
> libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the
> SWIG approach may be necessary. What are list member preferences at this
> stage. I was not utterly thrilled when I glanced at the current code
> base. Associated with the swig approach, I may only need specific
> functions to access LDAP and thus need only build a new simplified API
> that hides c-specific calls to do the rest.


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

Why are apartments so close together?

Re: ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Rich S. <rs...@zo...>]

I heartily endorse a SWIG approach.  Your source distribution can even
include the generated SWIG output for those without swig.
	/r$

ANNC and query: ldapmodule-1.10a3-patched RPMs available

[Joe L. <jl...@op...>]

So, I put together python-ldap RPMs/SRPMs for redhat 6.2 and 7.0 to go 
with my OpenLDAP 2.0.x RPMs on open-it.org. these include the patches 
spoken of before to support OpenLDAP 2.x.

http://open-it.org/download   (in either redhat6.2/RPMS or the like you 
find it)

This was done a while ago when I was doing some python-scripts against 
an LDAP tree (November). I'm now hell bent on using Zope to manage 
openldap, samba-tng, and other components necessary for Open-IT's goals. 
Well, OpenLDAP feature sets do trully need to be supported, since I'll 
be managing certificates and require TLS and such. Lovely that. So I 
will either need to figure out how to fix python-ldap for modern ldap 
libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the 
SWIG approach may be necessary. What are list member preferences at this 
stage. I was not utterly thrilled when I glanced at the current code 
base. Associated with the swig approach, I may only need specific 
functions to access LDAP and thus need only build a new simplified API 
that hides c-specific calls to do the rest.

Is python-ldap basically abandon-ware at this point? Being in "a3" for 
about a year is pretty "abandoned" to me.

Just trolling through the list via ZopeLDAP links and realized that I 
never did post my RPMs...

Re: Updated Lib/ldif.py

[Michael <mi...@st...>]

Cc:-ed to python-ldap-dev list since it might be interesting for
others...

Michael Schwartz wrote:
> =

> On Tue, 8 May 2001, Michael [iso-8859-1] Str=F6der wrote:
> =

> > Ah, ldif.CreateLDIF() does not add the necessary empty line to
> > separate entries.
> >
> That's great that you found the bug.

There seem to be a misunderstanding. This is an intended and
documented behaviour. I'm not sure why I left it out but there was
some reason (probably for having the possibility to add comment
lines with LDIF 1 format).

See web2ldap's module w2lsearch.py on how to write LDIF. Here's the
relevant excerpt.

------------------------ snip ------------------------
    # async search initiated before...

    result_type,result_dnlist =3D ls.l.result(ldap_msgid,0)
    while result_dnlist:
      for dn,entry in result_dnlist:
	outf.write('%s\n' %
ldif.CreateLDIF(dn,entry,w2lcore.ldap_binaryattrkeys))
      result_type,result_dnlist =3D ls.l.result(ldap_msgid,0)

------------------------ snip ------------------------

Ciao, Michael.

Updated Lib/ldif.py

[Michael <mi...@st...>]

HI!

I've committed a slightly modified module ldif.py to the CVS
archive.

Anyone using this module should check if there are any problems.

Ciao, Michael.

Re: Python and OpenLDAP 2

[Michael <mi...@st...>]

Stig, Konstantin,

sorry for the late reply. I was on vacation for two weeks.

Stig Venaas wrote:
> 
> A coworker asked me about Python and OpenLDAP 2.

Does your co-worker really need features of the OpenLDAP 2 libs?

> I thought you
> Konstantin were porting Python in order to help Michael use
> LDAPv3 stuff in web2ldap. How's it going?

The patches of Konstantin work but not thoroughly tested. You can do
a LDAPv3 bind a get search continuations, no schema or SSL/STARTTLS
support. There might be some cave-ats because the OpenLDAP 2 libs
seem to behave somewhat different.

> Will this be in official Python distribution at some point?

Many people are asking... Cc: to python-ldap-dev list.

> If my coworker wants to try
> Python and OpenLDAP 2, what should he do?

1. Grab the patches from the mailing list archive or ask me.
2. Subscribe to python-ldap-dev list.
3. Jump on in.

> Don't know anything about
> Python myself, although I've got friends raving about it (:

Stig, it's a shame! ;-)

Ciao, Michael.

Re: Bug#76717: 1.10alpha3 compiles against OpenLDAP 1 but not 2

[Michael <mi...@st...>]

Stephane Bortzmeyer wrote:
> 
> I can compile 1.0alpha3 without any problem on my Debian 2.2
> ("potato") machine (this is OpenLDAP version 1) but, on a future-2.3
> ("woody") machine, which has OpenLDAP 2:
> [..]
> I've read the archives of the mailing list and noted the thread
> "compiling against OpenLDAP 2.0.7" last month but I'm pessimistic: it
> seems there is no known solution.

There were two patches posted to the list earlier (December 2000?).
One of them (Konstantin's patch) even had support for LDAPv3 binds
and search continuations but is not ready for prime time yet.
web2ldap already contains code to abstract from the differences of
python-ldap built against OpenLDAP 2.0.x and do LDAPv3 binds (see
module ldapsession).

> Is is incredible that OpenLDAP 2 is still not supported.

There are so many incredible things out there...why bother with
python-ldap? ;-}

Serious: One of the main problems is that the OpenLDAP 2 API is
quite different. They dropped support for the old RFC1823 API
heading to LDAPEXT-API (Internet Draft). The other C APIs like e.g.
Netscape are quite different too (e.g. with setting options, SASL
and SSL/TLS). I did not manage to build against a recent version of
the Netscape SDK (which is a pity since it's the only thread-safe
LDAP C SDK out there).

> Is the software dead?

David Leonhard does not have the time to contribute anymore. I'm not
a C programmer myself. Therefore I can't help with the C part
(except excessively testing it).

Feel free to jump on in.

> Is there another Python-LDAP solution?

You might find some discussion about Sascha's SWIG-based approach in
python-ldap-dev list archive.

Another approach would be to build a completely new python-ldap
module maybe implemented mainly in Python with CPU intensive BER
en-/de-coding done in C (or optionally pure Python like the
cPickle/Pickle approach). The API design could be derived from the
Internet-Draft for a Java API which is still heavily discussed on
the ldapext list. But this would be a lot of ASN.1-related work and
I do not have enough unpayed spare time for it.

Again: Feel free to jump on in.

> <troll>Should I program in Perl?</troll>

Yes, probably. ;-}

Ciao, Michael.

publi/cursos:python-ldap-dev@lists.sourceforge.net

[curso-master<cu...@in...>]

<html>

<head>
<meta http-equiv="Content-Language" content="es">
<meta http-equiv="Content-Type" content="text/html; 
charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Pagina nueva 2</title>
</head>

<body>

<p><b><font color="#FF0000" size="3">DE SU MAXIMA 
ATENCION,GRACIAS</font></b></p>
<p><b>NOS RESULTA GRATO OFRECERLES NUESTROS CURSOS 
Y SERVICIOS PARA LA POTENCIACION Y  SUPERACION DE SUS
ACTIVIDADE</b>S .<font 
color="#FF0000">publi/desarrollo.</font></p>
<blockquote>
  <p><img border="0" 
src="file:///C:/Documents%20and%20Settings/J/Escritorio/CURSOS-VU
ELE.GIF" width="64" height="64"><img border="0" 
src="file:///C:/Documents%20and%20Settings/J/Escritorio/EMPRESAS
%20GRUPOS.GIF" width="200" height="64"><img border="0" 
src="file:///C:/Documents%20and%20Settings/J/Escritorio/MASTER.gif
" width="89" height="85"></p>
</blockquote>
<p><b>CURSOS PRACTICOS A DISTANCIA CURSOS  ACOGIDOS AL 
ART.126 DEL TRATADO DE MAASTRICH.ECC.(SOBRE EDUCACION 
A DISTANCIA). B.O.E.234.235.29.9.1.-10.90.<br>
SECCION SEGUNDA.NORMA CERTIFICADO CEE.<br>
</b><br>
<b><font color="#000080">AREA NET Y ECONOMIA:</font></b><br>
<b>MASTER WEB MASTER,MASTER MARKETIN NET,MASTER 
INTEGRAL  DISEŃO WEB,MASTER TECNICO EN COMUNICACIONES 
Y REDES,<br>
MASTER RELACIONES PUBLICAS,MASTER GESTION INMOBILIARIA 
E INVERSIONES,DIRECCION Y PLANIFICACION EMPRESA.<br>
<br>
</b><br>
<font color="#000080"><b>AREA SALUD:</b></font><br>
<b>MASTER EN NUTRITERAPIA,MASTER EN ACUPUNTURA Y 
MEDICINA CHINA,MASTER EN HOMEOPATIA,MASTER EN 
PSICOLOGIA SOCIAL,MASTER EN ECOLOGIA,MASTER EN 
SUPERACION DE STRESS,MASTER EN PSICOTERAPIA E 
HIPNOSIS.<br>
</b><br>
<b><font color="#000080">PARA MAS DE 
200.CURSOS,TITULACIONES AL MARGEN.<br>
ADMITIMOS Y PUNTUAMOS TESIS,EXPERIENCIA,HISTORIAL 
ACADEMICO,CONOCIMIENTOS AFINES.ECT.REPRESENTAMOS A 
VARIAS UNIVERSIDADES,CENTROS 
TECNOLOGICOS.</font></b></p>
<p><b><font color="#000080"><br>
ENVIE UN E-MAIL</font></b><br>
<a href="mailto:Int...@te..."><b><br>
</b></a><b><font 
color="#0000FF">CIE...@te...</font></b></p>
<p>&nbsp;</p>
<p><b>SOLICITE INFORMACION  POR FAX,,DETALLANDO COMO 
ASUNTO <font color="#FF0000">  EL CURSO DE</font></b></p>
<p><b>fax.34.968.28.04.16./34.965.35.04.17</b><br>
</p>
<p><b><br>
ATENTAMENTE:<br>
<br>
CARLOS  GORTAZAR<br>
IBER-NORT TRADE.SL/ESPAŃA<br>
INTERNATIONAL ESTUDIOS AREA<br>
MADRID,MOSCU,BALTIMORE<br>
PLAZA.AREA AVENIDA SAN ANTON<br>
30.008-MURCIA/ESPAŃA<br>
TLF.968.29.69.40.</b></p>
<p><b>SI QUIERE PODEMOS INFORMARLE SOBRE CONEXION 
SAT.8<font color="#FF0000">(SOLO
ESPAŃA)</font></b></p>
<p><img border="0" 
src="file:///C:/Documents%20and%20Settings/J/Escritorio/MARKETIN
G/CARTA-/SATELITE--.GIF" width="82" height="74"></p>
<p>&nbsp;</p>
<p><b>Si desea no 
recibir..email/remove&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </b><b><font 
color="#0000FF">CIE...@te...</font></b></p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p><b><br>
<br>
<br>
<br>
<br>
<br>
<br>
</b></p>

</body>

</html>

1.10alpha3 compiles against OpenLDAP 1 but not 2

[Stephane B. <bor...@ne...>]

I can compile 1.0alpha3 without any problem on my Debian 2.2
("potato") machine (this is OpenLDAP version 1) but, on a future-2.3
("woody") machine, which has OpenLDAP 2:

% gcc -fPIC  -I. -DLDAP_REFERRALS -g -O2 -Wall -Wstrict-prototypes -I/usr/include/python2.0 -I/usr/include/python2.0 -DHAVE_CONFIG_H -c /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c
/home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c: In function `LDAPinit_constants':
/home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: `LDAP_MAX_ATTR_LEN' undeclared (first use in this function)
/home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: (Each undeclared identifier is reported only once
/home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: for each function it appears in.)
/home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:82: `LDAP_REQ_UNBIND_30' undeclared (first use in this function)
...

Rightly, I do not find these symbols anywhere in OpenLDAP header
files.

I've read the archives of the mailing list and noted the thread
"compiling against OpenLDAP 2.0.7" last month but I'm pessimistic: it
seems there is no known solution.

Is is incredible that OpenLDAP 2 is still not supported. Is the
software dead? Is there another Python-LDAP solution? <troll>Should I
program in Perl?</troll>

web2ldap 0.9.0rc1

[Michael <mi...@st...>]

HI!

I'd like to announce a new release candidate of web2ldap found on

  http://www.web2ldap.de/

If there are no real showstoppers found in 0.9.0rc1 this will be
almost the final release 0.9.0 which is scheduled for 2001-05-10.

Ciao, Michael.

-lpthread + -D_REENTRANT

[Michael <mi...@st...>]

HI!

Is it possible to set gcc compiler option -D_REENTRANT and linker
option -lpthread in the autoconf script if Python was built
--with-threads?

Ciao, Michael.

Completely async...

[Michael <mi...@st...>]

HI!

I wrote a drop-in replacement class for LDAPObject for locking calls
into the LDAP libs since these are not completely thread-safe (see
attached gzip-ped module ldapthreading).

For letting other threads run the *_s() methods internally convert
the synchronous call from the application to asynchronous LDAPObject
method calls. Especially the result() method tries to do the timeout
handling to avoid hanging around in a ldap_result() call.

This seems to work in most situations (on my S.u.S.E. Linux 7.0
box). However it seems to me that the implementation of the result()
in python-ldap's LDAPObject.c is not really asynchronous.

Look at the following situation: The LDAPObject.result() method is
called like

  r = l.result(msgid,all=0,timeout=0)

This returns a tuple (restype,result) if the LDAP server has already
sent a result. But what happens if the LDAP server did not send
anything so far?

I would expect l.result() to return None in this case indicating
that no result was received so far which seems to be the case.

But how to distinguish between the LDAP server is still gathering
data and sent nothing so far and reaching the end of received
results? My tests are showing that in most cases None is also given
back byresult() when end of search results is reached.

Ciao, Michael.

web2ldap snapshot 20010413

[Michael <mi...@st...>]

HI!

I'd like to announce a new snapshot of web2ldap found on

  http://www.web2ldap.de/download.html

This snapshot tries to address problems with the LDAP libs which are
known not to be thread-safe. Basically calls into python-ldap are
locked by deploying a new wrapper class ldapthreading.LDAPObject
above ldap.LDAPOBject which also translates all synchronous calls
into asynchronous calls to let other threads run. This still does
not really solve the thread problems but makes things look much
better than in the last snapshot.

The caveat is that it seems not to work properly on Win32 platform.
I guess this problem is caused by the old Umich-DLLs I'm using under
Win32.

The detailed change history can be found here:

  http://www.web2ldap.de/changes.html

Please test it! Especially I'd like to hear of thread-related
experiences on other Unix platforms.

Installing is pretty convenient nowadays. Once you have Python 2.0
and python-ldap installed you can simply extract the tar.gz archive
and simply run sbin/web2ldap.py.

You can also help testing by (ab;-)using the on-line demo:

  http://www.web2ldap.de/demo.html

Ciao, Michael.