[ Coming into this discussion rather late ] On Fri, Nov 04, 2005 at 11:23:24PM -0500, Phillip Rhodes wrote:
> Thanks for all the replies. I think I've identified two > possible ways to do what I'm trying to do: It looks like > I can use the LDAP Content Sync stuff to do it "client side" > or process the replication log (in essense, replace slurpd > with my own program) and parse the LDIF and generate / send > events based on that. > > I'm going to explore the LDAP Content Sync stuff further, > since I'd prefer a "client side" solution anyway, and the > other approach would break replication unless slapd can > write out multiple copies of the replication log. (If it > can't, that might be handy feature, fwiw). Slapd writes one copy of the log per slave server so that slurpd can cope with slaves that are down/slow etc. You could probably do what you want using slurpd to feed changes into another OpenLDAP server: instead of having that server update a disk database, you could use a backend that passed each change to some other process for action. Back-shell, Back-perl, and the recently proposed Back-sock come to mind here but you might even find that Back-SQL does what you need. In fact, as Slurpd simply issues LDAP modify operations against each slave server you have other options. Anything that can behave as an LDAP server could be used as the target (pseudo-slave). Thus you could use something like IBM's Directory Integrator to receive the update and run it through a whole assembly-line of functions and scripts. Remember that you probably will not get cleartext passwords using this mechanism so updating other password stores could be problematic. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
