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: vanmeeu...@kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com
pgp: 9342 BF08
------------------------------------------------------------------------------
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
Python-LDAP-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev