python-ldap-dev — discussion among developers

Re: LDAP ORM

[James A. <ja...@da...>]

On Mon, 2007-10-22 at 19:22 +0200, Michael Ströder wrote: 
> James Andrewartha wrote:
> > 
> > Thanks for the pointer. I've updated the code to map _ in attribute
> > names to -. Attributes without a short name are impossible to wrap - I'm
> > not expecting clients of this library to know OIDs.
> 
> If you don't support schema elements without NAME you're not LDAPv3
> compliant. I saw schema elements without NAME and my web2ldap choked on
> this in the beginning. In this case the LDAP server returns the OIDs in
> search results.

Ok, I've added handling for them - they should end up being accessible
by obj['9.9.9'], assuming the OID is returned as a string key in the
results dictionary.

Source is now available at
http://forgetldap.svn.sourceforge.net/viewvc/forgetldap/trunk/ thanks to
Gagatan on #luma. It now supports modification of an entry, although it
doesn't change the rdn as yet. I'll probably look at that after I add
support for saving changes back to the LDAP server.

Anil - I've added some notes at the bottom of the source on the API the
Django ORM expects, what does Pylons expect?

James Andrewartha

Re: Need information for Python Systems Administration Book

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

Noah Gift wrote:
> 
> I would love to talk to somebody on or offline about documenting
> python-ldap in an upcoming O'Reilly book on "Python for Systems
> Administration".

You're welcome to ask specific questions on this list.

Ciao, Michael.

Need information for Python Systems Administration Book

[Noah G. <noa...@gm...>]

Hi,

I would love to talk to somebody on or offline about documenting python-ldap
in an upcoming O'Reilly book on "Python for Systems Administration".


Thanks,


Noah Gift

building better binary eggs

[Brandon C. R. <br...@rh...>]

I use Zope and "buildout" and, like those who made some earlier posts
this year, I need binary eggs to install.  I note that no one has put
such eggs on the Cheese Shop, and the binary eggs that do exist and to
which people have offered URLs seem to depend on one's OS having
paritcular versions of particular libraries installed.

I want to suggest another approach: there needs to be an .egg for
python-ldap that simply includes in the .so file, statically linked,
all of the libraries it needs - so that the OpenLDAP and OpenSSL
libraries just come "built in" and working, and don't rely on your
even having those libraries available on your OS, much less having
them working.

Are there license problems that prevent this?

I had followed this approach with my "PyEphem" library.  I can't
imagine that many people would use it if they had to download and
install an obscure astronomy package first from a third party!  So my
package's _libastro.so file simply has the astronomy libraries
statically linked in, so nothing except Python and my module are
required for users to get started.

-- 
Brandon Craig Rhodes   br...@rh...   http://rhodesmill.org/brandon

Status of module dsml

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

James Andrewartha wrote:
> I had a quick look at porting the docstrings of dsml, but it refers
> to DSMLv1 when v2 was released in 2002.

python-ldap's module implements DSMLv1, not DSMLv2. Gee, looking at the
module I don't remember what I've implemented there...

You see, DSML is very low on my priority list. Frankly I have some
doubts about what it's good for. ;-)

Ciao, Michael.

Re: documentation updates

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

James,

first of all many thanks for your efforts working on this.

James Andrewartha wrote:
> 
> Is there anything else I need to do to get these applied, and the
> version of the docs on the website updated?

I've started reviewing your patches this morning and I have some doubts
about some details which need clarification. This will take a little
bit. I will follow-up on this when I have some spare time left. Maybe
tomorrow...

One general note: I didn't document some stuff since I didn't want to
endorse it because I don't consider certain APIs to be really stable
(say: designed well). Examples are class SmartLDAPObject, the API of
ldap.schema etc.

So take a break until I follow-up on this. Thanks again.

Ciao, Michael.

Re: documentation updates

[James A. <ja...@da...>]

On Tue, 2007-10-23 at 17:27 +0800, James Andrewartha wrote:
> On Tue, 2007-10-23 at 09:15 +0800, James Andrewartha wrote:
> > Hi,
> > 
> > The first patch removes an invalid LDAP option. The second updates the
> > LDAPObject documentation, and the third updates LDAPObject docstrings.
> > Hopefully I'll have time to look at updating the rest of the docs soon.
> 
> Here's one for ldap-controls.tex, and a minor fix to ldap/controls.py
> to use the constant it defines. I've noted that the controlValue passed
> to SimplePagedResultsControl's constructor is ignored, but didn't remove
> it because that would be an API change.

