On Wed, 2017-12-06 at 10:53 -0600, Sergei Gerasenko wrote: > 389-ds-base-1.3.5.10-21.el7_3.x86_64. I do see errors like: > > connection - conn=1414256 fd=745 Incoming BER Element was too long, > max allowable is 2097152 bytes. Change the nsslapd-maxbersize > attribute in cn=config to increase. Master to Master traffic should ignore the maxbersize. I can't remember the ticket number, but I know we test for this. It's so that if one master has a maxber of X that's greater than the other masters, we can still replicate. So my advice - Sometimes we see this error when you use ldaps:// to a plaintext port IE ldaps://hostname:389. Is this possibly the issue you have replication set to SSL to a plaintext port? 1.3.7 has a better warning about this condition (we actually say "TLS on a plain port when it happens). > > > > On Dec 6, 2017, at 10:47 AM, Viktor Ashirov <vashirov@xxxxxxxxxx> > > wrote: > > > > Hi, > > On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko <gerases@gm > > ail.com> wrote: > > > Hi, > > > > > > I just discovered that I have a mismatch of BER sizes (nsslapd- > > > maxbersize) between some of my masters. On the masters that we > > > consider the authorative ones, the BER size is (cough, cough) > > > 209M while in the rest of the environment is the default 2M. I do > > > see occasional errors on the 2M masters complaining and > > > suggesting to increase the BER size. A couple of questions: > > > > > > 1. If the BER size of the supplier exceeds that of the consumer, > > > will it be automatically split into smaller chunks or will the > > > update just fail without any retries? > > > 2. Should I match the BER size accross the environment? I think > > > it’s obvious, but still asking just in case. > > > > What version of 389-ds-base do you have? BER size should be ignored > > [1] > > in replication in versions >=389-ds-base-1.3.5.2-1.el7 > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1223510 > > > > > > Thanks! > > > Sergei > > > _______________________________________________ > > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproje > > > ct.org > > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
