<quote who="Pierangelo Masarati">
Quanah Gibson-Mount wrote:
I'm confused here. Is it a 2.4 change?
Must be, and seems to be a really odd requirement to me. Why does the consumer need to know about it? Why should it be required to load the accesslog module?
As i said, when the __producer__ is configured with the slapo-accesslog(5) overlay, gets the the auditContext operational attribute set in the database's context entry. This may be useful to be able to determine what log context is logging modifications to that context.
As soon as I added accesslog.la to my olcModuleLoad in cn=config, replication started again.
I also see in auditlog.ldif (currently testing slapo-auditlog for docs):
auditContext: cn=accesslog
liek you said above.
As a side effect, syncrepl replicates this attribute as well in the __consumer__. However, if this attribute is not defined in the __consumer__'s schema, odd things could happen.
i.e. replication stops and is broken ;-)
So, the only reason to have slapo-accesslog(5) built and loaded **BUT NOT INSTANTIATED** on the __consumer__ (doesn't sound such strikingly resource intensive a requirement) is to have this attribute defined in the schema.
Yup, proved this by just loading the module, not using is via "overlay accesslog" etc.
If this sounds so unreasonable, please suggest (and code) a better strategy. I'm open to everything (including zapping auditContext at all, unless anyone out there finds it useful and is actively using it).
Not unreasonable, just *totally* undocumented. It is, IMHO, a major missing part in the "Changes Since last version" section in the Admin Guide.
It's not even in *any* man pages in HEAD.
So Syncrepl won't work in 2.4 on any consumer, where the provider has accesslog enabled, i.e. delta-syncrepl.
Much appreciated for the feedback Ando. Time for me to get writing ;-)
Gavin.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it