Howard Chu wrote:
The basic idea is this - on the provider, set up an accesslog DB for
logging changes, in addition to the main database. Set up the syncprov
overlay on the logging DB, not the main DB. Thus syncrepl will be
propagating full entries as usual, but the content of those entries
will actually be deltas, not actual entries... A sample config looks
like this:
database bdb
suffix cn=accesslog
directory db.1.b
rootdn cn=accesslog
rootpw secret
...
overlay syncprov
syncprov-nopresent TRUE
database bdb
suffix dc=example,dc=com
directory db.1.a
...
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE # by default, accesslog logs failed requests too. we
just want successful writes.
On the consumer, the configuration looks like:
database bdb
suffix dc=example,dc=com
syncrepl rid=1
provider=ldap://localhost:9011/
binddn="cn=accesslog"
bindmethod=simple
credentials=secret
searchbase="cn=accesslog"
scope=sub
type=refreshOnly
interval=00:00:00:10
syncdata=accesslog
This separation of log info from syncprovider is rather troublesome;
it won't fallback properly to a full refresh if the consumer is too
far out of date wrt the log database.
A better implementation would be to leave the syncprovider overlay on
top of the main database, and add a config keyword telling it where it
can find a log database to use. Then both syncprov and accesslog
overlays would sit on the main database. And ideally, there would be a
new flag in the syncrepl control requesting that changes be propagated
in commit order, as deltas instead of full entries.
I guess there are two directions to go here - first, the accesslog DB
could be used by the sync provider as a non-volatile session log. That
would allow it to work efficiently across server restarts.
Next, I'm considering a secondary consumer config specifically for the
delta log. E.g.
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
logbinddn="cn=accesslog"
logbindmethod=simple
logcredentials=secret
The consumer can access the log in RefreshOnly or Persist mode; if the
Provider signals that the consumer is out of date then the consumer will
do a full refresh against the actual DB, and then return to using the
log db.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
