Replication of local entries with translucent overlay

[Igor <nightonearth@gmail.com>]

Hello,

I have an openLDAP proxy server which uses the translucent overlay to
supplement Active Directory records with additional attributes. I
wanted to set up replication for my translucent entries (specifically,
push-based provider/consumer scheme, refreshAndPersist mode).

Since slapo-translucent turns off maintenance of the entryCSN and
entryUUID attributes (turns off the lastmod option in the
translucent_db_init function), it cannot be used with slapo-syncprov
(which requires entryCSN and entryUUID attributes).

I understand that to make these two overlays work together in all
scenarios may not be trivial. However, for my specific scenario, it
seems to be enough to just comment out that line which turns off
lastmod:

==============
---

 servers/slapd/overlays/translucent.c |    2 +-

 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/servers/slapd/overlays/translucent.c
b/servers/slapd/overlays/translucent.c

index 48cca49..45b45a0 100644

--- a/servers/slapd/overlays/translucent.c

+++ b/servers/slapd/overlays/translucent.c

@@ -1282,7 +1282,7 @@ static int translucent_db_init(BackendDB *be,
ConfigReply *cr) {

  return 1;

  }

  SLAP_DBFLAGS(be) |= SLAP_DBFLAG_NO_SCHEMA_CHECK;

- SLAP_DBFLAGS(be) |= SLAP_DBFLAG_NOLASTMOD;

+// SLAP_DBFLAGS(be) |= SLAP_DBFLAG_NOLASTMOD;



  return 0;

 }

-- 

1.7.1

==============

Everything replicates correctly after that.

I don't expect anyone to scour the openLDAP code to come up with an
exhaustive list of potential bugs that may arise because of this. I
assume the risks that come with such a solution.

Having said that, can anyone think of any issues with commenting that
line in translucent_db_init, and setting entryCSN, entryUUID,
contextCSN attributes to be searched in local glue records only (via
olcTranslucentLocal)?


Thanks,
-Igor