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-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-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  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 RES

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 B

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/20

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

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:

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
>> f

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:

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  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 
>>>  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
 
 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

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 
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

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



___
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

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 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 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 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