python-ldap-dev — discussion among developers

Re: Python LDAP

[Godefroid C. <go...@bu...>]

Le 07/04/11 21:04, Chris Dukes a écrit :
> On Thu, Apr 07, 2011 at 07:59:55PM +0200, Godefroid Chapelle wrote:
>> Hi,
>>
>> I am trying to access a Lotus Notes LDAP server.
>>
>> I got the information from the Notes admin that I should use a Base DN
>> that consists of a single space. That feels very strange to me.
>
> The problem you are having is not specific to python-ldap, nor Lotus LDAP.
>
> Be the DN '' (an empty string) or ' ' (A space) or '    ' (Lots of spaces)
> it's the DN of the root of the tree on that LDAP server.
>
>>
>> Has one of the subscribers already succeeded to connect to Lotus Notes ?
>
>
> I suggest attempting the following against the Lotus Domino LDAP.
> ldapsearch -h LDAPServer -x -b '' -s base 'objectclass=*'
> This will return the LDAP entry for the root of the tree, which may or may not
> contain anything interesting.
>
> Now look one level further down.
> ldapsearch -h LDAPServer -x -b '' -s one 'objectclass=*'
> Which will probably show all of groups.
>
>>
>> Thanks
>> --
>> Godefroid Chapelle (aka __gotcha) http://bubblenet.be

The hints you gave about the use of ldapsearch enabled me to understand 
better the setup of the Notes server I was trying to search.

I have now a working setup : thanks for this !

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

Python LDAP

[Godefroid C. <go...@bu...>]

Hi,

I am trying to access a Lotus Notes LDAP server.

I got the information from the Notes admin that I should use a Base DN 
that consists of a single space. That feels very strange to me.

Has one of the subscribers already succeeded to connect to Lotus Notes ?

Thanks
-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

New mailing list for python-ldap (was: Mailing list moves now!)

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

HI!

Maybe my last e-mail wasn't clear enough. So I'll try again:
The old SourceForge mailing list python-ldap-dev will not be used anymore!

I'd be happy to see you all on the new mailing list for
http://python-ldap.org under the umbrella of python.org.

List and subscriber info is here:
http://mail.python.org/mailman/listinfo/python-ldap

All announcements, discussion and support related to python-ldap
can be posted there.

Especially there are important things to discuss for
upcoming python-ldap 2.4...so please switch to the new list.

Ciao, Michael.


Michael Ströder wrote:
> HI!
> 
> This is the last message to the old SF mailing list. Do not reply here!
> The old mailing list will be shut down now!
> 
> I'd be happy to see you all on our new mailing list:
> 
> http://mail.python.org/mailman/listinfo/python-ldap
> 
> All announcements, discussion and support will be posted there.
> 
> Ciao, Michael.

Mailing list moves now!

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

HI!

This is the last message to the old SF mailing list. Do not reply here!
The old mailing list will be shut down now!

I'd be happy to see you all on our new mailing list:

http://mail.python.org/mailman/listinfo/python-ldap

All announcements, discussion and support will be posted there.

Ciao, Michael.

Re: Load Balance and Redundant LDAP config

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

Bob Brandt wrote:
> I apologize if this is not the right place to ask this question...

You're welcome to discuss this here.

> I am looking to modify my LDAP scripts to be both Redundant and Load
> Balancing!

Although both things are mixed all the time these are two different goals.

> Right now, I have a script that has a list of LDAP servers and uses the
> first one that responses, but the problem is all later requests, use
> that single LDAP server. If that server were to fail, the script fails.

A simple solution would be to try to connect to a random LDAP server within
the list and catch ldap.SERVER_DOWN to reconnect. You could have a look at
ldap.ldapobject.ReconnectLDAPObject.reconnect() to get an idea how to do that
automatically when serving sychronous calls.

Feel free to provide an extension for ReconnectLDAPObject which deals with
more than one server.

If you're using the async methods your application has to deal with it.

Ciao, Michael.

Re: ldap.controls in python-ldap 2.4

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

Michael Ströder wrote:
> Since I'm working more with LDAPv3 controls now I've cleaned up sub-module
> ldap.controls. Still work in progress...

Now I've checked in the modifications and updated Demo/page_control.py to make
use of the slightly new API. Also some related constants' names are now
aligned with OpenLDAP's ldap.h. Please check out HEAD and comment.

Ciao, Michael.

