python-ldap-dev — discussion among developers

Re: Implementation of LDAPControls

[Deepak G. <de...@ar...>]

On Fri, 2005-02-25 at 18:29 +0100, Michael Str=F6der wrote:
> I've committed your patches to CVS since they seem to be the most=20
> complete solution.=20

Great! :)=20

Regarding your suggestions, I've attached a new patch (I diff'ed against
the cvs HEAD).=20

> But I'd really prefer to have code without=20
> goto-statements. Could you please work out a solution for this?=20

Done!

(FWIW, I'd prefer to have code without goto-statements, too, but I'm of
the opinion that error handling in C is one of the few situations in
which goto's actually *help* readability. But since you're the boss,
I'll heed your conventions. :) )

> And=20
> maybe it would be nice to extract the helper functions for LDAPControls=
=20
> to a separate C source text called ldapcontrols.c?

Done!

> One thing I wonder about is whether it's possible to send a control=20
> where the control value is absent (e.g. by passing None as control=20
> value)? See RFC3296 chapter 3 for an example (ManageDsaIT Control).

Done!

(Before, an error would have been thrown. Now, 'None' is permitted.)

> Thanks again for working on it!

No problem. :)

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Re: Error: Schema fetching on Oracle Directory Server

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

Wido Depping wrote:
> 
> Attached are the updated testcase file and my improved split_tokens() function.
> This time I use string.split() and string.join() to benefit from their
> speed. The added checking in order to comply with the test cases has
> the result, that the new algorithm is only slightly faster than the
> old one. But now it should work with all known servers :)

Your patches were added to CVS. The test script I've checked in does not 
work although the new version of split_tokens() seems to work correctly. 
But I've committed it anyway to save the new test cases.

Note that there was also a change necessary to ldap.schema.models:

http://cvs.sourceforge.net/viewcvs.py/python-ldap/python-ldap/Lib/ldap/schema/models.py?r1=1.26&r2=1.27

(CVS changes might not yet be up-to-date in the web interface.)

Ciao, Michael.

Re: Implementation of LDAPControls

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

Deepak Giridharagopal wrote:
> 
> I've attached a unified diff of my changes, which as I said before are
> modeled closely after the existing implementation of LDAPMod structures.

I've committed your patches to CVS since they seem to be the most 
complete solution. But I'd really prefer to have code without 
goto-statements. Could you please work out a solution for this? And 
maybe it would be nice to extract the helper functions for LDAPControls 
to a separate C source text called ldapcontrols.c?

One thing I wonder about is whether it's possible to send a control 
where the control value is absent (e.g. by passing None as control 
value)? See RFC3296 chapter 3 for an example (ManageDsaIT Control).

Now for the Python parts:

I fixed some wrong argument lists in ldap.ldapobject.LDAPObject to make 
it work correctly at that level.
(Note that importing _ldap is considered bad!)

I also started to work on a basic Python class API in sub-module 
ldap.controls. I could not test it yet. But you get the idea.

Regarding ManageDsaIT Control: Once support for LDAPControls is complete 
I think we SHOULD drop l_ldap_manage_dsa_it() in LDAPObject.c and 
re-implement it completely in method 
ldap.ldapobject.LDAPObject.manage_dsa_it().

> I wouldn't turn down a mention at
> the bottom of the README file, though. :)

Already in CVS. Thanks again for working on it!

Ciao, Michael.

Re: Implementation of LDAPControls

[Ingo S. <st...@un...>]

