[Date Prev][Date Next]
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
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
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.
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. :)