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