Load Balance and Redundant LDAP config

[Bob B. <bo...@br...>]

I apologize if this is not the right place to ask this question...

I am looking to modify my LDAP scripts to be both Redundant and Load
Balancing!

For example I have a RADIUS server which runs a python script to retrieve
user's attributes from LDAP once they are authenticated.

Right now, I have a script that has a list of LDAP servers and uses the
first one that responses, but the problem is all later requests, use that
single LDAP server. If that server were to fail, the script fails.

I guess my main question is: Is there a preferred method of supplying
Redundancy and/or Load Balancing? (I don't really want to reinvent the
wheel)

However, if I must reinvent the wheel, I am thinking along the lines of
opening multiple connections the each server and programmically switching
between thed different connections as they come up.

Does this sound right? Any suggestions?

Thanks
Bob



-- 
What's the point of having a rapier wit if I can't use it to stab people? -
Jeph Jacques

ldap.controls in python-ldap 2.4

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

HI!

Since I'm working more with LDAPv3 controls now I've cleaned up sub-module
ldap.controls. Still work in progress...

Unfortunately it would be too cumbersome to maintain backward compability. So
python-ldap 2.4 will very likely break applications working with LDAPv3
controls. My application code will also be heavily affected.

I can understand that this will make many people unhappy. But IMO it's the
only way to clean up this mess and come up with a much more convenient API for
dealing with controls. Better to do it now than later.

Ciao, Michael.

Re: python-ldap as replication client

[Eric B. <br...@br...>]

On 03/23/2011 01:11 AM, Michael Ströder wrote:
> Eric Brunson wrote:
>> The new code works great, thanks so much for the new features.
>>
>> I do have one issue, and maybe I'm just not looking in the correct
>> place.  The Sync Info Message returns a syncInfoValue which is a BER
>> encoded ASN.1 CHOICE structure:
>>
>>      syncInfoValue ::= CHOICE {
>>                newcookie      [0] syncCookie,
>>                refreshDelete  [1] SEQUENCE {
>>                    cookie         syncCookie OPTIONAL,
>>                    refreshDone    BOOLEAN DEFAULT TRUE
>>                },
>>                refreshPresent [2] SEQUENCE {
>>                    cookie         syncCookie OPTIONAL,
>>                    refreshDone    BOOLEAN DEFAULT TRUE
>>                },
>>                syncIdSet      [3] SEQUENCE {
>>                    cookie         syncCookie OPTIONAL,
>>                    refreshDeletes BOOLEAN DEFAULT FALSE,
>>                    syncUUIDs      SET OF syncUUID
>>                }
>>            }
>>
>> The data is returned and I've been able to successfully decode it with
>> the PyASN1 BER codec, but I can't find any indication of the choice
>> index being returned in the value.   I don't know that the refreshDelete
>> and the refreshPresent are distinguishable from each other without
>> additional information, but I see that the value being returned from
>> result4() is simply what ldap_parse_intermediate() returns, without any
>> indication of the choice index.  Looking at the raw BER encoded packet
>> in wireshark, it would seem that the two bytes before the data being
>> returned have the index embedded in the second byte.
>>
>> I'm sure this must simply be something I'm overlooking.  Any help?
> Could you share a short script demonstrating this?

I've done some more reading and I think I'm mistaken about there being 
some sort of index indicating the type of choice that was encoded.  The 
documentation for the PyASN library implies that the decoder has to 
infer the choice based on the structure of the data, which seems odd.

Thanks for the reply, I'll get back to you when I figure something out.

e.

Re: python-ldap as replication client

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

Eric Brunson wrote:
> The new code works great, thanks so much for the new features.
> 
> I do have one issue, and maybe I'm just not looking in the correct
> place.  The Sync Info Message returns a syncInfoValue which is a BER
> encoded ASN.1 CHOICE structure:
> 
>     syncInfoValue ::= CHOICE {
>               newcookie      [0] syncCookie,
>               refreshDelete  [1] SEQUENCE {
>                   cookie         syncCookie OPTIONAL,
>                   refreshDone    BOOLEAN DEFAULT TRUE
>               },
>               refreshPresent [2] SEQUENCE {
>                   cookie         syncCookie OPTIONAL,
>                   refreshDone    BOOLEAN DEFAULT TRUE
>               },
>               syncIdSet      [3] SEQUENCE {
>                   cookie         syncCookie OPTIONAL,
>                   refreshDeletes BOOLEAN DEFAULT FALSE,
>                   syncUUIDs      SET OF syncUUID
>               }
>           }
> 
> The data is returned and I've been able to successfully decode it with
> the PyASN1 BER codec, but I can't find any indication of the choice
> index being returned in the value.   I don't know that the refreshDelete
> and the refreshPresent are distinguishable from each other without
> additional information, but I see that the value being returned from
> result4() is simply what ldap_parse_intermediate() returns, without any
> indication of the choice index.  Looking at the raw BER encoded packet
> in wireshark, it would seem that the two bytes before the data being
> returned have the index embedded in the second byte.
> 
> I'm sure this must simply be something I'm overlooking.  Any help?

