[Date Prev][Date Next]
Re: ldapmodify error
I added updatedn attribute in my production slapd.conf and it was same as rootdn.
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....
On Tue, Mar 25, 2008 at 2:20 PM, Naufal Sheikh <firstname.lastname@example.org
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.
On Tue, Mar 25, 2008 at 5:50 AM, Buchan Milne <email@example.com
On Monday 24 March 2008 19:40:01 Naufal Sheikh wrote:This is really not a good idea. You may rather want to consider one of these
> 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.
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
If you are processing a replication log, you should use the identity that is
> ldapmodify script which I am using is :
> 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.
listed in the updatedn parameter on the target. It is the only identity
allowed to write to operational attributes.