It sounds to me like you're attempting to import a database dump into a running slave, either by means of
slapcat. A running slapd instance with a replication mechanism configured in slave mode will reject all write attempts and return the message you provided.
If my slurpd based slapd servers ever became inconsistent I executed a fairly straight forward recovery procedure:
- Put the master into read-only mode.
- Make a fresh dump from the master and copy it to any inconsistent slaves (or copy from backups).
- Completely stop slapd on the slave you want to recover.
- Clear the contents of the data directory,
/var/lib/ldap (you might want to save your
DB_CONFIG file if the parameters aren't defined in slapd.conf)
slapadd to rebuild the directory on the slave (move
DB_CONFIG back if necessary)
- Start the slave normally.
Switch the master back into read-write mode.
yes, I am using slurpd replication method. It was running fine but somehow it broke down and till then its not working
You're probably running OpenLDAP 2.3.43 since that's what's packaged in CentOS 5.4. Unfortunately because of that you're also likely to run into replication issues again in the future unless you can upgrade to a newer OpenLDAP (2.4) server.
slurpd was very flawed, check out the OpenLDAP 2.4 docs for a complete explanation of why. The newer OpenLDAP releases come with a new replication mechanism called
syncrepl which is much more robust and nearly impervious to failure.
In the future if you're interested in getting help migrating to a newer OpenLDAP server I can offer guidance there as well.