Could you share a short script demonstrating this?

Ciao, Michael.

Re: python-ldap as replication client

[Eric B. <br...@br...>]

On 03/11/2011 11:24 AM, Michael Ströder wrote:
> Eric Brunson wrote:
>> On 03/11/2011 11:00 AM, Michael Ströder wrote:
>>> Eric Brunson wrote:
>>>> On 03/11/2011 05:40 AM, Michael Ströder wrote:
>>>>> No matter which sync protocol you implement it's very likely that
>>>>> you need
>>>>> python-LDAP from CVS HEAD (will be python 2.4) since this version
>>>>> contains
>>>>> code to extract response controls from intermediate responses.
>>>> I'm currently working on a project that requires me to do a syncrepl
>>>> from python and after much, much reading I'm afraid that the python-ldap
>>>> library does not implement 4533 correctly.
>>>>
>>>> Sync cookies are only retrieved by python-ldap if they are returned in a
>>>> server control, however this is only the case in an
>>>> LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The
>>>> protocol passes both deletes and presence records in
>>>> LDAP_RES_INTERMEDIATE packets, which don't get returned to the python
>>>> caller as they don't have LDAP entries in them, and cookies are also
>>>> returned in these intermediate result packets, but not in a server
>>>> control, so those are missed.
>>> The patches in CVS HEAD were contributed by Rich exactly to make syncrepl
>>> possible with python-ldap. If you think the current implementation in
>>> CVS HEAD
>>> still has deficiencies regarding controls in intermediate responses I
>>> happily
>>> will review a patch. ;-)
>> Wow, Michael, that is super awesome news.  I'll check the CVS head, try
>> it out and get back to you.
> Make sure to set the right arguments for LDAPObject.result4().
>
> Ciao, Michael.

Michael and all,

The new code works great, thanks so much for the new features.

I do have one issue, and maybe I'm just not looking in the correct 
place.  The Sync Info Message returns a syncInfoValue which is a BER 
encoded ASN.1 CHOICE structure:

    syncInfoValue ::= CHOICE {
               newcookie      [0] syncCookie,
               refreshDelete  [1] SEQUENCE {
                   cookie         syncCookie OPTIONAL,
                   refreshDone    BOOLEAN DEFAULT TRUE
               },
               refreshPresent [2] SEQUENCE {
                   cookie         syncCookie OPTIONAL,
                   refreshDone    BOOLEAN DEFAULT TRUE
               },
               syncIdSet      [3] SEQUENCE {
                   cookie         syncCookie OPTIONAL,
                   refreshDeletes BOOLEAN DEFAULT FALSE,
                   syncUUIDs      SET OF syncUUID
               }
           }

The data is returned and I've been able to successfully decode it with 
the PyASN1 BER codec, but I can't find any indication of the choice 
index being returned in the value.   I don't know that the refreshDelete 
and the refreshPresent are distinguishable from each other without 
additional information, but I see that the value being returned from 
result4() is simply what ldap_parse_intermediate() returns, without any 
indication of the choice index.  Looking at the raw BER encoded packet 
in wireshark, it would seem that the two bytes before the data being 
returned have the index embedded in the second byte.

I'm sure this must simply be something I'm overlooking.  Any help?

Thanks,
e.

Roadmap for python-ldap 2.4

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

HI!

I'd like to get final release 2.4.0 out begin of May and I'm currently
thinking of what should still to be added. Focus is still Python 2.x.

There are some considerations which I'm not sure about yet:

1. Unicode support for DNs, filter strings, etc. but not entry attributes!
(Everybody asking for the latter should check the mailing list archive first.)

2. Split LDAPControl into separate classes LDAPRequestControl and
LDAPResponseControl.

