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)
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