ldap-{cidict,resiter,sasl}.tex are all new files covering previously
undocumented modules. dn.diff adds the dn2str method and has a few
formatting fixes. contents.diff updates python-ldap.tex to include the
new sections, and I added a new chapter for ldapurl and ldif called
"Standalone modules". ldap.tex.2.diff applies over my previous patch and
adds a few references and more cleanups.

Remaining undocumented modules include all of ldap.schema and dsml. I
had a quick look at porting the docstrings of dsml, but it refers to
DSMLv1 when v2 was released in 2002. Under-documented modules (generally
only having examples) include ldap.async, ldif and ldapurl.

Is there anything else I need to do to get these applied, and the
version of the docs on the website updated?

James Andrewartha

Re: documentation updates

[James A. <ja...@da...>]

On Tue, 2007-10-23 at 09:15 +0800, James Andrewartha wrote:
> Hi,
> 
> The first patch removes an invalid LDAP option. The second updates the
> LDAPObject documentation, and the third updates LDAPObject docstrings.
> Hopefully I'll have time to look at updating the rest of the docs soon.

Here's one for ldap-controls.tex, and a minor fix to ldap/controls.py
to use the constant it defines. I've noted that the controlValue passed
to SimplePagedResultsControl's constructor is ignored, but didn't remove
it because that would be an API change.

James Andrewartha

documentation updates

[James A. <ja...@da...>]

Hi,

The first patch removes an invalid LDAP option. The second updates the
LDAPObject documentation, and the third updates LDAPObject docstrings.
Hopefully I'll have time to look at updating the rest of the docs soon.

James Andrewartha

Re: LDAP ORM

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

James Andrewartha wrote:
> 
> Thanks for the pointer. I've updated the code to map _ in attribute
> names to -. Attributes without a short name are impossible to wrap - I'm
> not expecting clients of this library to know OIDs.

If you don't support schema elements without NAME you're not LDAPv3
compliant. I saw schema elements without NAME and my web2ldap choked on
this in the beginning. In this case the LDAP server returns the OIDs in
search results.

Ciao, Michael.

Re: LDAP ORM

[James A. <ja...@da...>]

On Mon, 2007-10-22 at 16:13 +0200, Michael Ströder wrote:
> James Andrewartha wrote:
> > On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote:
> >> If you're using ldap.schema you might want to look into using class
> >> ldap.schema.models.Entry instead of simply ldap.cidict.cidict because
> >> you don't have to care about attribute description aliases and mapping
> >> them to OIDs.
> > 
> > I'm happy with the setup I've got now, but if I ever need to deal with
> > attribute OIDs then I'll look into it.
> 
> Well, it's not a matter of you personally need to deal with it. There
> might be the case that an attribute type or object class does not have
> NAME assigned at all. Also think about language sub-types and transfer
> type ;binary separated by ; from the name. And dashes (-) are allowed in
> AttributeTypeDescription. You really should dive into RFC 4512.

Thanks for the pointer. I've updated the code to map _ in attribute
names to -. Attributes without a short name are impossible to wrap - I'm
not expecting clients of this library to know OIDs. Attributes with
options are accessible via obj.['cn;lang-en'] (as are normal
attributes). There should probably be some functions to ask for a
specific language, RFC 3866 will guide me there.

James Andrewartha

Re: LDAP ORM

[James A. <ja...@da...>]

On Mon, 2007-10-22 at 07:12 -0700, Anil Jangity wrote:
> I was toying with the idea of doing just this thing a few days ago.
> It'll be nice if it also handles all the modifications of an entry
> with ease. (changing rdn when the attributes change etc...)
> 
> Let me know how I can help. :)

Well, have a look and see if what I've got so far seems sane, or if it
needs more comments/explanation etc.

