[squid-users] Re: Re: Tweaking squid_kerb_auth

>
>"Nick Cairncross" <Nick.Cairncross_at_condenast.co.uk> wrote in message
>news:C8C638C1.11799%nick.cairncross_at_condenast.co.uk...
>>
>>Hi Nick,
>>
>> The only tweaking which might be required is for MIT based libraries on
>>a
>>high load system to disable the replay cache by setting
>>
>> KRB5RCACHETYPE=none
>> export KRB5RCACHETYPE
>>
>>Markus
>>
>>
>>"Nick Cairncross" <Nick.Cairncross_at_condenast.co.uk> wrote in message
>>news:C8B7B33A.F61B%nick.cairncross_at_condenast.co.uk...
>>Hi,
>>
>>Running Kerberos auth ok for a while now and I wanted to look at
>>possibilities of tweaking/optimising it.
>>
>>Current helper conf:
>>auth_param negotiate program /usr/lib/squid/squid_kerb_auth -r -i -s
>>GSS_C_NO_NAME
>>auth_param negotiate children 10
>>auth_param negotiate keep_alive on
>>
>>400 or so AD users. Squid 3 STABLE 20 at the moment. Not caching, just
>>authenticate and go.
>>
>>What are the lists experiences of increasing children? Resources are not
>>a
>>problem as the machine is VM and I can always grant more.
>>
>>I remember reading something about Kerberos specific option(s) for squid
>>­
>>something to do with re-using tickets but can't remember.could anyone
>>shed
>>some light on it (and their experiences).
>>
>>I will be looking at moving to 3.1. Have the extra startup and idle
>>helped
>>you etc? Have you got any recommendations you have found have helped?
>>
>>I'm interested to hear your experiences/suggestions.
>>
>>Thanks,
>>Nick
>
>Hi Markus,
>Thanks for your input - I wondered something: I know this question depends
>on my AD infrastructure but how many requests/ps can the 10 Kerberos
>children optimally handle? Could I increase it to increase the Kerberos
>availability - say to 20 children? Or is that a bad idea?
>

I don't know the effect of increasing the number of children. I assume it
is possible to get statistics about how many children are used and how
often, but the experts have to answers this.

>Also, forgive the obvious but how do I check which libraries I am using
>again..?

Depends on your OS. On a system with rpm you can do

> ldd squid_kerb_auth
        linux-gate.so.1 => (0xffffe000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb77e6000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7747000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7720000)
        libdes425.so.3 => /usr/lib/libdes425.so.3 (0xb771b000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb76fa000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb76e4000)
        libc.so.6 => /lib/libc.so.6 (0xb7588000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb757f000)
        libdl.so.2 => /lib/libdl.so.2 (0xb757a000)
        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb7576000)
        /lib/ld-linux.so.2 (0xb7814000)
> rpm -q -i -f /usr/lib/libgssapi_krb5.so.2
Name : krb5 Relocations: (not relocatable)
Version : 1.6.3 Vendor: openSUSE
Release : 132.8.1 Build Date: Fri 21 May 2010
01:13:07 BST
Install Date: Sun 15 Aug 2010 21:59:01 BST Build Host: langsam
Group : Productivity/Networking/Security Source RPM:
krb5-1.6.3-132.8.1.src.rpm
Size : 1499825 License: X11/MIT
Signature : RSA/8, Fri 21 May 2010 01:14:32 BST, Key ID b88b2fd43dbdc284
Packager : http://bugs.opensuse.org
URL : http://web.mit.edu/kerberos/www/
Summary : MIT Kerberos5 Implementation--Libraries
Description :
Kerberos V5 is a trusted-third-party network authentication system,
which can improve your network's security by eliminating the insecure
practice of clear text passwords.

Authors:
--------
    The MIT Kerberos Team
    Sam Hartman <hartmans_at_mit.edu>
    Ken Raeburn <raeburn_at_mit.edu>
    Tom Yu <tlyu_at_mit.edu>
Distribution: openSUSE 11.1

>Thanks,
>Nick
>

Markus

>
>The information contained in this e-mail is of a confidential nature and is
>intended only for the addressee. If you are not the intended addressee,
>any disclosure, copying or distribution by you is prohibited and may be
>unlawful. Disclosure to any party other than the addressee, whether
>inadvertent or otherwise, is not intended to waive privilege or
>confidentiality. Internet communications are not secure and therefore
>Conde Nast does not accept legal responsibility for the contents of this
>message. Any views or opinions expressed are those of the author.
>
>The Conde Nast Publications Ltd (No. 226900), Vogue House, Hanover Square,
>London W1S 1JU
>
Received on Mon Sep 27 2010 - 19:42:01 MDT