3. OID-based registry especially for response controls so they can be decoded
on-the-fly when received before being returned to the calling application.

4. Use module logging for debug trace messages. I've already added the *very*
simple sub-module ldap.logger.

5. Use pyasn1 to implement more controls and extended operations.

Input welcome.

Ciao, Michael.

Re: Modifying multiple dns with a single function call

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

Rahul Amaram wrote:
> I am looking for something like this.
> 
> dn: cn=User1,dc=example,dc=com
> changetype: modify
> replace: mail
> mail: us...@ex...
> 
> dn: cn=User2,dc=example,dc=com
> changetype: modify
> replace: mail
> mail: us...@ex...
> 
> dn: cn=User3,dc=example,dc=com
> changetype: modify
> replace: mail
> mail: us...@ex...
> 
> I want to make all the above changes with a single function call. Is 
> this possible

No.

> or should I call modify_s once for each dn entry?

Yes.

Ciao, Michael.

Re: Modifying multiple dns with a single function call

[Rahul A. <ra...@sy...>]

I am looking for something like this.

dn: cn=User1,dc=example,dc=com
changetype: modify
replace: mail
mail: us...@ex...

dn: cn=User2,dc=example,dc=com
changetype: modify
replace: mail
mail: us...@ex...

dn: cn=User3,dc=example,dc=com
changetype: modify
replace: mail
mail: us...@ex...

I want to make all the above changes with a single function call. Is 
this possible or should I call modify_s once for each dn entry?

Regards,
Rahul.

On Friday 18 March 2011 03:25 PM, Michael Ströder wrote:
> Rahul Amaram wrote:
>> I would like to know if it possible to modify multiple dns at once i.e.
>> via a single modify_s request.
>
> Yes, if you mean (multiple) DN-valued attribute values in a single entry.
>
> No, if you mean the DNs of multiple entries.
>
>> I might need to update about 10,000 entries and I was wondering about
>> the best way to do this.
>
> One by one...
>
> This can get tricky if you have a hierarchy of DNs and you have to rename
> superior entries.
>
> Ciao, Michael.

Re: Modifying multiple dns with a single function call

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

Rahul Amaram wrote:
> I would like to know if it possible to modify multiple dns at once i.e. 
> via a single modify_s request.

Yes, if you mean (multiple) DN-valued attribute values in a single entry.

No, if you mean the DNs of multiple entries.

> I might need to update about 10,000 entries and I was wondering about 
> the best way to do this.

One by one...

This can get tricky if you have a hierarchy of DNs and you have to rename
superior entries.

Ciao, Michael.

Modifying multiple dns with a single function call

[Rahul A. <ra...@sy...>]

Hi,
I would like to know if it possible to modify multiple dns at once i.e. 
via a single modify_s request.

I might need to update about 10,000 entries and I was wondering about 
the best way to do this.

Any suggestions/feedback on how best this could be achieved using 
python-ldap would be very useful.

Thanks,
Rahul.

Re: python-ldap as replication client

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

Eric Brunson wrote:
> On 03/11/2011 11:00 AM, Michael Ströder wrote:
>> Eric Brunson wrote:
>>> On 03/11/2011 05:40 AM, Michael Ströder wrote:
>>>> No matter which sync protocol you implement it's very likely that
>>>> you need
>>>> python-LDAP from CVS HEAD (will be python 2.4) since this version
>>>> contains
>>>> code to extract response controls from intermediate responses.
>>> I'm currently working on a project that requires me to do a syncrepl
>>> from python and after much, much reading I'm afraid that the python-ldap
>>> library does not implement 4533 correctly.
>>>
>>> Sync cookies are only retrieved by python-ldap if they are returned in a
>>> server control, however this is only the case in an
>>> LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The
>>> protocol passes both deletes and presence records in
>>> LDAP_RES_INTERMEDIATE packets, which don't get returned to the python
>>> caller as they don't have LDAP entries in them, and cookies are also
>>> returned in these intermediate result packets, but not in a server
>>> control, so those are missed.
>> The patches in CVS HEAD were contributed by Rich exactly to make syncrepl
>> possible with python-ldap. If you think the current implementation in
>> CVS HEAD
>> still has deficiencies regarding controls in intermediate responses I
>> happily
>> will review a patch. ;-)
> 
> Wow, Michael, that is super awesome news.  I'll check the CVS head, try
> it out and get back to you.

