I'm using sites with gssapi auth. On some of the sites pages open very slowly and browser GUI freezes then works again for a second then freezes again and so on until the page is fully loaded.

I observe same behaviour with firefox, konqueror and epiphany.

I don't know how to debug the issue so suggestions are welcome but I do think the issue is debian specific to MIT kerberos package because:
1. using heimdal kerberos library all sites open normally without long annoying freezes (used the ff about:config to select it as gsslib)
2. on fedora 10 with the mit kerberos lib I also don't see these long freezes and slowness (tried to make krb5.conf equal on the two machines)

Regards

Can I get you to make sure that your krb5.conf explicitly lists the
KDCs for the realms in question, and that each KDC ends with a trailling period.
I.E.
kdc = kerberos.your.domain.
not
kdc = kerberos.your.domain

Also, do you see slowness the first time you open a location or all the time?

Can I get you to make sure that your krb5.conf explicitly lists the
KDCs for the realms in question, and that each KDC ends with a trailling period.
I.E.
kdc = kerberos.your.domain.
not
kdc = kerberos.your.domain

Also, do you see slowness the first time you open a location or all the time?

It is in the form kdc = <host>:<port> just like the standard entries
in the file. This is the same as on the fedora system which is
actually a virtualbox VM (with vbox nat networking) on the debian
machine so I'm excluding as a cause the network settings.
As well all sites I'm using kerberos auth with are with the same kdc.
Where should I put a dot if that can help?

It is always slow - slower the first time I open a page (I would guess
because some objects are cached).

Thanks

    Aleksandar> It is in the form kdc = <host>:<port> just like the
    Aleksandar> standard entries in the file. This is the same as on
    Aleksandar> the fedora system which is actually a virtualbox VM
    Aleksandar> (with vbox nat networking) on the debian machine so
    >

I'm looking into DNS issues; the VM under vboxnat doesn't entirely
exclude that.

put something like
kdc = <host.>:<port>

in krb5.conf.

Based on some other things, I suspect that's not the issue, but it is
important to rule out.

I don't have a lot of ideas here about what is going on.  I can think
of things that might be slow or blocking on the server side, but not
on the client side.
Do you happen to know approximately how many http connections are required in a given page load?
I'd expect that the only place any Kerberos could slow things down is during the initial sending of an HTTP request.

Actually with both machines I'm using the same DNS server (run on the
debian machine).

Yes, tried and doesn't seem to change anything.

I would guess that authentication is not threaded in browsers but why
can one library take so much longer than the other is very odd.

Looking at the firefox' status bar of the page there are probably near
300 objects (images?) have to be loaded.

btw. I tried using libgssglue configured to use mit kerberos and it is
also slow.

Regards

Can I get you to make sure you have krb5-user installed,

kinit -c KEYRING:blah <principal_name_goes_here>
and start firefox with the KRB5CCNAME environment variable set to KEYRING:blah

(to confirm you're using the keyring cache, probably doing a kdestroy
on your normal tickets would be good)

What I'm trying to do here is to see if the performance is dependent
on what type of credential cache is used.  I'm suspecting that there
is a locking problem in either MIT or Heimdal.  Either MIT holds a
lock too long, doesn't have fine grain locking somewhere, or Heimdal
has a race condition and is not holding a lock that it needs.  The
keyring cache has a different locking path than the file based cache.
So, it may perform differently.  If it is faster, then that tells us
something.  If it is not, then we don't learn much.

I don't have a test environment in which to reproduce this, although I
am talking to upstream about the issue.  I have not actually opened an
upstream bug at this point; I've brought the issue up on the krbcore
list.

Sorry for the delay but was overloaded with other things.

Yes, I have that package.
kinit -c KEYRING:blah <myuser>
export KRB5CCNAME="KEYRING:blah"
klist #now I see "Ticket cache: KEYRING:blah"
firefox & #very slow as before
klist #I see tickets requested for the web sites I'm trying to open

I wonder though if filesystem in use can make any difference given you
are suspecting some cache and locking?

I know it's very hard when you can't reproduce. I will understand if
you give up as after all it is not a critical issue to me (I'm fine
using heimdal).

Thanks for trying to help. If you have any other ideas, I'll be happy
to try. Actually I have one. I didn't try with any other kerberos
service so if you know some other I can try with both implementations,
that could possibly make a reproducer.

Regards

I've forwarded your latest message to upstream.

One advantage of the keyring cache is that it completely isolates the
file system for ticket caching.

Tcpdump shows me there are a lot of request and replyes on port 88.

Firefox logs:

How many requests do port 88 do you see?
Are most of them tgs requests?

I think you may have given a clue to what's going on.