Am Dienstag, 22. Februar 2005 09:57 schrieb Michael Str=F6der:
> Deepak Giridharagopal wrote:
> > My approach has been to model the OpenLDAP LDAPControl struct as a
> > tuple:
> >
> > (OID <string>, Criticality Flag <boolean>, Value <string/list of bytes>)
>
> I'd prefer to have a dedicated class hierachy for this in a separate
> sub-module ldap.controls. I will provide something for it which is
> compatible with your modifications to LDAPObject.c.
>
> > The "Value" field needs to be an ASN.1 encoded list of bytes.
> > [..]
> > # Here's where I actually construct the payload. The payload for this
> > # AD control needs to be an ASN.1 sequence with a single int inside.
> > payload =3D asn1.Sequence()
> > payload.append(0xf)
> >
> > # Ta da, here is the control
> > control =3D ( oid, criticality, payload.encode() )
>
> I think we could move the invocation of .encode() for all controls in a
> list into the wrapper classldap.ldapobject.LDAPObject. Together with a
> well-defined control class possible type conflicts would clash early in
> the Python wrapper code. This makes debugging easier.

This is prepared in our implementation, we would see the BerVal (or "payloa=
d")=20
as python-class which internaly saves types and values which should be used=
=20
for encoding. But I don't expect that we will implement this in the near=20
future...

Regards
Ingo


> Ciao, Michael.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

=2D-=20
Ingo Steuwer       st...@un...         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99

Re: Implementation of LDAPControls

[Deepak G. <de...@ar...>]

On Tue, 2005-02-22 at 09:57 +0100, Michael Str=F6der wrote:
> > My approach has been to model the OpenLDAP LDAPControl struct as a
> > tuple:
> >=20
> > (OID <string>, Criticality Flag <boolean>, Value <string/list of byte=
s>)
>=20
> I'd prefer to have a dedicated class hierachy for this in a separate=20
> sub-module ldap.controls. I will provide something for it which is=20
> compatible with your modifications to LDAPObject.c.

Great! I held off on implementing a higher-level abstraction since I
wanted to get opinions first on the lower level patch. But it's awesome
that we're moving forward on this. :)

On Tue, 2005-02-22 at 09:43 +0100, Michael Str=F6der wrote:=20
> Jeremy, the author of picses, already planned to negotiate a more=20
> liberal license with CNRI. A similar license issue was solved for Pytho=
n=20
> itself before. But AFAIK no progress so far.

That's too bad. :( I'll take a look at pysnmp.ber and see how it
compares.

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Re: Implementation of LDAPControls

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

Deepak Giridharagopal wrote:
> 
> My approach has been to model the OpenLDAP LDAPControl struct as a
> tuple:
> 
> (OID <string>, Criticality Flag <boolean>, Value <string/list of bytes>)

I'd prefer to have a dedicated class hierachy for this in a separate 
sub-module ldap.controls. I will provide something for it which is 
compatible with your modifications to LDAPObject.c.

> The "Value" field needs to be an ASN.1 encoded list of bytes.
> [..]
> # Here's where I actually construct the payload. The payload for this
> # AD control needs to be an ASN.1 sequence with a single int inside.
> payload = asn1.Sequence()
> payload.append(0xf)
> 
> # Ta da, here is the control
> control = ( oid, criticality, payload.encode() )

I think we could move the invocation of .encode() for all controls in a 
list into the wrapper classldap.ldapobject.LDAPObject. Together with a 
well-defined control class possible type conflicts would clash early in 
the Python wrapper code. This makes debugging easier.

Ciao, Michael.

Re: Implementation of LDAPControls

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

Deepak Giridharagopal wrote:
> 
> That said, for the moment I've been using Pices' ASN.1 encoding module.
> It's a single Python file and trivial to use:
> 
> http://www.cnri.reston.va.us/software/pisces/manual/module-pisces.asn1.html

I use a slightly improved version of it in web2ldap for the built-in 
X.509 certificate/CRL parser.

There are some issues with the CNRI license which prevents this module 
to be shipped with Debian Linux. See http://bugs.debian.org/80195 for a 
discussion about it.

Jeremy, the author of picses, already planned to negotiate a more 
liberal license with CNRI. A similar license issue was solved for Python 
itself before. But AFAIK no progress so far.

I have to look into module pysnmp.ber. Found some old conversation with 
Ilya in my archive about implementing a ASN.1 module...
(In the year 2000! time is running...!)

Ciao, Michael.

Re: Implementation of LDAPControls

[Deepak G. <de...@ar...>]

On Mon, 2005-02-21 at 19:02 +0100, Michael Str=F6der wrote:
> Ingo Steuwer wrote:
> >=20
> > Enclosed you find my mail including the necessary code-extraction=20
> > for basic ldap-controls in python-ldap.
>=20
> Glad to see some progress in this field. Thanks.
>=20
> Could you please send a unified diff against the CVS tree? I will take =
a=20
> closer look at it.

Well, I'm not Ingo, but for my university here I've finished support for
LDAP controls. This includes server and client control support for every
ldap_*_ext method in LDAPObject.c, and I've also implemented set_option
and get_option (from options.c) for both types of controls as well.

My modifications of the ldap_*_ext functions are always the same 3
steps:
1) Parse the serverctrls and clientctrls PyObjects into an array of
LDAPControl structs

