[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Changing timeouts from a slapd module
On 5/22/19 8:50 AM, Michael Ströder wrote:
<snip>
>
> Each request is processed by a slapd worker-thread. But this means that
> when setting
>
> threads n
>
> in your slapd.conf only max. n bind operations can wait for push
> message. The next one will block
I'm running OpenLDAP 2.4.42 (Ubuntu package) on the server which uses
cn=config. zytrax shows the equivalent parameter being olcThreads which
is 16 by default (I don't have the parameter set). Does this mean
I should expect to get 16 "non-blocking" push requests running
concurrently instead of only the one? Maybe I am misunderstanding -
You mentioned earlier: "slapd worker thread is blocked for the whole
processing time" so maybe this means the password overlay is not
designed to run concurrently and this is all for naught?
Additionally, regarding the 10 second timeout in my original post, I've
run more testing and it seems this timeout is limited to the Linux
`su` command. Huh..perhaps I need to look into the PAM stack config or
other client-side settings, not slapd. I'll have to try and hunt
that down. Authenticating with a PHP application, or using an
authenticated bind with ldapsearch doesn't timeout for nearly a minute.
>
> BTW: Not sure about the capabilities of the 2FA service you're using.
> Such a service might serialize all your calls or have some other type of
> rate-limiting in place.
The vendor offers a "push test" utility which simply sends a user a
push request to test the setup. I can indeed synchronously process
pushes to two users at once (slapd out of the loop) so I don't
believe the API is rate limiting at this point.
The source code for the utility is available and the same push call
they use is the one I use in the password overlay. The only difference
is I had to recompile the API library statically for use with slapd.
I will have to look into the gcc flags and make sure I didn't mess
something up there.
Thanks