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
Hi, On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko gerases@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:
- 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?
- 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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@redhat.com wrote:
Hi, On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko gerases@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:
- 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?
- 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
On Wed, Dec 06 2017 at 10:53:49 -0600, Sergei Gerasenko gerases@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@redhat.com wrote:
Hi, On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko gerases@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:
- 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?
- 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Another master
On Dec 6, 2017, at 11:01 AM, Viktor Ashirov vashirov@redhat.com wrote:
On Wed, Dec 06 2017 at 10:53:49 -0600, Sergei Gerasenko gerases@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@redhat.com wrote:
Hi, On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko gerases@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:
- 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?
- 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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@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:
- 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproje ct.org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
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
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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
389-users@lists.fedoraproject.org
-
Sergei Gerasenko -
Viktor Ashirov -
William Brown