2) Modify the actual libldap function call to use those parsed arrays
instead of NULL like we're doing now

3) De-allocate those newly created LDAPControl arrays.

You can see an example of usage in my previous email to the list.

I've attached a unified diff of my changes, which as I said before are
modeled closely after the existing implementation of LDAPMod structures.

> I'm not a lawyer. But I guess strictly speaking we would need kind of a=
=20
> legal person to give the copyright to. Maybe contributing the code unde=
r=20
> Python style license would be easier...sigh!

Copyright for the patch is all yours! I wouldn't turn down a mention at
the bottom of the README file, though. :)

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Re: Native python LDAP?

[Richard M. <ri...@ne...>]

mi...@st... wrote:

> Rich,
>
> nice to see you here. Sorry for following up so late. I'm swamped with 
> orga stuff so this rather long response took a while...
>
> Rich Megginson wrote:
>
>> Has anyone ever thought about doing a native (not based on ldap sdk 
>> binaries) python LDAP client?
>
>
> Yes, every now and then I'm thinking about this. In fact the 
> LDAPObject wrapper class was the first step towards that. Modules 
> ldap.schema, ldif and ldapurl are pure Python by purpose. I wanted to 
> reduce dependencies on LDAP C SDKs whereever I could...
>
> Actually there is 'ldaptor' which is a pure-Python LDAP implementation 
> based on Twisted. But the web site is very unclear, no docs, no 
> release history, no response from the author to my request of working 
> together, and last not least a strong dependency on Twisted. :-(

Interesting . . .

>
> There are various good reasons for reimplementing python-ldap from the 
> ground up.
>
> The RFC1823-style API still looks through the LDAPObject class letting 
> application code look very unpythonic.

Would definitely prefer to have a Python object model instead of a C API 
model.

>
> The data types returned from and passed to LDAPObject methods are not 
> specific to python-ldap:
> - list of dicts for search results

However, it is nice to be able to be able to expose those data 
structures in pure python for other applications.

> - no clear distinction between search results and search continuations
> - raw lists for change records
> etc.
>
> With LDAPControls we cannot stay away from messing with BER any 
> longer. Therefore we could reimplement much of the LDAP protocol stuff 
> following a nice object model.

Right.

>
> Compiling the various SDKs is a mess on some platforms (e.g. building 
> OpenLDAP libs on Win32). The binaries are often behind the current 
> release although some people are really doing great work providing 
> up-to-date pre-built binaries.

Right.  The Mozilla LDAP C SDK is more Windows friendly (since it is in 
Mozilla and Thunderbird).

>
> Licensing situation not suitable for contributing python-ldap to 
> Python's standard lib.
>
> etc.
>
>> Something like Net::LDAP (which is a very nice object model, even 
>> though it's perl).
>
>
> Don't know this since I never used Perl. If it's really a good object 
> model we could simply borrow from it.

You should definitely take a look at it, and the way it keeps the object 
model throughout. the various layers.
http://cpan.uwinnipeg.ca/module/Net::LDAP
and especialy the ASN.1 parser:
http://cpan.uwinnipeg.ca/module/Convert::ASN1

>
>> It depends on several modules being available.
>
>
> Yes, that's where the sadness begins...
>
>> For example, is there a python ASN.1 parser?
>
>
> The short answer: No there's no standard ASN.1 / BER / DER module for 
> Python which could just be imported by python-ldap without any 
> licensing and installation hassles.
>
> The long answer:
>
> There are some BER modules in SNMP modules. Don't know how to solve 
> the licensing issues.
>
> In web2ldap I'm using a slightly modified version of pisces.asn1 which 
> is under old CNRI license. The author planned to work out a better 
> license with CNRI but got stuck.
>
> => It boils down to developing a ASN.1 module and contribute it to 
> Python's standard libs (following licensing advice by PSF from the 
> very beginning).
>
>> Most everything else is already available in python - sockets, ssl, etc.
>
>
> Hmm, SSL support in Python's standard lib is very basic. AFAIK there's 
> no proper certificate and CRL checking at all. And there's also SASL, 
> Kerberos, etc. to think about.

I'm not sure if native python SSL support is best.  Perhaps there are 
wrappers around openssl or Mozilla NSS (which has much better support 
for CRL, OSCP, etc.).  Maybe the best thing to do would be to use SWIG 
to generate wrappers.  Just like in perl - I'm not aware of a native 
Perl SSL implementation - just wrappers around openssl.  Not sure about 
SASL either, but it seems that there would be a general need for a SASL 
module in python.  Or again, a wrapper around cyrus sasl.

As you can probably tell, I have a lot of experience with perl :-)  But 
very little with python, but I have come to realize the power and 
usefulness of python over perl for these sorts of applications.

