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