On 5/4/2014 1:27 PM, Graham Leggett wrote:
LDAP error "1" is LDAP_OPERATIONS_ERROR, which seems to be the ldap equivalent of "an error has occurred". There seems to be some kind of mechanism where a reason string is made available by the underlying code, but this is ignored by the above code, and the real reason for the error is lost. Regards, Graham -- -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
ottomh I can't think what's up with your servers, but for sure there's something very odd going on (beyond just "not configured correctly" I suspect). The errors where the replica initialization reports that the database index files have been deleted underneath it are particularly wacky.
Anyway, I'd recommend that you turn up the logging level on the servers. This will hopefully reveal more about what's going wrong. Also look carefully in the log for the _first_ sign of trouble. That will likely be the root cause. I suspect you have a lot of fog of war showing up that's generated by some underlying prime error, that aught to have appeared first in the timeline.
It should be possible to add an N+1th replica to an N-node deployment. Replication agreements are peer-to-peer, so you just add a new replication agreement from each of the servers you want to feed changes to the N+1th (typically all of them).
In the log messages, where you were wondering which consumer server is throwing the error, the name of the replication agreement is typically printed. So the server it is trying to talk to is the one that's the target for the replication agreement mentioned.
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
