On 01/07/15 16:10 +0000, Dameon Wagner wrote:
On Wed, Jan 07 2015 at 08:46:51 -0600, Dan White scribbled
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)?
Since this is merely a work around, you should use a value big enough to
support any individual sasl "session" that you anticipate having.
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.
You should file a bug report so with as much detail at you can, and the
developers may ask for additional details if they need them.
And just to doublecheck, maxbufsize is measured in bytes (meaning
16777215 would be ~16MB)?
I believe so, yes.
--
Dan White
