> >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@xxxxxxxxxxxxxxx> wrote in message >news:C8B7B33A.F61B%nick.cairncross@xxxxxxxxxxxxxxxxxx >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? Also, forgive the obvious but how do I check which libraries I am using again..? Thanks, Nick 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
