10:34 a.m.
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.
Thanks!
Sergei
10:47 a.m.
Hi,
On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko <gerases(a)gmail.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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
10:53 a.m.
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.
On Dec 6, 2017, at 10:47 AM, Viktor Ashirov
<vashirov(a)redhat.com> wrote:
Hi,
On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko <gerases(a)gmail.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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
11:01 a.m.
On Wed, Dec 06 2017 at 10:53:49 -0600, Sergei Gerasenko <gerases(a)gmail.com> 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.
Is
this connection coming from the other master? Or some client
connection?
> On Dec 6, 2017, at 10:47 AM, Viktor Ashirov <vashirov(a)redhat.com> wrote:
>
> Hi,
> On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko <gerases(a)gmail.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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
11:03 a.m.
Another master
On Dec 6, 2017, at 11:01 AM, Viktor Ashirov
<vashirov(a)redhat.com> wrote:
On Wed, Dec 06 2017 at 10:53:49 -0600, Sergei Gerasenko <gerases(a)gmail.com> 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.
Is this connection coming from the other master? Or some client
connection?
>
>
>> On Dec 6, 2017, at 10:47 AM, Viktor Ashirov <vashirov(a)redhat.com> wrote:
>>
>> Hi,
>> On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko <gerases(a)gmail.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(a)lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
2:34 a.m.
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(a)redhat.com>
> 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproje
> > ct.org
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
rg
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
3:55 p.m.
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?
I think in that case the message is:
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.
Note that it mentions the element size of 3 bytes. In the case in this thread however I
don’t see a size mentioned:
ns-slapd[45565]: [02/Dec/2017:22:47:52.520338378 +0000] connection - conn=1229556 fd=588
Incoming BER Element was too long, max allowable is 2097152 bytes. Change the
nsslapd-maxbersize attribute in cn=config to increase.
This makes me think it’s a different situation. I would imagine it shouldn’t have been
logged if it was ignored? But it’s possible...
Thanks,
Sergei
3:14 a.m.
On Fri, 2017-12-08 at 15:55 -0600, Sergei Gerasenko wrote:
> 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?
I think in that case the message is:
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.
Note that it mentions the element size of 3 bytes. In the case in
this thread however I don’t see a size mentioned:
ns-slapd[45565]: [02/Dec/2017:22:47:52.520338378 +0000] connection -
conn=1229556 fd=588 Incoming BER Element was too long, max allowable
is 2097152 bytes. Change the nsslapd-maxbersize attribute in
cn=config to increase.
This makes me think it’s a different situation. I would imagine it
shouldn’t have been logged if it was ignored? But it’s possible...
That message "was 3 bytes max allowable ..." means "SSL/TLS on a
plaintext port."
Newer versions of DS has a specific error message to explain this
better.
I think you should check your replication agreement configurations to
see if any of them list "ldaps://" instead of "ldap://" for a
StartTLS
connection perhaps. Or SSL vs TLS in the config.
Hope that helps,
Thanks,
Sergei
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
rg
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
2326
days inactive
2331
days old
389-users@lists.fedoraproject.org
7 comments
3 participants
participants (3)
-
Sergei Gerasenko -
Viktor Ashirov -
William Brown