Make sure to set the right arguments for LDAPObject.result4().

Ciao, Michael.

Re: python-ldap as replication client

[Eric B. <br...@br...>]

On 03/11/2011 11:00 AM, Michael Ströder wrote:
> Eric Brunson wrote:
>> On 03/11/2011 05:40 AM, Michael Ströder wrote:
>>> No matter which sync protocol you implement it's very likely that you need
>>> python-LDAP from CVS HEAD (will be python 2.4) since this version contains
>>> code to extract response controls from intermediate responses.
>> I'm currently working on a project that requires me to do a syncrepl
>> from python and after much, much reading I'm afraid that the python-ldap
>> library does not implement 4533 correctly.
>>
>> Sync cookies are only retrieved by python-ldap if they are returned in a
>> server control, however this is only the case in an
>> LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The
>> protocol passes both deletes and presence records in
>> LDAP_RES_INTERMEDIATE packets, which don't get returned to the python
>> caller as they don't have LDAP entries in them, and cookies are also
>> returned in these intermediate result packets, but not in a server
>> control, so those are missed.
> The patches in CVS HEAD were contributed by Rich exactly to make syncrepl
> possible with python-ldap. If you think the current implementation in CVS HEAD
> still has deficiencies regarding controls in intermediate responses I happily
> will review a patch. ;-)

Wow, Michael, that is super awesome news.  I'll check the CVS head, try 
it out and get back to you.

Sincerely,
e.

Re: python-ldap as replication client

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

Eric Brunson wrote:
> On 03/11/2011 05:40 AM, Michael Ströder wrote:
>> No matter which sync protocol you implement it's very likely that you need
>> python-LDAP from CVS HEAD (will be python 2.4) since this version contains
>> code to extract response controls from intermediate responses.
> 
> I'm currently working on a project that requires me to do a syncrepl 
> from python and after much, much reading I'm afraid that the python-ldap 
> library does not implement 4533 correctly.
> 
> Sync cookies are only retrieved by python-ldap if they are returned in a 
> server control, however this is only the case in an 
> LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The 
> protocol passes both deletes and presence records in 
> LDAP_RES_INTERMEDIATE packets, which don't get returned to the python 
> caller as they don't have LDAP entries in them, and cookies are also 
> returned in these intermediate result packets, but not in a server 
> control, so those are missed.

The patches in CVS HEAD were contributed by Rich exactly to make syncrepl
possible with python-ldap. If you think the current implementation in CVS HEAD
still has deficiencies regarding controls in intermediate responses I happily
will review a patch. ;-)

Ciao, Michael.

Re: python-ldap as replication client

[Eric B. <br...@br...>]

On 03/11/2011 05:40 AM, Michael Ströder wrote:
> Jeroen van Meeuwen (Kolab Systems) wrote:
>> I'm looking to implement LDAP_CONTROL_SYNC(*) capabilities to
>> python-ldap's ldap.controls, and while I do have some experience in
>> several areas, admittedly compared to you I'm probably the most
>> under-qualified programmer to actually do it.
> You're always welcome to send demo code and get it commented here.
>
>> That said, I first wanted to ask whether something like python-ldap
>> becoming a replication client (through server controls) was feasible in
>> your opinion(s).
> No matter which sync protocol you implement it's very likely that you need
> python-LDAP from CVS HEAD (will be python 2.4) since this version contains
> code to extract response controls from intermediate responses. Beware that
> this may still be subject of API changes especially regarding ldap.controls
> and ldap.extop.
>
> Some additional ASN.1 work for encoding/decoding controls is needed too. I'm
> currently using pyasn1.sf.net for that which is outside python-ldap.
>
>> I think RFC 3928[1] is the corresponding standard.
>> Another standard was proposed in RFC 4533[2] but that one bounced in
>> favor of the former.
> Which sync protocol standard suits your needs depends on the LDAP server your
> application is talking to.
>
> If you use the OpenLDAP server the OpenLDAP developers strongly recommend
> syncrepl. There were already some people here implementing syncrepl (RFC 4533)
> based on python-ldap.

I'm currently working on a project that requires me to do a syncrepl 
from python and after much, much reading I'm afraid that the python-ldap 
library does not implement 4533 correctly.

