Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-28 Thread Jakub Hrozek 
On Tue, May 27, 2014 at 07:34:58PM -0400, Bret Wortman wrote:
 No problem. We forced a re installation of openldap, which helped. Pam login 
 is still slow but sudo isn't. We'll keep chipping away at it. 

As said earlier in the thread, logs might be the best way to move this
forward.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-28 Thread Bret Wortman 
The CD is in the hands of the security folks now. I'll let you know when 
I have it and can transfer the logs over to you.


It's only 2GB worth of data, but I hope it's informative.


Bret

On 05/28/2014 03:52 AM, Jakub Hrozek wrote:

On Tue, May 27, 2014 at 07:34:58PM -0400, Bret Wortman wrote:

No problem. We forced a re installation of openldap, which helped. Pam login is 
still slow but sudo isn't. We'll keep chipping away at it.

As said earlier in the thread, logs might be the best way to move this
forward.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users





smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-27 Thread Rob Crittenden 
Bret Wortman wrote:
 Crud. That was supposed to have a second comparison log too:
 
 I found something in the slapd-FOO-NET/access log. I figured out which
 conn ID related to a sudo -i that I performed which took longer than
 expected and grepped for that conn ID:
 
 [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from
 192.168.208.129 to 192.168.10.111
 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
 oid=1.3.6.1.4.1.1466.20037 name=startTLS
 [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
 nentries=0 etime=0
 [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
 [26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
 [26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97
 nentries=0 etime=0
 [26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH
 base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) attrs=ALL
 [26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101
 nentries=0 etime=0
 [26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH
 base=ou=SUDOers,dc=foo,dc=net scope=2
 filter=(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204)
 (sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL)) attrs=ALL
 [26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101
 nentries=2 etime=0
 [26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH
 base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(sudoUser=+*) attrs=ALL
 [26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101
 nentries=0 etime=0
 [26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND
 [26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1
 
 I think this shows, roughly, a 7 second elapsed time from start to
 finish, right? Granted, there were other request being serficed during
 this interval as well, but nothing that looked like outrageous volume.

I don't see anything unusual here. The directory server retrieved the
data just as fast on both systems, the difference appears to be the
network, in connection and shutdown times.

 On our faster network, this same exchange went much faster:
 
 [26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from
 192.168.2.13 to 192.168.2.61
 [26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT
 oid=1.3.6.1.4.1.1466.20037 name=startTLS
 [26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120
 nentries=0 etime=0
 [26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES
 [26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND
 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me method=128 version=3
 [26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97
 nentries=0 etime=0 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me
 [26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH
 base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(cn=defaults)
 attrs=ALL
 [26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101
 nentries=0 etime=0
 [26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH
 base=ou=SUDOers,dc=wedgeofli,dc=me scope=2
 filter=(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL))
 attrs=ALL
 [26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101
 nentries=1 etime=0
 [26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH
 base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(sudoUser=+*)
 attrs=ALL
 [26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101
 nentries=0 etime=0
 [26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND
 [26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1
 
 
 
 Bret
 
 On 05/26/2014 09:51 AM, Bret Wortman wrote:
 Okay, I found something in the slapd-FOO-NET/access log. I figured out
 which conn ID related to a sudo -i that I performed which took longer
 than expected and grepped for that conn ID:

 [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection
 from 192.168.208.129 to 192.168.10.111
 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
 oid=1.3.6.1.4.1.1466.20037 name=startTLS
 [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
 nentries=0 etime=0
 [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
 [26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
 [26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97
 nentries=0 etime=0
 [26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH
 base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) attrs=ALL
 [26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101
 nentries=0 etime=0
 [26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH
 base=ou=SUDOers,dc=foo,dc=net scope=2

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-27 Thread Dmitri Pal 

On 05/27/2014 08:41 AM, Rob Crittenden wrote:

Bret Wortman wrote:

Crud. That was supposed to have a second comparison log too:

I found something in the slapd-FOO-NET/access log. I figured out which
conn ID related to a sudo -i that I performed which took longer than
expected and grepped for that conn ID:

[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from
192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) attrs=ALL
[26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2
filter=(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204)
(sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL)) attrs=ALL
[26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101
nentries=2 etime=0
[26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(sudoUser=+*) attrs=ALL
[26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND
[26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1

I think this shows, roughly, a 7 second elapsed time from start to
finish, right? Granted, there were other request being serficed during
this interval as well, but nothing that looked like outrageous volume.

I don't see anything unusual here. The directory server retrieved the
data just as fast on both systems, the difference appears to be the
network, in connection and shutdown times.

+1, however the TLS handshake took longer. That probably required 
several DNS lookups so I wonder if DNS lookups might be slowing things down.
I wonder if putting server records manually into the hosts file would 
make a difference. If yes then may be you need to take a look at your 
DNS setup for the slow network.




On our faster network, this same exchange went much faster:

[26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from
192.168.2.13 to 192.168.2.61
[26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES
[26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me method=128 version=3
[26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97
nentries=0 etime=0 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me
[26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(cn=defaults)
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2
filter=(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL))
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(sudoUser=+*)
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND
[26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1



Bret

On 05/26/2014 09:51 AM, Bret Wortman wrote:

Okay, I found something in the slapd-FOO-NET/access log. I figured out
which conn ID related to a sudo -i that I performed which took longer
than expected and grepped for that conn ID:

[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection
from 192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) attrs=ALL
[26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-27 Thread Bret Wortman 

I'll get with my network guys and start troubleshooting.

Thanks!

On 05/27/2014 09:20 AM, Dmitri Pal wrote:

On 05/27/2014 08:41 AM, Rob Crittenden wrote:

Bret Wortman wrote:

Crud. That was supposed to have a second comparison log too:

I found something in the slapd-FOO-NET/access log. I figured out which
conn ID related to a sudo -i that I performed which took longer than
expected and grepped for that conn ID:

[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection 
from

192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) 
attrs=ALL

[26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2
filter=(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) 

(sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL)) 
attrs=ALL

[26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101
nentries=2 etime=0
[26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(sudoUser=+*) 
attrs=ALL

[26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND
[26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1

I think this shows, roughly, a 7 second elapsed time from start to
finish, right? Granted, there were other request being serficed during
this interval as well, but nothing that looked like outrageous volume.

I don't see anything unusual here. The directory server retrieved the
data just as fast on both systems, the difference appears to be the
network, in connection and shutdown times.

+1, however the TLS handshake took longer. That probably required 
several DNS lookups so I wonder if DNS lookups might be slowing things 
down.
I wonder if putting server records manually into the hosts file would 
make a difference. If yes then may be you need to take a look at your 
DNS setup for the slow network.




On our faster network, this same exchange went much faster:

[26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from
192.168.2.13 to 192.168.2.61
[26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES
[26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me method=128 
version=3

[26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97
nentries=0 etime=0 
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me

[26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(cn=defaults)
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2
filter=(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL)) 


attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(sudoUser=+*)
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND
[26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1



Bret

On 05/26/2014 09:51 AM, Bret Wortman wrote:

Okay, I found something in the slapd-FOO-NET/access log. I figured out
which conn ID related to a sudo -i that I performed which took longer
than expected and grepped for that conn ID:

[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection
from 192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-27 Thread Bret Wortman 
I just checked to be sure, and we do already put all the IPA servers in 
our client host tables just to be sure they can be reached even if DNS 
goes down.


On 05/27/2014 09:20 AM, Dmitri Pal wrote:

On 05/27/2014 08:41 AM, Rob Crittenden wrote:

Bret Wortman wrote:

Crud. That was supposed to have a second comparison log too:

I found something in the slapd-FOO-NET/access log. I figured out which
conn ID related to a sudo -i that I performed which took longer than
expected and grepped for that conn ID:

[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection 
from

192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) 
attrs=ALL

[26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2
filter=(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) 

(sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL)) 
attrs=ALL

[26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101
nentries=2 etime=0
[26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(sudoUser=+*) 
attrs=ALL

[26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND
[26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1

I think this shows, roughly, a 7 second elapsed time from start to
finish, right? Granted, there were other request being serficed during
this interval as well, but nothing that looked like outrageous volume.

I don't see anything unusual here. The directory server retrieved the
data just as fast on both systems, the difference appears to be the
network, in connection and shutdown times.

+1, however the TLS handshake took longer. That probably required 
several DNS lookups so I wonder if DNS lookups might be slowing things 
down.
I wonder if putting server records manually into the hosts file would 
make a difference. If yes then may be you need to take a look at your 
DNS setup for the slow network.




On our faster network, this same exchange went much faster:

[26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from
192.168.2.13 to 192.168.2.61
[26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES
[26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me method=128 
version=3

[26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97
nentries=0 etime=0 
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me

[26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(cn=defaults)
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2
filter=(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL)) 


attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(sudoUser=+*)
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND
[26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1



Bret

On 05/26/2014 09:51 AM, Bret Wortman wrote:

Okay, I found something in the slapd-FOO-NET/access log. I figured out
which conn ID related to a sudo -i that I performed which took longer
than expected and grepped for that conn ID:

[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection
from 192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-27 Thread Dmitri Pal 

On 05/27/2014 09:44 AM, Bret Wortman wrote:
I just checked to be sure, and we do already put all the IPA servers 
in our client host tables just to be sure they can be reached even if 
DNS goes down.


Sorry, I am running out of ideas.



On 05/27/2014 09:20 AM, Dmitri Pal wrote:

On 05/27/2014 08:41 AM, Rob Crittenden wrote:

Bret Wortman wrote:

Crud. That was supposed to have a second comparison log too:

I found something in the slapd-FOO-NET/access log. I figured out which
conn ID related to a sudo -i that I performed which took longer than
expected and grepped for that conn ID:

[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection 
from

192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) 
attrs=ALL

[26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2
filter=(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) 

(sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL)) 
attrs=ALL

[26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101
nentries=2 etime=0
[26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(sudoUser=+*) 
attrs=ALL

[26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND
[26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1

I think this shows, roughly, a 7 second elapsed time from start to
finish, right? Granted, there were other request being serficed during
this interval as well, but nothing that looked like outrageous volume.

I don't see anything unusual here. The directory server retrieved the
data just as fast on both systems, the difference appears to be the
network, in connection and shutdown times.

+1, however the TLS handshake took longer. That probably required 
several DNS lookups so I wonder if DNS lookups might be slowing 
things down.
I wonder if putting server records manually into the hosts file would 
make a difference. If yes then may be you need to take a look at your 
DNS setup for the slow network.




On our faster network, this same exchange went much faster:

[26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection 
from

192.168.2.13 to 192.168.2.61
[26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES
[26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me method=128 
version=3

[26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97
nentries=0 etime=0 
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me

[26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(cn=defaults)
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2
filter=(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL)) 


attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(sudoUser=+*)
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND
[26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1



Bret

On 05/26/2014 09:51 AM, Bret Wortman wrote:
Okay, I found something in the slapd-FOO-NET/access log. I figured 
out

which conn ID related to a sudo -i that I performed which took longer
than expected and grepped for that conn ID:

[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection
from 192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-27 Thread Bret Wortman 
No problem. We forced a re installation of openldap, which helped. Pam login is 
still slow but sudo isn't. We'll keep chipping away at it. 


Bret Wortman
http://bretwortman.com/
http://twitter.com/BretWortman

 On May 27, 2014, at 7:15 PM, Dmitri Pal d...@redhat.com wrote:
 
 On 05/27/2014 09:44 AM, Bret Wortman wrote:
 I just checked to be sure, and we do already put all the IPA servers in our 
 client host tables just to be sure they can be reached even if DNS goes down.
 
 Sorry, I am running out of ideas.
 
 
 On 05/27/2014 09:20 AM, Dmitri Pal wrote: 
 On 05/27/2014 08:41 AM, Rob Crittenden wrote: 
 Bret Wortman wrote: 
 Crud. That was supposed to have a second comparison log too: 
 
 I found something in the slapd-FOO-NET/access log. I figured out which 
 conn ID related to a sudo -i that I performed which took longer than 
 expected and grepped for that conn ID: 
 
 [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from 
 192.168.208.129 to 192.168.10.111 
 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT 
 oid=1.3.6.1.4.1.1466.20037 name=startTLS 
 [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 
 nentries=0 etime=0 
 [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES 
 [26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND 
 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3 
 [26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97 
 nentries=0 etime=0 
 [26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH 
 base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) attrs=ALL 
 [26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101 
 nentries=0 etime=0 
 [26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH 
 base=ou=SUDOers,dc=foo,dc=net scope=2 
 filter=(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204)
  
 (sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL)) attrs=ALL 
 [26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101 
 nentries=2 etime=0 
 [26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH 
 base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(sudoUser=+*) attrs=ALL 
 [26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101 
 nentries=0 etime=0 
 [26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND 
 [26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1 
 
 I think this shows, roughly, a 7 second elapsed time from start to 
 finish, right? Granted, there were other request being serficed during 
 this interval as well, but nothing that looked like outrageous volume.
 I don't see anything unusual here. The directory server retrieved the 
 data just as fast on both systems, the difference appears to be the 
 network, in connection and shutdown times.
 +1, however the TLS handshake took longer. That probably required several 
 DNS lookups so I wonder if DNS lookups might be slowing things down. 
 I wonder if putting server records manually into the hosts file would make 
 a difference. If yes then may be you need to take a look at your DNS setup 
 for the slow network. 
 
 
 On our faster network, this same exchange went much faster: 
 
 [26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from 
 192.168.2.13 to 192.168.2.61 
 [26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT 
 oid=1.3.6.1.4.1.1466.20037 name=startTLS 
 [26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120 
 nentries=0 etime=0 
 [26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES 
 [26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND 
 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me method=128 
 version=3 
 [26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97 
 nentries=0 etime=0 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me 
 [26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH 
 base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(cn=defaults) 
 attrs=ALL 
 [26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101 
 nentries=0 etime=0 
 [26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH 
 base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 
 filter=(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL))
  
 attrs=ALL 
 [26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101 
 nentries=1 etime=0 
 [26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH 
 base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(sudoUser=+*) 
 attrs=ALL 
 [26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101 
 nentries=0 etime=0 
 [26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND 
 [26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1 
 
 
 
 Bret 
 
 On 05/26/2014 09:51 AM, Bret Wortman wrote: 
 Okay, I found something in the slapd-FOO-NET/access log. I figured out 
 which conn ID related to a sudo -i that I performed which took longer 
 than expected and grepped for that conn ID:

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-26 Thread Bret Wortman 

Crud. That was supposed to have a second comparison log too:

I found something in the slapd-FOO-NET/access log. I figured out which 
conn ID related to a sudo -i that I performed which took longer than 
expected and grepped for that conn ID:


[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from 
192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT 
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 
nentries=0 etime=0

[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND 
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97 
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH 
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) attrs=ALL
[26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101 
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH 
base=ou=SUDOers,dc=foo,dc=net scope=2 
filter=(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) 
(sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL)) attrs=ALL
[26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101 
nentries=2 etime=0
[26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH 
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(sudoUser=+*) attrs=ALL
[26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101 
nentries=0 etime=0

[26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND
[26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1

I think this shows, roughly, a 7 second elapsed time from start to 
finish, right? Granted, there were other request being serficed during 
this interval as well, but nothing that looked like outrageous volume.


On our faster network, this same exchange went much faster:

[26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from 
192.168.2.13 to 192.168.2.61
[26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT 
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120 
nentries=0 etime=0

[26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES
[26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND 
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me method=128 version=3
[26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn=uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me
[26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH 
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(cn=defaults) 
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101 
nentries=0 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH 
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 
filter=(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL)) 
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101 
nentries=1 etime=0
[26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH 
base=ou=SUDOers,dc=wedgeofli,dc=me scope=2 filter=(sudoUser=+*) 
attrs=ALL
[26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101 
nentries=0 etime=0

[26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND
[26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1



Bret

On 05/26/2014 09:51 AM, Bret Wortman wrote:
Okay, I found something in the slapd-FOO-NET/access log. I figured out 
which conn ID related to a sudo -i that I performed which took longer 
than expected and grepped for that conn ID:


[26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection 
from 192.168.208.129 to 192.168.10.111
[26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT 
oid=1.3.6.1.4.1.1466.20037 name=startTLS
[26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 
nentries=0 etime=0

[26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
[26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND 
dn=uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net method=128 version=3
[26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97 
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH 
base=ou=SUDOers,dc=foo,dc=net scope=2 filter=(cn=deraults) attrs=ALL
[26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101 
nentries=0 etime=0
[26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH 
base=ou=SUDOers,dc=foo,dc=net scope=2 
filter=(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) 
(sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL)) attrs=ALL
[26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101 
nentries=2 etime=0
[26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH

[Freeipa-users] LDAP/SSSD/IPA performance

2014-05-23 Thread Bret Wortman 
Collecting my various threads together under one big issue and adding 
this new data point:


Our web UI on our slow network is exhibiting some strange behavior as well.

When selecting, for example, the Users, it can take up to 5 seconds to 
fetch 20 out of our 56 entries.


When switching to Hosts, it took 4 seconds for the footer to show that 
there would be 47 pages in total, then after 10 seconds total, the page 
loaded 20 of 939 entries. When I select a host, the previously-selected 
host will actually be displayed for upwards of 8-10 seconds (while the 
spinning cursor spins near the word Logout) until the host actually loads.


Is it just me, or does this, plus everything else, start to sound like 
LDAP is struggling?


I ran a test using ldapsearch in authenticated and unauthenticated mode 
from my workstation and here's what I found, which may tell us nothing:


# time ldapsearch -x -H -ldap://zsipa.foo.net 
base=uid=bretw,cn=users,cn=accounts,dc=foo,dc=net

:
real0m2.047s
user   0m0.000s
sys 0m0.001s
# time ldapsearch -Y GSSAPI -H ldap://zsipa.foo.net 
base=uid=bretw,cn=users,cn=accounts,dc=foo,dc=net

:
real0m2.816s
user   0m0.004s
sys 0m0.002s

When I did this locally on the ipa master:

# ssh zsipa.foo.net
# time ldapsearch -Y GSSAPI 
base=uid=bretw,cn=uses,cn=accounts,dc=foo,dc=net

:
real0m0.847s
user   0m0.007s
sys 0m0.006s
#


--
*Bret Wortman*

http://damascusgrp.com/
http://about.me/wortmanbret



smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-23 Thread Bret Wortman 

More soft/anecdotal:

When executing sudo -i or sudo -iu the first time, we can expect a 
several second delay before the command completes. If we then exit the 
session and re-execute the command, it will complete almost instantly. 
So whatever cache is holding this information, if we could increase its 
duration, that would certainly make our pain less. Is this a settable value?


Entering a password into a screensaver is particularly painful. 10+ 
seconds before the screensaver will exit.


We are looking at environmental possibilities, like interfaces and such. 
This machine is running on a VMware VM, but we've had success deploying 
IPA on VMs in the past, and our faster network is running VMs as well 
(with one physical box).



Bret


On 05/23/2014 08:15 AM, Bret Wortman wrote:
Collecting my various threads together under one big issue and adding 
this new data point:


Our web UI on our slow network is exhibiting some strange behavior as 
well.


When selecting, for example, the Users, it can take up to 5 seconds 
to fetch 20 out of our 56 entries.


When switching to Hosts, it took 4 seconds for the footer to show 
that there would be 47 pages in total, then after 10 seconds total, 
the page loaded 20 of 939 entries. When I select a host, the 
previously-selected host will actually be displayed for upwards of 
8-10 seconds (while the spinning cursor spins near the word Logout) 
until the host actually loads.


Is it just me, or does this, plus everything else, start to sound like 
LDAP is struggling?


I ran a test using ldapsearch in authenticated and unauthenticated 
mode from my workstation and here's what I found, which may tell us 
nothing:


# time ldapsearch -x -H -ldap://zsipa.foo.net 
base=uid=bretw,cn=users,cn=accounts,dc=foo,dc=net

:
real0m2.047s
user   0m0.000s
sys 0m0.001s
# time ldapsearch -Y GSSAPI -H ldap://zsipa.foo.net 
base=uid=bretw,cn=users,cn=accounts,dc=foo,dc=net

:
real0m2.816s
user   0m0.004s
sys 0m0.002s

When I did this locally on the ipa master:

# ssh zsipa.foo.net
# time ldapsearch -Y GSSAPI 
base=uid=bretw,cn=uses,cn=accounts,dc=foo,dc=net

:
real0m0.847s
user   0m0.007s
sys 0m0.006s
#


--
*Bret Wortman*

http://damascusgrp.com/
http://about.me/wortmanbret



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users




smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-23 Thread Jakub Hrozek 
On Fri, May 23, 2014 at 09:48:00AM -0400, Bret Wortman wrote:
 More soft/anecdotal:
 
 When executing sudo -i or sudo -iu the first time, we can expect
 a several second delay before the command completes. If we then exit
 the session and re-execute the command, it will complete almost
 instantly. So whatever cache is holding this information, if we
 could increase its duration, that would certainly make our pain
 less. Is this a settable value?
 
 Entering a password into a screensaver is particularly painful. 10+
 seconds before the screensaver will exit.
 
 We are looking at environmental possibilities, like interfaces and
 such. This machine is running on a VMware VM, but we've had success
 deploying IPA on VMs in the past, and our faster network is running
 VMs as well (with one physical box).

Can you try increasing this option:

   pam_id_timeout (integer)
   For any PAM request while SSSD is online, the SSSD will attempt to
   immediately update the cached identity information for the user in
   order to ensure that authentication takes place with the latest
   information.

   A complete PAM conversation may perform multiple PAM requests, such
   as account management and session opening. This option controls (on
   a per-client-application basis) how long (in seconds) we can cache
   the identity information to avoid excessive round-trips to the
   identity provider.

   Default: 5

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-23 Thread Jakub Hrozek 
On Fri, May 23, 2014 at 04:03:44PM +0200, Jakub Hrozek wrote:
 On Fri, May 23, 2014 at 09:48:00AM -0400, Bret Wortman wrote:
  More soft/anecdotal:
  
  When executing sudo -i or sudo -iu the first time, we can expect
  a several second delay before the command completes. If we then exit
  the session and re-execute the command, it will complete almost
  instantly. So whatever cache is holding this information, if we
  could increase its duration, that would certainly make our pain
  less. Is this a settable value?
  
  Entering a password into a screensaver is particularly painful. 10+
  seconds before the screensaver will exit.
  
  We are looking at environmental possibilities, like interfaces and
  such. This machine is running on a VMware VM, but we've had success
  deploying IPA on VMs in the past, and our faster network is running
  VMs as well (with one physical box).
 
 Can you try increasing this option:
 
pam_id_timeout (integer)
For any PAM request while SSSD is online, the SSSD will attempt to
immediately update the cached identity information for the user in
order to ensure that authentication takes place with the latest
information.
 
A complete PAM conversation may perform multiple PAM requests, such
as account management and session opening. This option controls (on
a per-client-application basis) how long (in seconds) we can cache
the identity information to avoid excessive round-trips to the
identity provider.
 
Default: 5

I should also have explicitly said that the option belongs to the [pam]
section.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-23 Thread Bret Wortman 
I assumed. It obviously hasn't helped our sudo situation, but I wouldn't 
expect it to. I'll let you know how it plays against screensavers and such.


On 05/23/2014 10:05 AM, Jakub Hrozek wrote:

On Fri, May 23, 2014 at 04:03:44PM +0200, Jakub Hrozek wrote:

On Fri, May 23, 2014 at 09:48:00AM -0400, Bret Wortman wrote:

More soft/anecdotal:

When executing sudo -i or sudo -iu the first time, we can expect
a several second delay before the command completes. If we then exit
the session and re-execute the command, it will complete almost
instantly. So whatever cache is holding this information, if we
could increase its duration, that would certainly make our pain
less. Is this a settable value?

Entering a password into a screensaver is particularly painful. 10+
seconds before the screensaver will exit.

We are looking at environmental possibilities, like interfaces and
such. This machine is running on a VMware VM, but we've had success
deploying IPA on VMs in the past, and our faster network is running
VMs as well (with one physical box).

Can you try increasing this option:

pam_id_timeout (integer)
For any PAM request while SSSD is online, the SSSD will attempt to
immediately update the cached identity information for the user in
order to ensure that authentication takes place with the latest
information.

A complete PAM conversation may perform multiple PAM requests, such
as account management and session opening. This option controls (on
a per-client-application basis) how long (in seconds) we can cache
the identity information to avoid excessive round-trips to the
identity provider.

Default: 5

I should also have explicitly said that the option belongs to the [pam]
section.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users





smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-23 Thread Dmitri Pal 

On 05/23/2014 10:03 AM, Bret Wortman wrote:


On 05/23/2014 09:53 AM, Mauricio Tavares wrote:




On Fri, May 23, 2014 at 9:48 AM, Bret Wortman 
bret.wort...@damascusgrp.com mailto:bret.wort...@damascusgrp.com 
wrote:


More soft/anecdotal:

When executing sudo -i or sudo -iu the first time, we can
expect a several second delay before the command completes. If we
then exit the session and re-execute the command, it will
complete almost instantly. So whatever cache is holding this
information, if we could increase its duration, that would
certainly make our pain less. Is this a settable value?

Entering a password into a screensaver is particularly painful.
10+ seconds before the screensaver will exit.

We are looking at environmental possibilities, like interfaces
and such. This machine is running on a VMware VM, but we've had
success deploying IPA on VMs in the past, and our faster network
is running VMs as well (with one physical box).


Bret

  Did running sudo in debugging mode (SUDOERS_DEBUG  2 in 
ldap.conf) give you any more clues?



No. I compared the output on both networks and there's no real 
difference once I accounted for HBAC on one (which produced 2 entries 
on the slower network that got filtered down to 1 user match and 1 
host match). But the debug output was nearly identical.


Did you see any gaps in time in the logs that are different?
The flow can be the same but some operations can take longer so there 
would be hint to us on what to look for.






On 05/23/2014 08:15 AM, Bret Wortman wrote:

Collecting my various threads together under one big issue and
adding this new data point:

Our web UI on our slow network is exhibiting some strange
behavior as well.

When selecting, for example, the Users, it can take up to 5
seconds to fetch 20 out of our 56 entries.

When switching to Hosts, it took 4 seconds for the footer to
show that there would be 47 pages in total, then after 10
seconds total, the page loaded 20 of 939 entries. When I select
a host, the previously-selected host will actually be displayed
for upwards of 8-10 seconds (while the spinning cursor spins
near the word Logout) until the host actually loads.

Is it just me, or does this, plus everything else, start to
sound like LDAP is struggling?

I ran a test using ldapsearch in authenticated and
unauthenticated mode from my workstation and here's what I
found, which may tell us nothing:

# time ldapsearch -x -H -ldap://zsipa.foo.net
http://zsipa.foo.net
base=uid=bretw,cn=users,cn=accounts,dc=foo,dc=net
:
real0m2.047s
user   0m0.000s
sys 0m0.001s
# time ldapsearch -Y GSSAPI -H ldap://zsipa.foo.net
base=uid=bretw,cn=users,cn=accounts,dc=foo,dc=net
:
real0m2.816s
user   0m0.004s
sys 0m0.002s

When I did this locally on the ipa master:

# ssh zsipa.foo.net http://zsipa.foo.net
# time ldapsearch -Y GSSAPI
base=uid=bretw,cn=uses,cn=accounts,dc=foo,dc=net
:
real0m0.847s
user   0m0.007s
sys 0m0.006s
#


-- 
*Bret Wortman*


http://damascusgrp.com/
http://about.me/wortmanbret



___
Freeipa-users mailing list
Freeipa-users@redhat.com  mailto:Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



___
Freeipa-users mailing list
Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users






___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] LDAP/SSSD/IPA performance

2014-05-23 Thread Bret Wortman 
All I saw was additional output when I ran the command. On the slower system, 
there was a one second lag, then a burst of activity, then a one second lag, 
then completion. I’ll do it again Monday and see what the logs show.

On May 23, 2014, at 2:44 PM, Dmitri Pal d...@redhat.com wrote:

 On 05/23/2014 10:03 AM, Bret Wortman wrote:
 
 On 05/23/2014 09:53 AM, Mauricio Tavares wrote:
 
 
 
 On Fri, May 23, 2014 at 9:48 AM, Bret Wortman 
 bret.wort...@damascusgrp.com wrote:
 More soft/anecdotal:
 
 When executing sudo -i or sudo -iu the first time, we can expect a 
 several second delay before the command completes. If we then exit the 
 session and re-execute the command, it will complete almost instantly. So 
 whatever cache is holding this information, if we could increase its 
 duration, that would certainly make our pain less. Is this a settable value?
 
 Entering a password into a screensaver is particularly painful. 10+ seconds 
 before the screensaver will exit.
 
 We are looking at environmental possibilities, like interfaces and such. 
 This machine is running on a VMware VM, but we've had success deploying IPA 
 on VMs in the past, and our faster network is running VMs as well (with one 
 physical box).
 
 
 Bret
 
   Did running sudo in debugging mode (SUDOERS_DEBUG  2 in ldap.conf) 
 give you any more clues?
 
 No. I compared the output on both networks and there's no real difference 
 once I accounted for HBAC on one (which produced 2 entries on the slower 
 network that got filtered down to 1 user match and 1 host match). But the 
 debug output was nearly identical.
 
 Did you see any gaps in time in the logs that are different?
 The flow can be the same but some operations can take longer so there would 
 be hint to us on what to look for.
 
 
 
 On 05/23/2014 08:15 AM, Bret Wortman wrote:
 Collecting my various threads together under one big issue and adding this 
 new data point:
 
 Our web UI on our slow network is exhibiting some strange behavior as well.
 
 When selecting, for example, the Users, it can take up to 5 seconds to 
 fetch 20 out of our 56 entries.
 
 When switching to Hosts, it took 4 seconds for the footer to show that 
 there would be 47 pages in total, then after 10 seconds total, the page 
 loaded 20 of 939 entries. When I select a host, the previously-selected 
 host will actually be displayed for upwards of 8-10 seconds (while the 
 spinning cursor spins near the word Logout) until the host actually loads.
 
 Is it just me, or does this, plus everything else, start to sound like 
 LDAP is struggling?
 
 I ran a test using ldapsearch in authenticated and unauthenticated mode 
 from my workstation and here's what I found, which may tell us nothing:
 
 # time ldapsearch -x -H -ldap://zsipa.foo.net 
 base=uid=bretw,cn=users,cn=accounts,dc=foo,dc=net
 :
 real0m2.047s
 user   0m0.000s
 sys 0m0.001s
 # time ldapsearch -Y GSSAPI -H ldap://zsipa.foo.net 
 base=uid=bretw,cn=users,cn=accounts,dc=foo,dc=net
 :
 real0m2.816s
 user   0m0.004s
 sys 0m0.002s
 
 When I did this locally on the ipa master:
 
 # ssh zsipa.foo.net
 # time ldapsearch -Y GSSAPI 
 base=uid=bretw,cn=uses,cn=accounts,dc=foo,dc=net
 :
 real0m0.847s
 user   0m0.007s
 sys 0m0.006s
 #
 
 
 -- 
 Bret Wortman
 Mail Attachment.png
 http://damascusgrp.com/
 http://about.me/wortmanbret
 
 
 
 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users
 
 
 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users
 
 
 
 
 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users
 
 
 -- 
 Thank you,
 Dmitri Pal
 
 Sr. Engineering Manager IdM portfolio
 Red Hat, Inc.
 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users