Hey list,
I have openlldap running on one box with replog enabled. I am trying to propagate the generated replog on the production and when using the ldapmodify command I get the following:
ldap_modify: Constraint violation (19) additional info: entryCSN: no user modification allowed
test server is exact mirror of the production in every sense apart from the platforms they are running on which I believe showuld not be the issue. They have same configuration and everything.
Any pointer will be appreciated .
Thanks!
NZ
Naufal Sheikh wrote:
I have openlldap running on one box with replog enabled.
Can you please elaborate on which version of OpenLDAP you're running and which replication scheme you configured? Ideally by providing the slapd.conf.
I am trying to propagate the generated replog on the production and when using the ldapmodify command I get the following:
ldap_modify: Constraint violation (19) additional info: entryCSN: no user modification allowed
What exactly are you doing? If you don't provide enough of the relevant information nobody can help.
Ciao, Michael.
Hi,
Ok, I am using openldap 2.2.20 on both machines. My production server is Solaris 8, while my backup machine is redhat linux 8. I am not really using some kind of sophisticated replication scheme, but simply this is what I have done.
I have added replog attribute in the slapd.conf of my backup machine. I switch off my production for maintainance, and swithc the backup on. AS it has replog enabled it starts creating logs of the events, After maintainance activity I ftp the replog to production and use ldapmodify to apply those logs on production.
ldapmodify script which I am using is :
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/main/soft/openldap/openldap-2.2.20 /lib:/main/soft/openssl/openssl-0.9.7e/lib:/main/soft/berkeleydb/db-4.2.52 /lib export LD_LIBRARY_PATH
/main/soft/openldap/openldap-2.2.20/bin/ldapmodify \ -d 7 \ -v -x -W -D "cn=nsadmin" -h hostname -p 389 -f /main/backup replog.
And when I run the script the error I get is
ldap_modify: Constraint violation (19) additional info: entryCSN: no user modification allowed
IF I edit my replog and remove all the stuff like
replace: lastModifiedTime lastModifiedTime: 2008-03-24 12:27 - replace: entryCSN entryCSN: 20080324172725Z#000001#00#000000 - replace: modifiersName modifiersName: cn=nsadmin - replace: modifyTimestamp modifyTimestamp: 20080324172725Z
and only keep what exactly was done, the script is able to apply that ldif to the production.
I had been doing it before and I am not sure now what is going wrong which is creating this problem.
I'll appreciate any pointer.
Thanks --NZ -
On Sat, Mar 22, 2008 at 6:07 AM, Michael Ströder michael@stroeder.com wrote:
Naufal Sheikh wrote:
I have openlldap running on one box with replog enabled.
Can you please elaborate on which version of OpenLDAP you're running and which replication scheme you configured? Ideally by providing the slapd.conf.
I am trying to propagate the generated replog on the production and when using the ldapmodify command I get the following:
ldap_modify: Constraint violation (19) additional info: entryCSN: no user modification allowed
What exactly are you doing? If you don't provide enough of the relevant information nobody can help.
Ciao, Michael.
On Monday 24 March 2008 19:40:01 Naufal Sheikh wrote:
Hi,
Ok, I am using openldap 2.2.20 on both machines. My production server is Solaris 8, while my backup machine is redhat linux 8. I am not really using some kind of sophisticated replication scheme, but simply this is what I have done.
I have added replog attribute in the slapd.conf of my backup machine. I switch off my production for maintainance, and swithc the backup on. AS it has replog enabled it starts creating logs of the events, After maintainance activity I ftp the replog to production and use ldapmodify to apply those logs on production.
This is really not a good idea. You may rather want to consider one of these options: 1)Running read-only on the slave during maintenance on the master 2)Use cluster software to run an HA master 3)Upgrade to 2.4 and run mirrormode or multi-master
ldapmodify script which I am using is :
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/main/soft/openldap/openldap-2.2.20 /lib:/main/soft/openssl/openssl-0.9.7e/lib:/main/soft/berkeleydb/db-4.2.52 /lib export LD_LIBRARY_PATH
/main/soft/openldap/openldap-2.2.20/bin/ldapmodify \ -d 7 \ -v -x -W -D "cn=nsadmin" -h hostname -p 389 -f /main/backup replog.
If you are processing a replication log, you should use the identity that is listed in the updatedn parameter on the target. It is the only identity allowed to write to operational attributes.
Regards, Buchan
Thanks for your replies. I guess I need to stick to what I am doing for now cos its really temporary. Anyways ur poinbter really did it. Just had to add the updatedn in slapd.conf of production and it is now picking the replogs.
Thanks!
On Tue, Mar 25, 2008 at 5:50 AM, Buchan Milne bgmilne@staff.telkomsa.net wrote:
On Monday 24 March 2008 19:40:01 Naufal Sheikh wrote:
Hi,
Ok, I am using openldap 2.2.20 on both machines. My production server is Solaris 8, while my backup machine is redhat linux 8. I am not really
using
some kind of sophisticated replication scheme, but simply this is what I have done.
I have added replog attribute in the slapd.conf of my backup machine. I switch off my production for maintainance, and swithc the backup on. AS
it
has replog enabled it starts creating logs of the events, After maintainance activity I ftp the replog to production and use ldapmodify
to
apply those logs on production.
This is really not a good idea. You may rather want to consider one of these options: 1)Running read-only on the slave during maintenance on the master 2)Use cluster software to run an HA master 3)Upgrade to 2.4 and run mirrormode or multi-master
ldapmodify script which I am using is :
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/main/soft/openldap/openldap-2.2.20 /lib:/main/soft/openssl/openssl-0.9.7e/lib:/main/soft/berkeleydb/db-
4.2.52
/lib export LD_LIBRARY_PATH
/main/soft/openldap/openldap-2.2.20/bin/ldapmodify \ -d 7 \ -v -x -W -D "cn=nsadmin" -h hostname -p 389 -f /main/backup
replog.
If you are processing a replication log, you should use the identity that is listed in the updatedn parameter on the target. It is the only identity allowed to write to operational attributes.
Regards, Buchan
Hi Buchan,
I added updatedn attribute in my production slapd.conf and it was same as rootdn.
rootdn "cn=nsadmin" updatedn "cn=nsadmin"
production server was applying the replogs from the temp server fine untill i nocticed that after adding this attribute, I could no longer add an entry on my production but modify only. That is starnge....
regards
On Tue, Mar 25, 2008 at 2:20 PM, Naufal Sheikh naufalzamir@gmail.com wrote:
Thanks for your replies. I guess I need to stick to what I am doing for now cos its really temporary. Anyways ur poinbter really did it. Just had to add the updatedn in slapd.conf of production and it is now picking the replogs.
Thanks!
On Tue, Mar 25, 2008 at 5:50 AM, Buchan Milne bgmilne@staff.telkomsa.net wrote:
On Monday 24 March 2008 19:40:01 Naufal Sheikh wrote:
Hi,
Ok, I am using openldap 2.2.20 on both machines. My production server
is
Solaris 8, while my backup machine is redhat linux 8. I am not really
using
some kind of sophisticated replication scheme, but simply this is what
I
have done.
I have added replog attribute in the slapd.conf of my backup machine.
I
switch off my production for maintainance, and swithc the backup on.
AS it
has replog enabled it starts creating logs of the events, After maintainance activity I ftp the replog to production and use
ldapmodify to
apply those logs on production.
This is really not a good idea. You may rather want to consider one of these options: 1)Running read-only on the slave during maintenance on the master 2)Use cluster software to run an HA master 3)Upgrade to 2.4 and run mirrormode or multi-master
ldapmodify script which I am using is :
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/main/soft/openldap/openldap-2.2.20 /lib:/main/soft/openssl/openssl-0.9.7e/lib:/main/soft/berkeleydb/db-
4.2.52
/lib export LD_LIBRARY_PATH
/main/soft/openldap/openldap-2.2.20/bin/ldapmodify \ -d 7 \ -v -x -W -D "cn=nsadmin" -h hostname -p 389 -f /main/backup
replog.
If you are processing a replication log, you should use the identity that is listed in the updatedn parameter on the target. It is the only identity allowed to write to operational attributes.
Regards, Buchan
Naufal Sheikh wrote:
Ok, I am using openldap 2.2.20 on both machines.
You should seriously consider upgrading since 2.2.x is historic since quite a while. Historic means there is absolutely no support for this code base anymore. Even no security fixes! Nada!
I have added replog attribute in the slapd.conf of my backup machine. I switch off my production for maintainance, and swithc the backup on. AS it has replog enabled it starts creating logs of the events, After maintainance activity I ftp the replog to production and use ldapmodify to apply those logs on production.
This is a very unusual approach. Note that ldapmodify is a normal DUA (directory *user* agent).
ldap_modify: Constraint violation (19) additional info: entryCSN: no user modification allowed
IF I edit my replog and remove all the stuff like
replace: lastModifiedTime lastModifiedTime: 2008-03-24 12:27
replace: entryCSN entryCSN: 20080324172725Z#000001#00#000000
These attributes are operational attributes not modifiable by a normal DUA. Consider deploying a real replication mechanism (syncrepl preferred). There are several modes available which should satisfy your particular needs.
http://www.openldap.org/doc/admin24/config.html#Replicated%20Directory%20Ser...
http://www.openldap.org/doc/admin24/replication.html
http://www.openldap.org/faq/data/cache/1170.html
Ciao, Michael.
openldap-software@openldap.org
-
Buchan Milne -
Michael Ströder -
Naufal Sheikh