12:37 p.m.
Le mer. 15 mai 2019 19:52, Quanah Gibson-Mount <quanah(a)symas.com> a écrit :
--On Wednesday, May 15, 2019 8:23 PM +0200 Manuela Mandache
<manuela.mandache.mm(a)gmail.com> wrote:
> Actually, the replication is in refreshAndPersist mode.
Replication mode is immaterial.
Quanah,
Thanks a lot for your detailed and comprehensive answers.
Best regards,
Manuela
1:42 p.m.
New subject: accesslog database: overflow or data rotation?
--On Wednesday, May 15, 2019 10:37 PM +0200 Manuela Mandache
<manuela.mandache.mm(a)gmail.com> wrote:
Le mer. 15 mai 2019 19:52, Quanah Gibson-Mount <quanah(a)symas.com> a
écrit :
--On Wednesday, May 15, 2019 8:23 PM +0200 Manuela Mandache
<manuela.mandache.mm(a)gmail.com> wrote:
>> Actually, the replication is in refreshAndPersist mode.
>
> Replication mode is immaterial.
Thanks a lot for your detailed and comprehensive answers.
Heh, I can't tell in this case if your serious or sarcastic, but I'll note
this: it's entirely possible (and legal, and there are valid reasons for
it) to have an accesslog for a database where the environment is not
replicated at all. So replication mode, etc, is utterly immaterial to
whether or not an accesslog may exist, what its purge interval is, etc. If
that helps. :)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
7:12 a.m.
New subject: Changing timeouts from a slapd module
I'm calling a 3rd party 2FA API from within a password module in
OpenLDAP. The 2FA API call sends an SMS push to a mobile device.
If the push does not return a result within 10 seconds, auth
fails with what looks like a socket (tls_read) timeout[1]. What is going
on there and can this timeout be increased if that's what this is?
60 seconds would be more user friendly but after some experimentation
with ldap_set_option() I've not been able to affect the connection
timeout -- if that's what it is.
Thanks
------------------- push timed out ------------------------------
5ce4023e daemon: activity on 1 descriptor
5ce4023e daemon: activity on: 30r
5ce4023e daemon: read active on 30
5ce4023e daemon: epoll: listen=8 active_threads=0 tvp=zero
5ce4023e daemon: epoll: listen=9 active_threads=0 tvp=zero
5ce4023e daemon: epoll: listen=10 active_threads=0 tvp=zero
5ce4023e connection_get(30)
5ce4023e connection_get(30): got connid=1002
5ce4023e connection_read(30): checking for input on id=1002
ber_get_next
tls_read: want=5, got=5
0000: 17 03 03 00 26 ....&
tls_read: want=38, got=38
0000: 00 00 00 00 00 00 00 04 22 93 b3 d6 32 6d 6b c2
........"...2mk.
0010: 1c d2 4b 74 d9 87 8e c2 63 35 02 e4 5e 5f d6 76
..Kt....c5..^_.v
0020: b5 b4 8b d2 04 14 ......
ldap_read: want=8, got=8
0000: 30 0c 02 01 05 60 07 02 0....`..
ldap_read: want=6, got=6
0000: 01 03 04 00 80 00 ......
ber_get_next: tag 0x30 len 12 contents:
ber_dump: buf=0x7efc280008c0 ptr=0x7efc280008c0 end=0x7efc280008cc len=12
0000: 02 01 05 60 07 02 01 03 04 00 80 00 ...`........
5ce4023e op tag 0x60, time 1558446654
5ce4023e connection_input: conn=1002 deferring operation: binding
ber_get_next
tls_read: want=5 error=Resource temporarily unavailable
ldap_read: want=8, got=0
5ce4023e daemon: activity on 1 descriptor
5ce4023e daemon: activity on:
5ce4023e daemon: epoll: listen=8 active_threads=0 tvp=zero
5ce4023e daemon: epoll: listen=9 active_threads=0 tvp=zero
5ce4023e daemon: epoll: listen=10 active_threads=0 tvp=zero
2:31 p.m.
New subject: Changing timeouts from a slapd module
On 5/21/19 4:12 PM, dee heffem wrote:
I'm calling a 3rd party 2FA API from within a password module in
OpenLDAP. The 2FA API call sends an SMS push to a mobile device.
If the push does not return a result within 10 seconds, auth
fails with what looks like a socket (tls_read) timeout[1]. What is going
on there and can this timeout be increased if that's what this is?
60 seconds would be more user friendly but after some experimentation
with ldap_set_option() I've not been able to affect the connection
timeout -- if that's what it is.
Is your overlay processing a single bind operation?
AFAIK the slapd worker thread is blocked for the whole processing time
of a single bind operation. Thus I have some doubts that you want to
implement an auth mechanism with such asynchronous characteristics in an
overlay.
Ciao, Michael.
6:28 a.m.
New subject: Changing timeouts from a slapd module
On 5/21/19 4:31 PM, Michael Ströder wrote:
On 5/21/19 4:12 PM, dee heffem wrote:
<snip>>> 60
seconds would be more user friendly but after some
experimentation
> with ldap_set_option() I've not been able to affect the
connection
> timeout -- if that's what it is.
It seems after reloading my OpenLDAP test server this morning, the
ldap_set_option() timeout adjustment has indeed changed. I had merely
restarted slapd yesterday and for whatever reason the timeout
was unaffected.
Is your overlay processing a single bind operation?
AFAIK the slapd worker thread is blocked for the whole processing time
of a single bind operation. Thus I have some doubts that you want to
implement an auth mechanism with such asynchronous characteristics in an
overlay.
Yes. Also, I now see what you mean. Testing simultaneous auth sessions
was the next TODO after increasing the timeout. Alas, as you mention,
when two users attempt a bind (ldapsearch -D for instance) User #2 does
not get a push request until User #1 has finished auth. Blasted thing.
Can lutil_passwd_add() be told to run in another thread or something?
Perhaps this is just digging a hole deeper however.
Thanks
6:50 a.m.
New subject: Changing timeouts from a slapd module
On 5/22/19 3:28 PM, dee heffem wrote:
On 5/21/19 4:31 PM, Michael Ströder wrote:
> Is your overlay processing a single bind operation?
>
> AFAIK the slapd worker thread is blocked for the whole processing time
> of a single bind operation. Thus I have some doubts that you want to
> implement an auth mechanism with such asynchronous characteristics in an
> overlay.
Yes. Also, I now see what you mean. Testing simultaneous auth sessions
was the next TODO after increasing the timeout. Alas, as you mention,
when two users attempt a bind (ldapsearch -D for instance) User #2 does
not get a push request until User #1 has finished auth. Blasted thing.
I would not expect the 2nd request to block. I would expect the n+1 bind
operation to block with n being the value configured with slapd.conf
directive 'threads'.
Can lutil_passwd_add() be told to run in another thread or
something?
Perhaps this is just digging a hole deeper however.
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
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.
Ciao, Michael.
10:25 a.m.
New subject: 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
10:58 a.m.
New subject: Changing timeouts from a slapd module
On 5/24/19 7:25 PM, dee heffem wrote:
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?
Glad you put non-blocking in quotes. ;-)
AFAIK the listener threads dispatch operations to worker threads which
call the appropriate backend and its configured overlays. Therefore in
the default case max. 16 bind operation can be processed in parallel.
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?
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?
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.
Ciao, Michael.
1:33 p.m.
New subject: Changing timeouts from a slapd module
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
1575
days inactive
1590
days old
openldap-technical@openldap.org
8 comments
4 participants
participants (4)
-
dee heffem -
Manuela Mandache -
Michael Ströder -
Quanah Gibson-Mount