>
> Off course I'd be willing to put work into it. But it would need 
> several developers to reach the same functional level as today's 
> python-ldap within a reasonable time frame.

Sure.

>
> Let's discuss design goals...mine are:
>
> Let's call the module 'ldap2'.
>
> 'ldap2' should go into Python's standard lib in the long run.
>
> Drop back-ward compabilty to 'ldap'. One could try to implement a 
> compability class API later but this should not be a first-time 
> requirement which then turns out to be an obstacle for a clean object 
> model.
>
> Drop support for Python versions prior 2.3 (because of sets, datetime 
> and various other modules)
>
> Add support for Unicode whereever suitable.

That sounds like the right things to do.

>
> ....to be continued...
>
> Ciao, Michael.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: Implementation of LDAPControls

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

Ingo Steuwer wrote:
> 
> Enclosed you find my mail including the necessary code-extraction 
> for basic ldap-controls in python-ldap.

Glad to see some progress in this field. Thanks.

Could you please send a unified diff against the CVS tree? I will take a 
closer look at it.

There's also another issue with licensing:
Which plans Univention has with this code? Would Univention be willing 
to give away copyright so that some time in the future we can 
stream-line the licensing?
I'm not a lawyer. But I guess strictly speaking we would need kind of a 
legal person to give the copyright to. Maybe contributing the code under 
Python style license would be easier...sigh!

Please consult your management and your legal department before we can 
incorporate code into the python-ldap CVS.

Ciao, Michael.

Re: Native python LDAP?

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

Rich,

nice to see you here. Sorry for following up so late. I'm swamped with 
orga stuff so this rather long response took a while...

Rich Megginson wrote:
> Has anyone ever thought about doing a native (not based on ldap sdk 
> binaries) python LDAP client?

Yes, every now and then I'm thinking about this. In fact the LDAPObject 
wrapper class was the first step towards that. Modules ldap.schema, ldif 
and ldapurl are pure Python by purpose. I wanted to reduce dependencies 
on LDAP C SDKs whereever I could...

