Re: push-mode syncrepl and structuralObjectClass

[Alex Bramley <alexeb@transitive.com>]

Pierangelo Masarati wrote:
> Alex Bramley wrote:
> > I'm setting up push-mode replication using syncrepl and back-ldap as per
> > advice from searching the list archives.
>
> You need an "updatedn" directive in the slave, and have the push
> back-ldap bind as that DN, so the slave understands that write is a
> replication, and allows operational attrs in.

This appears to have fixed the initial problem, thank you. However I 
have still been unsuccessful in getting the push-mode replication 
working correctly.

After I added the correct updatedn setting, I got the error:

tag=103 err=53 text=shadow context; no update referral

Some more reading of the list archives pointed me towards the need for 
an "updateref" line also, which I then added, pointing back to the 
master server. I'm not quite sure why this is needed, as this is 
intended to be a read-only directory in our DMZ which has no way of 
making a connection back to the master server.

The problem now is that I am trying to replicate only a small number of 
attributes from one sub-tree of our master directory. The entries in 
question have both inetOrgPerson and posix/shadowAccount objectClasses, 
but I only wish to replicate a subset of the inetOrgPerson attributes. 
However, the objectClass attribute of each entry to be replicated still 
includes posixAccount and shadowAccount, thus the additions are failing 
due to missing attributes. I have tried turning schemachecking off to no 
avail.

I have also looked into using slapo-rwm on the back-ldap proxy to remove 
the posix/shadowAccount objectClass attributes. The configuration 
directives below were intended to remove the posixAccount and 
inetOrgPerson objectClasses completely from the data written to the 
back-ldap database (from my reading of slapo-rwm(5)). Unfortunately, 
they seemed to result in the replication failing completely before the 
first ADD operation rather than producing any errors.

overlay rwm
rwm-map objectclass posixAccount
rwm-map objectclass shadowAccount

How can I get around these limitations?

I also have a related question about how I should be structuring this 
replication. The syncrepl configuration pasted in my original post uses 
a base of "ou=users,dc=transitives,dc=com" and a filter restricting the 
returned objects to those of the inetOrgPerson class. However, the 
suffix of the both the proxy back-ldap database and the slave back-bdb 
database is "dc=transitives,dc=com". How will the slave database get the 
entries at "dc=transitives,dc=com" and "ou=users,dc=transitives,dc=com" 
when initialised with a completely empty directory? Must these be added 
before the replication is attempted? Would it make more sense to 
replicate these entries with syncrepl also?

Thanks again for any help. :)
--alex