Hi all. I'm trying to use slapd-sock as a way to do some ancillary processing, external to the openLDAP database, when entries are updated. Following a suggestion I got on this list some weeks back, I wrote a little Python program to listen on a Unix socket and do the actual processing; then I set up a consumer replica using the socket backend to pass updates along to the socket.
Here's my problem: Whenever I stop and then restart the replica server, it re-loads the whole tree from the master. I conjecture that this is because it doesn't have a persistent location to store the contextCSN on shutdown. Am I right so far?
I see from logging what comes across the socket that contextCSN gets *set* over the socket when the reload finishes. However, it doesn't appear that it is being *requested* (via a search operation) across the socket when the consumer replication engine starts up. Again, am I correct so far?
My socket listener could always squirrel away the contextCSN and then provide it to the replication engine in response to a search, if the search were being requested, but apparently it's not.
Is there any way for either my socket program or something internal to the openLDAP server to persist and then provide the contextCSN on server startup?
Or have I completely misunderstood how this all works?
Suggestions for alternative design approaches also welcomed, and many thanks as always to the local sages.