Actually there is 'ldaptor' which is a pure-Python LDAP implementation 
based on Twisted. But the web site is very unclear, no docs, no release 
history, no response from the author to my request of working together, 
and last not least a strong dependency on Twisted. :-(

There are various good reasons for reimplementing python-ldap from the 
ground up.

The RFC1823-style API still looks through the LDAPObject class letting 
application code look very unpythonic.

The data types returned from and passed to LDAPObject methods are not 
specific to python-ldap:
- list of dicts for search results
- no clear distinction between search results and search continuations
- raw lists for change records
etc.

With LDAPControls we cannot stay away from messing with BER any longer. 
Therefore we could reimplement much of the LDAP protocol stuff following 
a nice object model.

Compiling the various SDKs is a mess on some platforms (e.g. building 
OpenLDAP libs on Win32). The binaries are often behind the current 
release although some people are really doing great work providing 
up-to-date pre-built binaries.

Licensing situation not suitable for contributing python-ldap to 
Python's standard lib.

etc.

> Something like Net::LDAP (which is a very 
> nice object model, even though it's perl).

Don't know this since I never used Perl. If it's really a good object 
model we could simply borrow from it.

> It depends on several modules being available.

Yes, that's where the sadness begins...

> For example, is there a python ASN.1 parser?

The short answer: No there's no standard ASN.1 / BER / DER module for 
Python which could just be imported by python-ldap without any licensing 
and installation hassles.

The long answer:

There are some BER modules in SNMP modules. Don't know how to solve the 
licensing issues.

In web2ldap I'm using a slightly modified version of pisces.asn1 which 
is under old CNRI license. The author planned to work out a better 
license with CNRI but got stuck.

=> It boils down to developing a ASN.1 module and contribute it to 
Python's standard libs (following licensing advice by PSF from the very 
beginning).

> Most everything else is already available in python - sockets, ssl, etc.

Hmm, SSL support in Python's standard lib is very basic. AFAIK there's 
no proper certificate and CRL checking at all. And there's also SASL, 
Kerberos, etc. to think about.

Off course I'd be willing to put work into it. But it would need several 
developers to reach the same functional level as today's python-ldap 
within a reasonable time frame.

Let's discuss design goals...mine are:

Let's call the module 'ldap2'.

'ldap2' should go into Python's standard lib in the long run.

Drop back-ward compabilty to 'ldap'. One could try to implement a 
compability class API later but this should not be a first-time 
requirement which then turns out to be an obstacle for a clean object model.

Drop support for Python versions prior 2.3 (because of sets, datetime 
and various other modules)

Add support for Unicode whereever suitable.

....to be continued...

Ciao, Michael.

Re: Implementation of LDAPControls

[Ingo S. <st...@un...>]

Am Freitag, 18. Februar 2005 19:53 schrieb Deepak Giridharagopal:
> Hello, me again. :)
>
> On Thu, 2005-02-17 at 16:30 -0600, Deepak Giridharagopal wrote:
> > The project I'm working on is at a point where this feature is a
> > necessity, so if implementation of this feature is at a standstill I'm
> > willing to get the ball rolling again.
>
> As a proof of concept, I've gone ahead and begun coding up support for
> LDAP Controls. My goal for the test was to successfully do an
> ldap_modify_ext operation on our Active Directory server, using AD's
> Security Descriptor Modification control (http://tinyurl.com/5tlok).
>
> It works great!
>

Hello

I answered your mail yesterday but it was rejected because my attachement w=
as=20
too big. Enclosed you find my mail including the necessary code-extraction=
=20
for basic ldap-controls in python-ldap.

Regards
Ingo Steuwer

> Hello
>=20
> we've implemented basic support for LDAP-Controls in Python LDAP. We defi=
ned=20
> an LDAPControl Python-class and some helper function and pre-defined OID'=
s=20
> for using it. It is prepared for but lacks support of bervals (we don't n=
eed=20
> it at the moment). We're using this version in our test-cases and think i=
t=20
is=20
> stable.
>=20
> You can i.e. see deleted DN's in AD by using:
>=20
> ------------------------------------------------------------------------
> import ldap
> lo =3D ldap.open("ad-host")
> login_dn =3D "cn=3DAdministrator,cn=3DUsers,dc=3Dwindomain"
> login_pw =3D 'secret'
>=20
> lo.simple_bind_s(login_dn, login_pw)
> lc1 =3D ldap.create_control("LDAP_SERVER_SHOW_DELETED_OID")
> res =3D lo.search_ext_s(
> =A0"dc=3Dw2k3st,dc=3Dunivention,dc=3Dde",ldap.SCOPE_SUBTREE,sys.argv[1],s=
erverctrls=3D[lc1])
> # print res
> ------------------------------------------------------------------------
>=20
> I wanted to send you this files earlier, but didn't had the time for it.=
=20
> Attached you will find a tgz of "our" python-ldap -- I'm still to short o=
n=20
> time to make a patch...
>=20
> Included is an other extension of python-ldap which makes it possible to=
=20
> request ldap-schema-definitions from an open-ldap-server. We're using thi=
s=20
> for a long time but AFAIK it is not our implementation (at least not mine=
).
>=20
> To get a part of the "official" python-ldap package our=20
> LDAP-Control-Implementation is provided with acknowledgment of the=20
> python-license and there provided without any guaranty -- which means we =
are=20
> not responsible for your problems with our code. Enough=20
> "Legal-Department"-comments.
>=20
> We're interested in your meanings and experiences looking at or using our=
=20
code=20
> and will try to help if there are any problems.
>=20
> Regards
> Ingo Steuwer
>=20


=2D-=20
Ingo Steuwer       st...@un...         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99

Re: Implementation of LDAPControls

[Deepak G. <de...@ar...>]

Hello, me again. :)

