[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: push-mode syncrepl and structuralObjectClass

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. :)