> My main dev environment is pylons. Site doesn't work.
> 
> ~ $ wget http://trs80.ucc.asn.au/ldaporm.py
> --07:11:50--  http://trs80.ucc.asn.au/ldaporm.py
>            => `ldaporm.py'
> Resolving trs80.ucc.asn.au... 130.95.13.9
> Connecting to trs80.ucc.asn.au[130.95.13.9]:80... connected.
> HTTP request sent, awaiting response... 500 Internal Server Error
> 07:11:51 ERROR 500: Internal Server Error.

Oops, it wasn't supposed to be interpreted by the webserver. Try
http://trs80.ucc.asn.au/ldaporm.pys instead.

James Andrewartha

Re: LDAP ORM

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

James Andrewartha wrote:
> On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote:
> 
>> If you're using ldap.schema you might want to look into using class
>> ldap.schema.models.Entry instead of simply ldap.cidict.cidict because
>> you don't have to care about attribute description aliases and mapping
>> them to OIDs.
> 
> I'm happy with the setup I've got now, but if I ever need to deal with
> attribute OIDs then I'll look into it.

Well, it's not a matter of you personally need to deal with it. There
might be the case that an attribute type or object class does not have
NAME assigned at all. Also think about language sub-types and transfer
type ;binary separated by ; from the name. And dashes (-) are allowed in
AttributeTypeDescription. You really should dive into RFC 4512.

Ciao, Michael.

Re: LDAP ORM

[James A. <ja...@da...>]

On Mon, 2007-10-22 at 15:05 +0200, Michael Ströder wrote:
> James Andrewartha wrote:
> > 
> > --- cidict.py~  2003-08-25 00:28:12.000000000 +0800
> > +++ cidict.py   2007-10-22 20:16:54.000000000 +0800
> > @@ -43,6 +43,9 @@
> >    def has_key(self,key):
> >      return UserDict.has_key(self,lower(key))
> > 
> > +  def __contains__(self,key):
> > +    return UserDict.has_key(self,lower(key))
> > +
> >    def get(self,key,failobj=None):
> >      try:
> >        return self[key]
> 
> I'd prefer if it's ok for you:
> 
>   def __contains__(self,key):
>     return self.has_key(self,key)

Sure, I was just copying has_key().

> If you're using ldap.schema you might want to look into using class
> ldap.schema.models.Entry instead of simply ldap.cidict.cidict because
> you don't have to care about attribute description aliases and mapping
> them to OIDs.

I'm happy with the setup I've got now, but if I ever need to deal with
attribute OIDs then I'll look into it.

James Andrewartha

Re: LDAP ORM

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

James Andrewartha wrote:
> 
> --- cidict.py~  2003-08-25 00:28:12.000000000 +0800
> +++ cidict.py   2007-10-22 20:16:54.000000000 +0800
> @@ -43,6 +43,9 @@
>    def has_key(self,key):
>      return UserDict.has_key(self,lower(key))
> 
> +  def __contains__(self,key):
> +    return UserDict.has_key(self,lower(key))
> +
>    def get(self,key,failobj=None):
>      try:
>        return self[key]

I'd prefer if it's ok for you:

  def __contains__(self,key):
    return self.has_key(self,key)

If you're using ldap.schema you might want to look into using class
ldap.schema.models.Entry instead of simply ldap.cidict.cidict because
you don't have to care about attribute description aliases and mapping
them to OIDs.

Ciao, Michael.

LDAP ORM

[James A. <ja...@da...>]

Hi all,

The current Python LDAP interface is a bit low level for my liking, so
I've started work on an LDAP ORM[1]. Currently there's very little RM
going on, but I have got a nice Python object representing an LDAP
object with attribute access and deletion, no adding or saving to the
ldap server just yet. ldap.schema is really quite handy. 

Which brings me to my next point - could someone update the API docs on
the website? They're 3.5 years out of date, and so missing things like
ldap.schema and cidict.

Here's a patch for cidict to implement __contains__, which makes foo in
somecidict work right:

--- cidict.py~  2003-08-25 00:28:12.000000000 +0800
+++ cidict.py   2007-10-22 20:16:54.000000000 +0800
@@ -43,6 +43,9 @@
   def has_key(self,key):
     return UserDict.has_key(self,lower(key))

+  def __contains__(self,key):
+    return UserDict.has_key(self,lower(key))
+
   def get(self,key,failobj=None):
     try:
       return self[key]

Anyway, I'd appreciate any comments or suggestions (including for a new
name) on LDAP ORM. I have a vague goal of being able to use LDAP as an
ORM for Django or whatever other web framework tickles your fancy.

[1] http://trs80.ucc.asn.au/ldaporm.py

James Andrewartha

Re: ldap controls

[Matej V. <ve...@de...>]

Stefan Gohmann <go...@un...> writes:

> Am Donnerstag, 20. September 2007 10:57 schrieb Michael Str=F6der:
>> In the source distribution:
>>
>> Demo/page_control.py
>> Demo/ldapcontrols.py
>> Demo/matchedvalues.py
>
> Ah, these files are not in the debian package. Thanks.

Actually, they're in the python-ldap-doc package, in
/usr/share/doc/python-ldap-doc/examples/.

Cheers,

Matej

Re: ldap controls

[Stefan G. <go...@un...>]

Am Donnerstag, 20. September 2007 11:21 schrieb Stefan Gohmann:
> Am Donnerstag, 20. September 2007 10:57 schrieb Michael Str=F6der:
> > Stefan Gohmann wrote:
> > > where could I find some examples or docs for using ldap controls with
> > > python-ldap?
> >
> > Which particular controls are you interested in?
>
> I want to search for deleted objects, 1.2.840.113556.1.4.417.
>
> > In the source distribution:
> >
> > Demo/page_control.py
> > Demo/ldapcontrols.py
> > Demo/matchedvalues.py
>
> Ah, these files are not in the debian package. Thanks.

The following code works for me:

lc1 =3D LDAPControl('1.2.840.113556.1.4.417',criticality=3D1)
lo.search_ext_s(base,ldap.SCOPE_SUBTREE,filter,serverctrls=3D[lc1])

Cheers
Stefan

=2D-=20
Stefan Gohmann         Entwicklung              go...@un...
Univention GmbH        Linux for your Business  fon: +49 421 22 232- 0
Mary-Somerville-Str.1  28359 Bremen             fax: +49 421 22 232-99
                       http://www.univention.de

Re: ldap controls

[Stefan G. <go...@un...>]

Am Donnerstag, 20. September 2007 10:57 schrieb Michael Str=F6der:
> Stefan Gohmann wrote:
> > where could I find some examples or docs for using ldap controls with
> > python-ldap?
>
> Which particular controls are you interested in?

I want to search for deleted objects, 1.2.840.113556.1.4.417.

> In the source distribution:
>
> Demo/page_control.py
> Demo/ldapcontrols.py
> Demo/matchedvalues.py

Ah, these files are not in the debian package. Thanks.

Cheers,
Stefan
=2D-=20
Stefan Gohmann         Entwicklung              go...@un...
Univention GmbH        Linux for your Business  fon: +49 421 22 232- 0
Mary-Somerville-Str.1  28359 Bremen             fax: +49 421 22 232-99
                       http://www.univention.de

Re: ldap controls

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

Stefan Gohmann wrote:
> 
> where could I find some examples or docs for using ldap controls with 
> python-ldap?

Which particular controls are you interested in?

In the source distribution:

Demo/page_control.py
Demo/ldapcontrols.py
Demo/matchedvalues.py

Ciao, Michael.

ldap controls

[Stefan G. <go...@un...>]

Hello,

where could I find some examples or docs for using ldap controls with 
python-ldap?

Thanks.

Cheers
Stefan
-- 
Stefan Gohmann         Entwicklung              go...@un...
Univention GmbH        Linux for your Business  fon: +49 421 22 232- 0
Mary-Somerville-Str.1  28359 Bremen             fax: +49 421 22 232-99
                       http://www.univention.de

Re: [PATCH] default values

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

Geert Jansen wrote:
> 
> the attached patch allows you to use default values for the
> functions/arguments below. This is helpful in an environment where
> /etc/openldap/ldap.conf is kept up to date with correct information.

Sorry, I won't accept this patch for general use. Note: This behaviour
is not guaranteed to work in future versions of python-ldap. In the
future there MAY be a change to another/additional LDAP client lib which
does not have a ldap.conf at all.

I consider python-ldap to rather provide a low-level API. Applications
implemented on top of python-ldap should deal with whatever config file
they like passing all required parameters around. Hiding config file
access within such a low-level module is IMO bad design.

Ciao, Michael.

Re: Build Errors (LDAP_OPT_X... undeclared)

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

Torsten Kurbad wrote:
> 
> Anyway, Eric HAS the 2.3.x libs installed and used the 2.2.x headers
> for no good reason. That's what I wanted to point out...

Got your message. But I wanted to make sure that it won't get misunderstood.

Ciao, Michael.

Re: Build Errors (LDAP_OPT_X... undeclared)

[Torsten K. <pyt...@tk...>]

> > I had similar problems when building python-ldap on Mac OSX, where
> > openldap 2.2.x is installed by default. Simply "stealing" the 2.3
> > headers from a Linux system did the trick there.
> 
> This workaround is very bad practice. You MUST NOT mix headers and
> libs from different OpenLDAP versions. This can lead to serious
> crashs. Please don't ask for support if you're doing something like
> this.

I won't... This was part of my .egg project - and was merely a
test. ;o)
But it showed clearly that it's problematic to build python-ldap-2.3.1
with OpenLDAP 2.2.x, which I didn't know beforehand.

Anyway, Eric HAS the 2.3.x libs installed and used the 2.2.x headers
for no good reason. That's what I wanted to point out...

Regards,
Torsten
-- 
  I am a deeply superficial person. -Andy Warhol

Re: Build Errors (LDAP_OPT_X... undeclared)

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

Torsten Kurbad wrote:
> 
> I had similar problems when building python-ldap on Mac OSX, where
> openldap 2.2.x is installed by default. Simply "stealing" the 2.3
> headers from a Linux system did the trick there.

This workaround is very bad practice. You MUST NOT mix headers and libs
from different OpenLDAP versions. This can lead to serious crashs.
Please don't ask for support if you're doing something like this.

Ciao, Michael.