Hi,
I think I searched the internet and the documentation carefully, and still have problems:
Master and slave are both openSuSE 10.2, running openldap 2.3.27 (unaltered SuSE version).
I set up in the master: replogfile /var/lib/ldap/slurpd/slurpd.replog replica host=frifri_vpn:389 binddn="uid=rmanager,ou=intern,o=rori" bindmethod=simple credentials=xxx
and on the slave: [...beginning of access rules] access to * by dn.exact="uid=rmanager,ou=intern,o=rori" write by * break
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword,userPKCS12 by self write by * auth
access to attrs=shadowLastChange by self write by * read
access to * by * read [...] updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
and populated the slave's database with slapadd and restarted slapd on master and slave, + slurpd on master.
Everytime I make a change on the master I get in the rejection file the same error code: ERROR: Constraint violation: structuralObjectClass: no user modification allow ed replica: frifri_vpn:389 time: 1193340583.0 dn: cn=test test,ou=people,o=rori changetype: add sn: test givenName: test mail: x@y mozillaCustom2: FriFri cn: test test objectClass: top objectClass: inetOrgPerson objectClass: abookPerson objectClass: mozillaOrgPerson structuralObjectClass: mozillaOrgPerson entryUUID: 6208a648-177c-102c-9f5a-29bdb5d43dbc creatorsName: cn=Manager,o=rori createTimestamp: 20071025192943Z entryCSN: 20071025192943Z#000000#00#000000 modifiersName: cn=Manager,o=rori modifyTimestamp: 20071025192943Z
I have found various references to "Constraint violation: structuralObjectClass: no user modification allowed" on the internet, e.g. pointing out that a restore of a slapcat produced ldif with ldapadd will result in this error message (and ran myself into that problem, until I found out I was supposed to use slapadd), and apparently various people had the same occuring with replication, but I didn't see a solution. It seems that either master's ldap should not produce the structuralObjectClass: mozillaOrgPerson line (and other organization ones neither), or slave's ldap should accept it. The permissions I set according to advices on the list and slapd.access man page. What am I missing?
kind regards, Marcus
On Thursday 25 October 2007 21:51:12 Marcus Frischherz wrote:
Hi,
I think I searched the internet and the documentation carefully, and still have problems:
Master and slave are both openSuSE 10.2, running openldap 2.3.27 (unaltered SuSE version).
I set up in the master:
If this was *exactly* what was in your slapd.conf, it is broken. White space is very important in slapd.conf, there should be leading white space before the first characters on your line starting with bindmethod (as it is part of the replica statement, which should be on one line, and lines may be continued by using leading white space on the next line to aid readability).
replogfile /var/lib/ldap/slurpd/slurpd.replog replica host=frifri_vpn:389 binddn="uid=rmanager,ou=intern,o=rori" bindmethod=simple credentials=xxx
and on the slave: [...beginning of access rules] access to * by dn.exact="uid=rmanager,ou=intern,o=rori" write by * break
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword,userPKCS12 by self write by * auth
access to attrs=shadowLastChange by self write by * read
access to * by * read [...] updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
And here, the updatedn should be the first text on a new line (no leading white space), and the same thing for updateref. If you really have updatedn and updateref on the same line, this would explain your problem below.
and populated the slave's database with slapadd and restarted slapd on master and slave, + slurpd on master.
Everytime I make a change on the master I get in the rejection file the same error code: ERROR: Constraint violation: structuralObjectClass: no user modification allow ed replica: frifri_vpn:389 time: 1193340583.0 dn: cn=test test,ou=people,o=rori changetype: add sn: test givenName: test mail: x@y mozillaCustom2: FriFri cn: test test objectClass: top objectClass: inetOrgPerson objectClass: abookPerson objectClass: mozillaOrgPerson structuralObjectClass: mozillaOrgPerson entryUUID: 6208a648-177c-102c-9f5a-29bdb5d43dbc creatorsName: cn=Manager,o=rori createTimestamp: 20071025192943Z entryCSN: 20071025192943Z#000000#00#000000 modifiersName: cn=Manager,o=rori modifyTimestamp: 20071025192943Z
I have found various references to "Constraint violation: structuralObjectClass: no user modification allowed" on the internet, e.g. pointing out that a restore of a slapcat produced ldif with ldapadd will result in this error message (and ran myself into that problem, until I found out I was supposed to use slapadd), and apparently various people had the same occuring with replication, but I didn't see a solution. It seems that either master's ldap should not produce the structuralObjectClass: mozillaOrgPerson line (and other organization ones neither), or slave's ldap should accept it.
The slave will only accept operational attributes from the updatedn. Additionally, it won't accept any changes from anything but the updatedn, if the updateref is set. So, it seems like slapd on the slave is not parsing either of your updatedn or updateref statements.
If you don't succeed in fixing the issue, please attach sanitised versions of your configuration files, so we can be sure we are looking at *exactly* what you have in slapd.conf.
I note that slurpd-based replication is deprecated in 2.3, and slurpd has been removed from 2.4.
Regards, Buchan
Buchan Milne schrieb:
On Thursday 25 October 2007 21:51:12 Marcus Frischherz wrote:
Hi,
I set up in the master:
If this was *exactly* what was in your slapd.conf, it is broken. White space is very important in slapd.conf, there should be leading white space before the first characters on your line starting with bindmethod (as it is part of the replica statement, which should be on one line, and lines may be continued by using leading white space on the next line to aid readability).
replogfile /var/lib/ldap/slurpd/slurpd.replog replica host=frifri_vpn:389 binddn="uid=rmanager,ou=intern,o=rori" bindmethod=simple credentials=xxx
That newline was created by Thunderbird, in reality the replogfile statement is one line, and the replica statement is one line, without continuation
updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
And here, the updatedn should be the first text on a new line (no leading white space), and the same thing for updateref. If you really have updatedn and updateref on the same line, this would explain your problem below.
Well, that's what I thought, and what my LDAP book says. However, if I put the updateref statement on a separate subsequent line, I get the following error upon start-up of slapd: /etc/openldap/slapd.conf: line 103: <updateref> must appear after syncrepl or updatedn
This after I changed the slave to look like this: updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
The slave will only accept operational attributes from the updatedn. Additionally, it won't accept any changes from anything but the updatedn, if the updateref is set. So, it seems like slapd on the slave is not parsing either of your updatedn or updateref statements.
If you don't succeed in fixing the issue, please attach sanitised versions of your configuration files, so we can be sure we are looking at *exactly* what you have in slapd.conf.
How to samitize? tarred attachments?
I note that slurpd-based replication is deprecated in 2.3, and slurpd has been removed from 2.4.
Well, the administrator's guide, chapter 14, in the file replication.html distributed with the package openldap2 does not mention deprecation.
regards, Marcus
Marcus Frischherz wrote:
Buchan Milne schrieb:
On Thursday 25 October 2007 21:51:12 Marcus Frischherz wrote:
Hi,
I set up in the master:
If this was *exactly* what was in your slapd.conf, it is broken. White space is very important in slapd.conf, there should be leading white space before the first characters on your line starting with bindmethod (as it is part of the replica statement, which should be on one line, and lines may be continued by using leading white space on the next line to aid readability).
replogfile /var/lib/ldap/slurpd/slurpd.replog replica host=frifri_vpn:389 binddn="uid=rmanager,ou=intern,o=rori" bindmethod=simple credentials=xxx
That newline was created by Thunderbird, in reality the replogfile statement is one line, and the replica statement is one line, without continuation
updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
And here, the updatedn should be the first text on a new line (no leading white space), and the same thing for updateref. If you really have updatedn and updateref on the same line, this would explain your problem below.
Well, that's what I thought, and what my LDAP book says. However, if I put the updateref statement on a separate subsequent line, I get the following error upon start-up of slapd: /etc/openldap/slapd.conf: line 103: <updateref> must appear after syncrepl or updatedn
This after I changed the slave to look like this: updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
The slave will only accept operational attributes from the updatedn. Additionally, it won't accept any changes from anything but the updatedn, if the updateref is set. So, it seems like slapd on the slave is not parsing either of your updatedn or updateref statements.
If you don't succeed in fixing the issue, please attach sanitised versions of your configuration files, so we can be sure we are looking at *exactly* what you have in slapd.conf.
How to samitize? tarred attachments?
I note that slurpd-based replication is deprecated in 2.3, and slurpd has been removed from 2.4.
Well, the administrator's guide, chapter 14, in the file replication.html distributed with the package openldap2 does not mention deprecation.
Always read up to date docs when you can or search our archives.
Thanks.
Gavin Henry schrieb:
Marcus Frischherz wrote:
Buchan Milne schrieb:
On Thursday 25 October 2007 21:51:12 Marcus Frischherz wrote:
Always read up to date docs when you can or search our archives.
Well, that was not really helpful. In particular, it did not respond to any of my questions. Incidentally, I just checked what should be the most up to date doc (on-line on openldap site): http://www.openldap.org/doc/admin23/replication.html and the only mention it makes of the word deprecated is the "host option".
However, meanwhile I did configure the syncrepl mechanism, and found it to be easy to implement, and working, so I stopped trying to get the slurpd mechanism to work, but still think that it is broken somehow.
regards, Marcus
--On Friday, October 26, 2007 5:57 PM +0200 Marcus Frischherz marcus@casaberg.at wrote:
However, meanwhile I did configure the syncrepl mechanism, and found it to be easy to implement, and working, so I stopped trying to get the slurpd mechanism to work, but still think that it is broken somehow.
slurpd works just fine in Release 2.3. That's why there's a test that's shipped with the code to test whether or not it works. But in any case, I'm glad you got syncrepl working.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Well, the administrator's guide, chapter 14, in the file replication.html distributed with the package openldap2 does not mention deprecation.
Always read up to date docs when you can or search our archives.
ITS #5196 ?
This is why I filed that ITS, as it is quite obvious that it would have been useful if the last 2.3 release indicated the obsolescence of slurpd ...
Regards, Buchan
--On Friday, October 26, 2007 10:32 AM +0200 Marcus Frischherz marcus@casaberg.at wrote:
This after I changed the slave to look like this: updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
I think the slapd.conf man page is quite clear about this:
updateref <url>
Your updateref is *not* in url form:
updateref ldap://rori_vpn:389/
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Friday, October 26, 2007 9:30 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Friday, October 26, 2007 10:32 AM +0200 Marcus Frischherz marcus@casaberg.at wrote:
This after I changed the slave to look like this: updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
Also, your updatedn option was invalid. The man page is quite clear about this too:
updatedn <dn>
Note that there is no "=" sign there.
updaten uid=rmanager,ou=intern,o=rori
In the future, I suggest you *carefully* read the documentation.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Le Ven 26 octobre 2007 18:30, Quanah Gibson-Mount a écrit :
--On Friday, October 26, 2007 10:32 AM +0200 Marcus Frischherz marcus@casaberg.at wrote:
This after I changed the slave to look like this: updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
I think the slapd.conf man page is quite clear about this:
updateref <url>Your updateref is *not* in url form:
updateref ldap://rori_vpn:389/
An other problem is that you must not put '=' sign between updatedn and its value. Else slapd will take it as a single argument.
Regards, Raphaël Ouazana.
On Friday 26 October 2007 10:32:48 Marcus Frischherz wrote:
Buchan Milne schrieb:
On Thursday 25 October 2007 21:51:12 Marcus Frischherz wrote:
Hi,
I set up in the master:
If this was *exactly* what was in your slapd.conf, it is broken. White space is very important in slapd.conf, there should be leading white space before the first characters on your line starting with bindmethod (as it is part of the replica statement, which should be on one line, and lines may be continued by using leading white space on the next line to aid readability).
replogfile /var/lib/ldap/slurpd/slurpd.replog replica host=frifri_vpn:389 binddn="uid=rmanager,ou=intern,o=rori" bindmethod=simple credentials=xxx
That newline was created by Thunderbird, in reality the replogfile statement is one line, and the replica statement is one line, without continuation
updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
And here, the updatedn should be the first text on a new line (no leading white space), and the same thing for updateref. If you really have updatedn and updateref on the same line, this would explain your problem below.
Well, that's what I thought, and what my LDAP book says. However, if I put the updateref statement on a separate subsequent line, I get the following error upon start-up of slapd: /etc/openldap/slapd.conf: line 103: <updateref> must appear after syncrepl or updatedn
This after I changed the slave to look like this: updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389
If this was exactly what you had, then you would want to replace the updatedn="uid... with updatedn "uid...
Also, updateref is supposed to be a URI, so something more like ldap://rori_vpn:389 would be appropriate.
The slave will only accept operational attributes from the updatedn. Additionally, it won't accept any changes from anything but the updatedn, if the updateref is set. So, it seems like slapd on the slave is not parsing either of your updatedn or updateref statements.
If you don't succeed in fixing the issue, please attach sanitised versions of your configuration files, so we can be sure we are looking at *exactly* what you have in slapd.conf.
How to samitize? tarred attachments?
Remove any sensitive information, such as passwords (hashed or cleartext), or anything else you don't want to have public. However, you should not modify it too much as you may introduce errors.
I note that slurpd-based replication is deprecated in 2.3, and slurpd has been removed from 2.4.
Well, the administrator's guide, chapter 14, in the file replication.html distributed with the package openldap2 does not mention deprecation.
See my other reply, but I'll note that 2.4.5 shipped with no slurpd.
However, it does still work (for simple cases, more complex ones require some workarounds) in 2.3, but you may find it more productive to migrate to syncrepl.
Regards, Buchan
openldap-software@openldap.org
-
Buchan Milne -
Gavin Henry -
Marcus Frischherz -
Quanah Gibson-Mount -
Raphaël Ouazana-Sustowski