On Thu, 2005-02-17 at 16:30 -0600, Deepak Giridharagopal wrote:
> The project I'm working on is at a point where this feature is a
> necessity, so if implementation of this feature is at a standstill I'm
> willing to get the ball rolling again.

As a proof of concept, I've gone ahead and begun coding up support for
LDAP Controls. My goal for the test was to successfully do an
ldap_modify_ext operation on our Active Directory server, using AD's
Security Descriptor Modification control (http://tinyurl.com/5tlok).

It works great!

I've only so far implemented control support in:
set_option
ldap_search_ext
ldap_modify_ext

...but adding support for the other LDAP operations (I hope) should be
easy.

My approach has been to model the OpenLDAP LDAPControl struct as a
tuple:

(OID <string>, Criticality Flag <boolean>, Value <string/list of bytes>)

The "Value" field needs to be an ASN.1 encoded list of bytes. I've taken
the position that however the user actually encodes his Python data
structure into ASN.1 is (for the moment) not my concern. This way, the C
code remains simple. 

I figure that once we settle on a pure-python ASN.1 encoding module, we
can handle marshalling/unmarshalling an LDAPControl object's payload at
a higher level than the C code, perhaps in a utility module like
"modlist.py" ("control_builder.py"?).

That said, for the moment I've been using Pices' ASN.1 encoding module.
It's a single Python file and trivial to use:

http://www.cnri.reston.va.us/software/pisces/manual/module-pisces.asn1.html

Here is the code I use to set a control:

#######################
import asn1 # This is the Pices module

# This is the OID for the MS security descriptor control I described
# above.
oid = "1.2.840.113556.1.4.801"
criticality = 1

# Here's where I actually construct the payload. The payload for this
# AD control needs to be an ASN.1 sequence with a single int inside.
payload = asn1.Sequence()
payload.append(0xf)

# Ta da, here is the control
control = ( oid, criticality, payload.encode() )

# Now do the operation
dn = "cn=foobar,cn=users,dc=activedirectory,dc=com"
modifications = [(ldap.MOD_REPLACE, "ntSecurityDescriptor", "blah")]
conn.modify_ext_s(dn, modifications, serverctrls=[control])
######################

Like I said, it works great!

The C code I've written looks very similar to the existing code in
LDAPObject.c that handles LDAPMod objects (I used the LDAPMod code as a
template for my stuff). If you guys want, I can start throwing patches
your way. 

Any thoughts on all of this?

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Re: Implementation of LDAPControls

[Deepak G. <de...@ar...>]

Hi, guys! 

Has there been any progress on implementing LDAPControl objects in
python-ldap? There were some messages posted on the list in late
December/early January about this, but I haven't heard much since then.

The project I'm working on is at a point where this feature is a
necessity, so if implementation of this feature is at a standstill I'm
willing to get the ball rolling again.

Is there any work that's already begun? I didn't see anything in the CVS
repository. If anyone has any existing code, I'd much appreciate it if I
could take a look at it.

Cheers!
Deepak

ps - earlier, my colleague posted on the OpenLDAP mailing list about
what we're trying to accomplish:
http://www.openldap.org/lists/openldap-software/200502/msg00392.html

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Native python LDAP?

[Rich M. <ri...@ne...>]

Has anyone ever thought about doing a native (not based on ldap sdk 
binaries) python LDAP client?  Something like Net::LDAP (which is a very 
nice object model, even though it's perl).  It depends on several 
modules being available.  For example, is there a python ASN.1 parser?  
Most everything else is already available in python - sockets, ssl, etc.

Re: Python & LDAP & Oracle

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

Michael Strecker wrote:
>
> is Python compatible with Oracle?

There are surely DB-API modules for Python to access Oracle databases. 
But this is off-topic on this list.

Since we're here on python-ldap-dev you maybe ask about access Oracle 
Internet Directory which is the LDAP server product implemented by 
Oracle. Is this what you're after?

> I would read out the users on openLDAP Servers, copy them and insert the
> users into the Oracle Database.

Should be no problem to access OpenLDAP with python-ldap.

Ciao, Michael.

Re: Python & LDAP & Oracle

[Gavin D. <gdo...@an...>]

Yes, we have many python applications talking to Oracle 8.1 and 9

Michael Strecker wrote:
> Hello,
> is Python compatible with Oracle?
> I would read out the users on openLDAP Servers, copy them and insert the
> users into the Oracle Database.
> 
> Dear Michael
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

-- 
Gavin Doughtie
DreamWorks SKG
(818) 695-3821

Re: Python & LDAP & Oracle

[Bjorn O. G. <bg...@st...>]

Michael Strecker:
> Hello,
> is Python compatible with Oracle?
> I would read out the users on openLDAP Servers, copy them and insert th=
e
> users into the Oracle Database.

A bit OT for this list perhaps, but - anyways...
http://www.python.org/topics/database/modules.html has a list of which
databases are supported in Python and which module you can use.=20

--=20
Regards
=20
Bj=F8rn Ove Gr=F8tan

Python & LDAP & Oracle

[Michael S. <Mic...@ok...>]

Hello,
is Python compatible with Oracle?
I would read out the users on openLDAP Servers, copy them and insert the
users into the Oracle Database.

Dear Michael

Re: Adding objectClass to existing dn

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

Mark Roach wrote:
> 
>>{'info': "attribute 'cn' not allowed", 'desc': 'Object class violation'}
>>{'info': 'modify/add: objectClass: value #0 already exists', 'desc':
>>'Type or value exists'}
 >
> mlist = ldap.modlist.modifyModlist(attrs, newattrs)

ldap.modlist.modifyModlist() is a function which calculates the delta of 
an old entry and what a new entry should like. The result is a list to 
be passed to LDAPObject.modify() and .modify_s(). Using this function 
would certainly help with the problem the original poster has since it 
would supress adding the same attribute value twice.

But use this function with care! There surely are situations where the 
dumb case-sensitive string match for generating the delta is not 
sufficient. Therefore I don't recommend it unless you're really know 
what you're doing. Better you have full control of what you're doing.

Ciao, Michael.

Re: Adding objectClass to existing dn

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

Robert Cooke wrote:
> 
> I've been trying to add an objectClass to an existing dn.
> Now I get messages like :
> 
> {'info': "attribute 'cn' not allowed", 'desc': 'Object class violation'}
> {'info': 'modify/add: objectClass: value #0 already exists', 'desc':
> 'Type or value exists'}
> 
> In my modlist are all the values nessecary I though. It feels like
> the chicken and the egg problem.

There's no chicken and egg problem here. The error description says that 
the attribute value for attribute 'cn' is already there. To be clear: 
Not only the attribute 'cn' itself is present. The very same attribute 
value is already stored in attribute 'cn' of this entry. This violates 
the X.500 data model. Just leave the 'cn' out of your modify list.

> To insert an objectClass you need the must attributes and to get the
> attributes you need the new objectClass.

This is another problem and can be easily solved. Add and modify 
requests are atomic.

Ciao, Michael.

Re: Adding objectClass to existing dn

[Mark R. <mr...@ok...>]

On Tue, 2005-02-01 at 17:11 +0100, Robert Cooke wrote:
> Hi,
> 
> Thanks mark for your quick response but I'm sorry to tell the problem is
> not yet solved.

Hmm... perhaps the problem is adding new attributes as a tuple. Here is
a snippet from actual working code:

    sambaAttributes = deepcopy(newAttributes)
    sambaAttributes['objectClass'].append('sambaSAMAccount')
    sambaSID = domainSID + "-" + str(int(uidNumber) * 2 + 1000)
    sambaAttributes['sambaSID'] = sambaSID
    sambaAttributes['sambaAcctFlags'] = '[UX]'
    modlist = ldap.modlist.modifyModlist(newAttributes, sambaAttributes)
    self._conn.modify_s(userdn, modlist)

As you can see, the new attributes are just strings. That really
*shouldn't* make a difference though. ... oh wait. I think I see a
problem here:

> list(newattrs['objectClass']).append('ipHost')

This is creating a new copy of newattrs['objectClass'] and appending the
new objectClass to that list. You don't need the list() call at all, in
fact you need to not use list().

-Mark

Re: Adding objectClass to existing dn

[Mark R. <mr...@ok...>]

On Tue, 2005-02-01 at 14:37 +0100, Robert Cooke wrote:
> Hi,
> 
> I've been trying to add an objectClass to an existing dn.
> Now I get messages like :

> {'info': "attribute 'cn' not allowed", 'desc': 'Object class violation'}
> {'info': 'modify/add: objectClass: value #0 already exists', 'desc':
> 'Type or value exists'}

I'm not sure how you're building your modlist, but you might want to
using ldap.modlist: (example off the top of my head, may have typos)

import ldap
import ldap.modlist
import copy

l = ldap.initialize('ldap://server')
l.bind_s('...', 'pass')
dn, attrs = l.search_s(dn, ldap.SCOPE_BASE)

newattrs = copy.deepcopy(attrs)
newattrs['objectClass'].append('newobjectclass')
newattrs['cn'] = ('cn_value',)

mlist = ldap.modlist.modifyModlist(attrs, newattrs)
l.modify_s(dn, mlist)


-Mark

Adding objectClass to existing dn

[Robert C. <r....@ho...>]

Hi,

I've been trying to add an objectClass to an existing dn.
Now I get messages like :



{'info': "attribute 'cn' not allowed", 'desc': 'Object class violation'}
{'info': 'modify/add: objectClass: value #0 already exists', 'desc':
'Type or value exists'}

In my modlist are all the values nessecary I though. It feels like
the chicken and the egg problem.

To insert an objectClass you need the must attributes and to get the
attributes you need the new objectClass.

Please tell me what I'm missing here.

Thanks robert

Re: LDAP sorting routines

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

Marc Balmer wrote:
> 
> OpenLDAP specifies a set of functions to sort a result set:
> 
> ldap_sort_entries(),  ldap_sort_values(), and ldap_sort_strcasecmp()

These are helper functions used for sorting at the client side. IMO only 
useful for client applications implemented in C.

> I did not find these functions in the documentation of python-ldap.  Is 
> there a reason they are not available in python?  Could they be added?

It does not make sense to wrap these functions since client-side sorting 
of complete search result sets can be easily achieved by a couple of 
lines of Python code.

Support for server-side sorting together is a different story.

Ciao, Michael.