On 5/24/19 12:58 PM, Michael Ströder wrote:
<snip>
No. It simply means that processing the LDAP operations is done synchronously in worker thread.
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)
Really in a single OS process?
Perhaps I misrepresented. This was done in two different terminal processes.
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.
This library could also serialize calls into the library with a lock.
I was busy with a few other projects this week but just came back to this. I was going through some code and this caught my eye:
static ldap_pvt_thread_mutex_t my_mutex; ... ldap_pvt_thread_mutex_lock (...); ... ldap_pvt_thread_mutex_unlock (...);
in my password overlay. I used some of the contrib overlays to develop with and the radius.c overlay used this. I guessed it best to implement the same since I am also using an external API.
I don't have time today to experiment but this may be where the blocking is coming from. Would you know what the intention of ldap_pvt_thread_mutex_t is from the standpoint of the password overlay?
Thank you