On Wed, Jan 07 2015 at 08:46:51 -0600, Dan White scribbled in "Re: Possible SASL bug seen with long-ish ldapmodify updates": > 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. I don't think it's specific to heimdal, as I'm pretty sure I tried against the libsasl2-modules-gssapi-mit package too, with the same outcome. I'll dig a little in the archive, and see if anything pops out. > 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). tweaking maxbufsize appears to have done the trick, though I'd like to know what you would consider a large value (or generally what you would consider a sensible value for a server with 32GB doing little other than running a low traffic postgresql DB and a slapd master)? I'm currently testing with maxbufsize=1572864 (and also maxbufsize=0, but I'm guessing that that disables some of the security?) Looking at the code, I'm guessing 16777215 (0xFFFFFF) is the maximum value? There are a couple of things in the Changelog that could, to my naïve eye be linked, but if it is a bug it was introduced at some point after 2.1.22 (where it doesn't appear to cause any trouble). Thanks so much for the help, you've saved me a lot of worry, and if there's any info that I can pass on that would help in tracking down the bug, I'd be happy to gather from my test systems what I can and hand it over. And just to doublecheck, maxbufsize is measured in bytes (meaning 16777215 would be ~16MB)? Thanks again Dan. Cheers. Dameon. -- ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <>< Dameon Wagner, Systems Development and Support Team IT Services, University of Oxford ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
