<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 08/01/2012 09:20 AM, Loris Santamaria wrote: <blockquote cite="mid:1343834410.5050.0.camel@toron.pzo.lgs.com.ve" type="cite"> <pre wrap="">El mié, 01-08-2012 a las 10:35 -0400, Simo Sorce escribió: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2012-07-31 at 08:49 -0700, Stephen Ingram wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, Jul 31, 2012 at 1:39 AM, Petr Spacek <a class="moz-txt-link-rfc2396E" href="mailto:pspacek@redhat.com"><pspacek@redhat.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 07/31/2012 12:27 AM, John Dennis wrote: </pre> <blockquote type="cite"> <pre wrap=""> What is taking so long with session bookkeeping? I don't know yet. I would need more timing instrumentation. I will say when I looked at the python-krb5 code (which we use to populate the ccache from the session and read back to store in the session) seemed to be remarkably inefficient. We also elected to use file based ccache rather than in-memory ccache (that means there is a bit of file-IO occurring). </pre> </blockquote> <pre wrap=""> A note regarding python-krbV: I used python-krbV extensively in my thesis for KDC stress test. Python-krbV can obtain several thousands of TGTs per second (even with ccache in a file). AFAIK VFS calls are not done synchronously. But others parts of python-krbV were left uncovered, so it can contain some surprises. === Wild speculation follows === 1.5 second is incredibly long time, it sounds like some kind of timeout. Krb5 libs have usual timeout = 1 second per request. Are all KDCs in /etc/krb5.conf alive and reachable? </pre> </blockquote> <pre wrap=""> In this case, as I'm referring to the extreme slowness of the Web UI, the KDC is on the same system (the ipa server) that is making the request, correct? </pre> <blockquote type="cite"> <pre wrap="">Is SSSD running on problematic server? </pre> </blockquote> <pre wrap=""> Yes. Again, I'm guessing the problematic server is the IPA server itself. </pre> <blockquote type="cite"> <pre wrap="">Is proper KDC selected by SSSD KDC auto-locator plugin? (See /var/lib/sss/pubconf/) </pre> </blockquote> <pre wrap=""> Yes, I checked that file and it is the IP address of the IPA server on the same server. Perhaps should this be 127.0.0.1 instead? I also have checked the resolv.conf file, and indeed the IP points to the IPA server itself (same machine) as expected. Both forward and reverse DNS work. I'm not really sure what else could be setup incorrectly to cause any KDC slowness. Due to the extreme UI slowness issue, I have not created any replicas so this system is it. I'm not so sure I would be able to see the 1.5 s delay if it weren't compounded by the overall slowness of the Web UI, however, the KDC seems to perform well for other systems in the realm. I'm certainly not taxing it with a huge load, but tickets seem to be issued without delay. </pre> </blockquote> <pre wrap=""> Stephen, another user sent me a wireshark trace for a similar performance issue. So far I see a pause when doing the first leg of a SASL authentication. This may well explain also your issue. </pre> </blockquote> <pre wrap=""> Hi, I experience the same delay in SASL authentication. The number I posted on freeipa-users, show a 1-2 second delay with SASL authentication: # time ldapsearch -x uid=bdteg01662 dn # extended LDIF # # LDAPv3 # base <dc=xxx,dc=gob,dc=ve> (default) with scope subtree # filter: uid=bdteg01662 # requesting: dn # # bdteg01662, users, accounts, xxx.gob.ve dn: uid=bdteg01662,cn=users,cn=accounts,dc=xxx,dc=gob,dc=ve # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 real 0m0.006s user 0m0.001s sys 0m0.003s # time ldapsearch -Y GSSAPI uid=bdteg01662 dn SASL/GSSAPI authentication started SASL username: <a class="moz-txt-link-abbreviated" href="mailto:admin@XXX.GOB.VE">admin@XXX.GOB.VE</a> SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=xxx,dc=gob,dc=ve> (default) with scope subtree # filter: uid=bdteg01662 # requesting: dn # # bdteg01662, users, accounts, xxx.gob.ve dn: uid=bdteg01662,cn=users,cn=accounts,dc=xxx,dc=gob,dc=ve # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 real 0m2.344s user 0m0.007s sys 0m0.005s</pre> </blockquote> Can you post excerpts from your 389 access log showing the sequence of operations for this connection, bind and search? <blockquote cite="mid:1343834410.5050.0.camel@toron.pzo.lgs.com.ve" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">Can you test connecting to the ldap server using ldapsearch -Y GSSAPI (you need a kerberos ticket) and telling me if you experience any delay ? If you could run a bunch of searches in a loop and take a wireshark trace that may help analyzing the timings and seeing if there is a correlation. Simo. </pre> </blockquote> <pre wrap=""> </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ Freeipa-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a></pre> </blockquote> </body> </html>