Re: Possible SASL bug seen with long-ish ldapmodify updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 01/06/15 23:15 +0000, Dameon Wagner wrote:
I've been trying to solve an issue we're seeing with large batched
ldapmodify update, and with the help of the kind people over at
openldap-technical it seems that it may be more of a SASL issue than
an openldap issue.  Given that, I thought I'd ask here too, in case it
rings bells with anyone on the list.

During the course of my testing (we've not seen this in production,
thankfully) I've noticed that, with reasonably lengthy* updates for an
entry, ldapmodify dies with an error like the following:

As a work-around I can manually split up the list into several blocks
(tested with roughly 1000 member updates per block) with "replace:
member" for the first, to match the current behaviour, and "add:
member" for the rest. In this format, ldapmodify is happy to process
the LDIF (all in one connection, but as discreet operations totalling
about 1000 lines of updates or roughly 67K of changes).  (Note: the
authenticated user has "unlimited" limits in the config.)

We're using Debian wheezy, with the authenticating with Kerberos using
the libsasl2-modules-gssapi-heimdal Debian package of version
2.1.25.dfsg1-6+deb7u1.  On the older system we're in upgrading away
from we're using the lenny version of the package
(2.1.22.dfsg1-23+lenny1 -- hence planning the upgrade).

Has anyone on the list seen anything similar to the
"sb_sasl_cyrus_decode" and "sb_sasl_generic_read" failures in
situation like this?

I don't recall seeing those errors specifically, but I would guess there's
a bug here in the negotiation of the maximum security layer receive buffer
between libsasl and heimdal. I recall seeing some emails in years past
about it.

You can trouble shoot by using a libsasl compiled against MIT, or
experiment with olcSaslSecProps/sasl-secprops on the server, and
SASL_SECPROPS on the client. Try a large value for maxbufsize. See
slapd-config(5) and ldap.conf(5).

Dan White

[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux