On 11/03/2017 02:53 PM, Sergei Gerasenko wrote:
>> Also, you mentioned that the agreement might have been
disabled. What field of the nsds5replicationagreement class shows that?
> nsds5ReplicaEnabled
Thank you
>> Given the error in the log, and the low likelihood of the agreement being
disabled for a week, what else can cause a node not to find a CSN?
> Have you restored from a backup recently?
No
> You need to look through all the logs to further troubleshoot this. For now I would
get everyone in sync then monitor replication, and archive your logs for the next week.
That way you have a full data set to investigate if something goes wrong.
Ok, I’ll try to plow through the logs. I might still have them.
> What version of 389 are you on? rpm -qa | grep 389-ds-base
389-ds-base-libs-1.3.5.10-21.el7_3.x86_64
389-ds-base-1.3.5.10-21.el7_3.x86_64
Actually you might be running into a known bug
which is fixed in 1.3.6
and up. Sorry 1.3.5/el7_3 is no longer supported or maintained.
What does this tell you:
[25/Oct/2017:18:16:43.389794105 +0000] connection - conn=167482 fd=121 Incoming BER
Element was 3 bytes, max allowable is 2097152 bytes. Change the nsslapd-maxbersize
attribute in cn=config to increase.
This is confusing, it was 3 bytes which is < 2097152 and still the log message.
This happens when you try to open a ssl connection on the non-secure
port. We have a bug open on this to make that error message means
something useful (the message should be fixed in 1.3.7)