Most of my organization's data is kept in LDAP, along with groups and affiliations and titles and positions and everything else. We've got a simple single-master, multi-slave setup, built back in the OpenLDAP 2.0 days.
We also have a provisioning service, which essentially monitors LDAP, and as new people arrive, change position, or what have you, it runs off and provisions accounts, mailboxes, services and permissions as needed for the person, all automatically.
Currently, this monitoring - trying to keep it as "live" as possible - is done by essentially making the provisioning server an LDAP replicant, using slurpd. It works "well enough", though it has some problems.
But slurpd is going away, and I'm trying to kill it off in our structure. The provisioning server is one of the last holdouts.
So my question is this: Is it possible for me to write some code, using perl or C or whatever is needed, that will connect as a syncrepl consumer, and "refresh and persist"? Are there docs for how the synchronization protocol works? Is it just an odd LDAP query?
On 10/09/2009 20:23, Brandon Hume wrote:
Most of my organization's data is kept in LDAP, along with groups and affiliations and titles and positions and everything else. We've got a simple single-master, multi-slave setup, built back in the OpenLDAP 2.0 days.
We also have a provisioning service, which essentially monitors LDAP, and as new people arrive, change position, or what have you, it runs off and provisions accounts, mailboxes, services and permissions as needed for the person, all automatically.
Currently, this monitoring - trying to keep it as "live" as possible - is done by essentially making the provisioning server an LDAP replicant, using slurpd. It works "well enough", though it has some problems.
But slurpd is going away, and I'm trying to kill it off in our structure. The provisioning server is one of the last holdouts.
So my question is this: Is it possible for me to write some code, using perl or C or whatever is needed, that will connect as a syncrepl consumer, and "refresh and persist"? Are there docs for how the synchronization protocol works? Is it just an odd LDAP query?
Hi,
You should find this section of the admin guide enlightening: http://www.openldap.org/doc/admin24/replication.html
The syncrepl protocol is defined by RFC4533. Very basically, it is a plain LDAP search plus a specific control to obtain a persistent search, and communicate state change information.
If you choose this route, you can of course look at OpenLDAP's code in C (servers/slapd/syncrepl.c in the source tree). Also, the ApacheDS project is implementing a listener in Java, which you probably look at too.
If you do implement a syncrepl consumer, many of us would be most interested to hear your feedback, and/or checkout the code.
Hope this helps, Jonathan
Brandon Hume writes:
So my question is this: Is it possible for me to write some code, using perl or C or whatever is needed, that will connect as a syncrepl consumer, and "refresh and persist"? Are there docs for how the synchronization protocol works? Is it just an odd LDAP query?
RFC 4533 describes the sync protocol. You might also have a look at the auditlog and accesslog overlays for alternate solutions to your probelm.
Hallvard B Furuseth wrote:
Brandon Hume writes:
So my question is this: Is it possible for me to write some code, using perl or C or whatever is needed, that will connect as a syncrepl consumer, and "refresh and persist"? Are there docs for how the synchronization protocol works? Is it just an odd LDAP query?
RFC 4533 describes the sync protocol. You might also have a look at the auditlog and accesslog overlays for alternate solutions to your probelm.
Following on to Hallvard's comment, OpenLDAP's libldap provides primitives to implement consumer-side syncrepl (as per RFC4533, no support for OpenLDAP extensions like delta-syncrepl and so). If you want to design your own consumer-side code based on RFC 4533, I'd recommend to start there. Of course, other solutions based on e.g. accesslog might be preferable if you prefer to limit the amount of required coding.
p.
openldap-software@openldap.org
-
Brandon Hume -
Hallvard B Furuseth -
Jonathan Clarke -
Pierangelo Masarati