[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapmodify error

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 <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
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
> /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.