Sync cookies are only retrieved by python-ldap if they are returned in a 
server control, however this is only the case in an 
LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The 
protocol passes both deletes and presence records in 
LDAP_RES_INTERMEDIATE packets, which don't get returned to the python 
caller as they don't have LDAP entries in them, and cookies are also 
returned in these intermediate result packets, but not in a server 
control, so those are missed.

To see the proper handling of the syncrepl protocol it's instructional 
to read through the do_syncrep2 found in the file 
servers/slapd/syncrepl.c of the openldap source.  I'm working on moving 
that code over to a new function in the python-ldap module, but I'm not 
sure whether my company is going to allow me to release the code back to 
the project.  If I do it, they probably will.  If we pay someone else to 
do it, possibly not.

In any case, a python-LDAP syncrepl client can be made to work, but if 
there are deletes during a period when the client is not connected I 
believe they will be lost during the catchup phase of the sync.

I'm certainly not an OpenLDAP nor a python-LDAP expert, so if I'm 
mistaken about anything I've said above, please feel free to set me 
straight.  I just thought it would be good to share the caveat as I 
understand it.

Sincerely,
e.

> Personally I'm currently using LDAP persistent search retrieving data from a
> Novell eDirectory server since this is the control this server supports.
>
> Other LDAP servers have other sync controls, e.g. MS AD implemented the
> proprietary DirSync control, etc.
>
> Ciao, Michael.
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: python-ldap as replication client

[Jeroen v. M. (K. Systems) <van...@ko...>]

Michael Ströder wrote:
> Jeroen van Meeuwen (Kolab Systems) wrote:
> > I'm looking to implement LDAP_CONTROL_SYNC(*) capabilities to
> > python-ldap's ldap.controls, and while I do have some experience in
> > several areas, admittedly compared to you I'm probably the most
> > under-qualified programmer to actually do it.
> 
> You're always welcome to send demo code and get it commented here.
> 

Thanks! I feel all warm and fuzzy and welcome ;-)

> > That said, I first wanted to ask whether something like python-ldap
> > becoming a replication client (through server controls) was feasible in
> > your opinion(s).
> 
> No matter which sync protocol you implement it's very likely that you need
> python-LDAP from CVS HEAD (will be python 2.4) since this version contains
> code to extract response controls from intermediate responses. Beware that
> this may still be subject of API changes especially regarding ldap.controls
> and ldap.extop.
> 

Sure, that is fair enough. I was planning on doing any work based on CVS HEAD 
anyways, as I always consider it easier to upgrade (too) late then it is to 
stick with a modified, unsupported version forever ;-)

> Some additional ASN.1 work for encoding/decoding controls is needed too.
> I'm currently using pyasn1.sf.net for that which is outside python-ldap.
> 
> > I think RFC 3928[1] is the corresponding standard.
> > Another standard was proposed in RFC 4533[2] but that one bounced in
> > favor of the former.
> 
> Which sync protocol standard suits your needs depends on the LDAP server
> your application is talking to.
> 
> If you use the OpenLDAP server the OpenLDAP developers strongly recommend
> syncrepl. There were already some people here implementing syncrepl (RFC
> 4533) based on python-ldap.
> 

I'd be very interested in this work. Do you have a reference, perhaps? I can 
find some coversations on the topic, but no code / show-case implementation.

That said, it's interesting people have implemented this based on RFC 4533; 
Would you agree or disagree implementing the superseeded may actually be a bad 
thing to do for python-ldap, or would you wish any such implementation to be 
compatible with 4533 as well, somehow?

> Personally I'm currently using LDAP persistent search retrieving data from
> a Novell eDirectory server since this is the control this server supports.
> 

I'm successfully using the paging search results control[1] (against python-
ldap version 2.3.10) against a (simulated) very large LDAP tree, after which I 
realized this type of iteration does in no way apply any changes to the tree 
as instantly as the daemon being a replication client.

> Other LDAP servers have other sync controls, e.g. MS AD implemented the
> proprietary DirSync control, etc.
> 

I'll stick to the Free and RFC compatible for now, if that's OK with you? ;-)

Kind regards,

Jeroen van Meeuwen

[1] http://git.kolab.org/pykolab/tree/pykolab/auth/ldap/__init__.py#n150

-- 
Senior Engineer, Kolab Systems AG

e: van...@ko...
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08

Re: python-ldap as replication client

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

Jeroen van Meeuwen (Kolab Systems) wrote:
> I'm looking to implement LDAP_CONTROL_SYNC(*) capabilities to
> python-ldap's ldap.controls, and while I do have some experience in
> several areas, admittedly compared to you I'm probably the most
> under-qualified programmer to actually do it.

