python-ldap as replication client

[Jeroen van Meeuwen (Kolab Systems)]

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: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20110311/71a463ed/attachment.html>