From: Jeroen v. M. (K. Systems) <van...@ko...> - 2011-03-11 14:04:44
|
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 |