You're always welcome to send demo code and get it commented here.

> That said, I first wanted to ask whether something like python-ldap
> becoming a replication client (through server controls) was feasible in
> your opinion(s).

No matter which sync protocol you implement it's very likely that you need
python-LDAP from CVS HEAD (will be python 2.4) since this version contains
code to extract response controls from intermediate responses. Beware that
this may still be subject of API changes especially regarding ldap.controls
and ldap.extop.

Some additional ASN.1 work for encoding/decoding controls is needed too. I'm
currently using pyasn1.sf.net for that which is outside python-ldap.

> I think RFC 3928[1] is the corresponding standard.
> Another standard was proposed in RFC 4533[2] but that one bounced in
> favor of the former.

Which sync protocol standard suits your needs depends on the LDAP server your
application is talking to.

If you use the OpenLDAP server the OpenLDAP developers strongly recommend
syncrepl. There were already some people here implementing syncrepl (RFC 4533)
based on python-ldap.

Personally I'm currently using LDAP persistent search retrieving data from a
Novell eDirectory server since this is the control this server supports.

Other LDAP servers have other sync controls, e.g. MS AD implemented the
proprietary DirSync control, etc.

Ciao, Michael.

python-ldap as replication client

[Jeroen v. M. (K. Systems) <van...@ko...>]

Hello dear list members,

Please allow me to thank you and shortly introduce myself as I'm new to the 
list; My name is Jeroen van Meeuwen, I'm Dutch and I live in the United 
Kingdom, where I work for a Swiss company in Free Software groupware 
solutions, Kolab Systems.

I'm looking to implement LDAP_CONTROL_SYNC(*) capabilities to python-ldap's 
ldap.controls, and while I do have some experience in several areas, 
admittedly compared to you I'm probably the most under-qualified programmer to 
actually do it.

That said, I first wanted to ask whether something like python-ldap becoming a 
replication client (through server controls) was feasible in your opinion(s). 
I think RFC 3928[1] is the corresponding standard. Another standard was 
proposed in RFC 4533[2] but that one bounced in favor of the former.

Thanks in advance,

Kind regards,

Jeroen van Meeuwen

[1] http://tools.ietf.org/html/rfc3928
[2] http://tools.ietf.org/html/rfc4533

-- 
Senior Engineer, Kolab Systems AG

e: van...@ko...
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08

Re: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a released

[Rich M. <ric...@gm...>]

On 03/07/2011 11:19 AM, Michael Ströder wrote:
> Rich Megginson wrote:
>> RHEL does not include pyasn1.  But it is extremely useful for
>> extops/controls - doing BER codec by hand is not fun.
> Yupp!
>
>>   A mid-way
>> approach would be to expose the liblber ber_scanf/ber_printf and support
>> functions in python.
> Also an idea we already had. But I'm not a C programmer. So I'll stay away
> from that myself.
>
> But I will happily add a nice Python layer on top of your code. ;-}
> Make the C wrapper code as lean as possible.
The biggest problem I see is how to pass in arguments to the varadic 
functions ber_scanf and ber_printf from python without completely 
rewriting those functions to accept an array of format specifiers and a 
corresponding array of values/pointers.  It may be easier to just bite 
the bullet and add pyasn1 . . .
>> If you do decide that it is necessary for python-ldap to use pyasn1, we
>> can work on getting it into RHEL.  The Fedora python-pyasn1 maintainer
>> is one of the guys on the freeipa team which uses python-ldap heavily.
> Noted.
>
> Ciao, Michael.

Re: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a released

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

Rich Megginson wrote:
> RHEL does not include pyasn1.  But it is extremely useful for 
> extops/controls - doing BER codec by hand is not fun.

Yupp!

>  A mid-way 
> approach would be to expose the liblber ber_scanf/ber_printf and support 
> functions in python.

Also an idea we already had. But I'm not a C programmer. So I'll stay away
from that myself.

But I will happily add a nice Python layer on top of your code. ;-}
Make the C wrapper code as lean as possible.

> If you do decide that it is necessary for python-ldap to use pyasn1, we 
> can work on getting it into RHEL.  The Fedora python-pyasn1 maintainer 
> is one of the guys on the freeipa team which uses python-ldap heavily.

Noted.

Ciao, Michael.