[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: asynchronous event notification?

[ 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

|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |