Hi,
I'm setting up push-mode replication using syncrepl and back-ldap as per advice from searching the list archives. The proxy slapd is correctly binding to the slave slapd, and I can see the replication begin to occur, but all the ADD operations are failing with the following result:
tag=105 err=19 text=structuralObjectClass: no user modification allowed
I've googled around a bit and searched the mailing list archives, but i've not found anything more relevant than this post:
http://www.openldap.org/lists/openldap-software/200706/msg00296.html
My current proxy and slave configurations are below.
Any advice on what I'm doing wrongly or what I need to do to avoid this problem would be greatly appreciated.
Many Thanks, Alex
======================================================================== proxy:
database ldap suffix "dc=transitives,dc=com" rootdn "cn=jabber,dc=transitives,dc=com" rootpw "" uri ldap://jabber.transitives.com/ tls start idle-timeout 600 network-timeout 10 acl-bind bindmethod=simple binddn="cn=jabber,dc=transitives,dc=com" credentials=""
syncrepl rid=051 provider=ldap://ldap-master.transitives.com/ type=refreshAndPersist retry="10 6 60 9 300 +" searchbase="ou=users,dc=transitives,dc=com" scope=sub filter="(objectClass=inetOrgPerson)" schemachecking=on bindmethod=simple binddn="cn=syncjabber,ou=roles,ou=auth,dc=transitives,dc=com" starttls=critical credentials=""
======================================================================== slave:
backend bdb database bdb suffix "dc=transitives,dc=com" directory "/var/lib/ldap/db/transitives/" mode 0600
index objectClass,entryCSN,entryUUID pres,eq index cn,sn,uid,displayName pres,eq,sub index givenName,mail pres,eq,sub index default eq,sub
lastmod on rootdn "cn=jabber,dc=transitives,dc=com" rootpw ""
# ACL's;
access to dn.base="" by * read access to * by * read
Alex Bramley wrote:
Hi,
I'm setting up push-mode replication using syncrepl and back-ldap as per advice from searching the list archives. The proxy slapd is correctly binding to the slave slapd, and I can see the replication begin to occur, but all the ADD operations are failing with the following result:
tag=105 err=19 text=structuralObjectClass: no user modification allowed
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.
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 ---------------------------------------
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
Alex Bramley skrev, on 17-10-2007 17:21:
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
This should never happen unless a client of your consumer is trying to update the consumer's DB. Which it can't, since its server is a consumer (slave). Therefore you have to have a mechanism that tells the consumer where to go for updates, a referral mechanism. By configuring the consumer for "chaining" this can be done (my site does it), but it's not always immediately obvious from the docs how to get this working (took me a long time, anyhow, trying different alternatives, whereof one - and only one - finally worked). I'm totally dependent on chaining on one of my 3 consumers.
--Tonni
Tony Earnshaw wrote:
Alex Bramley skrev, on 17-10-2007 17:21:
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
This should never happen unless a client of your consumer is trying to update the consumer's DB. Which it can't, since its server is a consumer (slave). Therefore you have to have a mechanism that tells the consumer where to go for updates, a referral mechanism. By configuring the consumer for "chaining" this can be done (my site does it), but it's not always immediately obvious from the docs how to get this working (took me a long time, anyhow, trying different alternatives, whereof one - and only one - finally worked). I'm totally dependent on chaining on one of my 3 consumers.
I believe the replication proxy back-ldap database (for push-mode syncrepl) connects as a client to the consumer. It seems this triggers a requirement for an updateref, even when the proxy is binding as the updatedn to perform replication updates.
--alex
Alex Bramley skrev, on 17-10-2007 18:35:
[...]
I believe the replication proxy back-ldap database (for push-mode syncrepl) connects as a client to the consumer. It seems this triggers a requirement for an updateref, even when the proxy is binding as the updatedn to perform replication updates.
However, one would still need a chain directive in the last consumer, which I don't think I saw. It should then update the provider, not the "pivot" - unless the "pivot" were also configured to chain to the original provider.
Best,
--Tonni
Alex Bramley wrote:
Tony Earnshaw wrote:
Alex Bramley skrev, on 17-10-2007 17:21:
After I added the correct updatedn setting, I got the error:
tag=103 err=53 text=shadow context; no update referral
This should never happen unless a client of your consumer is trying to update the consumer's DB. Which it can't, since its server is a consumer (slave). Therefore you have to have a mechanism that tells the consumer where to go for updates, a referral mechanism. By configuring the consumer for "chaining" this can be done (my site does it), but it's not always immediately obvious from the docs how to get this working (took me a long time, anyhow, trying different alternatives, whereof one - and only one - finally worked). I'm totally dependent on chaining on one of my 3 consumers.
I believe the replication proxy back-ldap database (for push-mode syncrepl) connects as a client to the consumer. It seems this triggers a requirement for an updateref, even when the proxy is binding as the updatedn to perform replication updates.
No. If the Bind with updateDN was successful this error will never appear.
Howard Chu wrote:
No. If the Bind with updateDN was successful this error will never appear.
It certainly appears that binding with the updateDN was successful from the logs -- could it be because I am using the rootDN as the updateDN?
Tony Earnshaw wrote:
However, one would still need a chain directive in the last consumer, which I don't think I saw. It should then update the provider, not the "pivot" - unless the "pivot" were also configured to chain to the original provider.
But my consumer is supposed to be a read-only slave -- I don't want any updates coming from it, and anyway it won't be able to reach the master provider through our internal firewalls. I'm not even sure why I needed the updateref configuration directive, but it seemed to fix things. I'm going to mess with my configuration and see if I can narrow down the problems some more...
Incidentally, I should probably mention that this is debian etch's OpenLDAP 2.3.30 (but there is no possibility of changing this, unfortunately).
Nevertheless, this is getting away from my main issue, which is that of removing the posixAccount and shadowAccount objectClasses from the replicated user data (unless I am attempting to solve the wrong problem).
Cheers, --alex
By configuring the consumer for "chaining" this can be done (my site does it), but it's not always immediately obvious from the docs how to get this working (took me a long time, anyhow, trying different alternatives, whereof one - and only one - finally worked). I'm totally dependent on chaining on one of my 3 consumers.
--Tonni
I've got examples to add to the Admin Guide this week btw.
openldap-software@openldap.org
-
Alex Bramley -
Gavin Henry -
Howard Chu -
Pierangelo Masarati -
Tony Earnshaw