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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
