Re: [squid-users] pam_auth pam_end()

On 10/04/11 01:09, Eugene M. Zheganin wrote:
> Hi.
>
> On 15.03.2011 16:54, Amos Jeffries wrote:
>>
>> Start with the -d option.
>> Then add/update debug() lines to any place that looks useful. I'm
>> interested in making the debug helpful so patches for that are welcome
>> upstream.
>> debug() operates identical to printf() but sends the result to the
>> helper channel for Squid cache.log.
>>
>> FWIW, I think adding pam_strerror() results into both of the WARNING:
>> messages with that text should be enough to point at the actual problem.
>>
> Well... I did all of that (and it didn't help). By the way, debug seems
> to be a macro, rather than a squid channel logging function (could it be
> even possible ? main part of squid 3.x is written in C++ and the helper
> part - in C). Anyway, may be it's time to describe my problem, rather
> than to describe the solution as I see it. :)
>
> Okay, the problem description: as I said I have a proxy. That's the
> company main proxy, and the wpad for the network of more than 2K
> machines points at it. So, during the weekdays I have loads of requests
> from all sorts of clients, most of them remains blocked, but all of the
> basic authentication requests are handled by pam_auth. I have 35
> simultaneously running pam_auth processes. During load peaks I ususally
> have 3-5 (sometimes even more) pam_auth processes that eat 100% of the
> both CPUs all together. I used to think that those are the processes
> that squid failed to release. But, when I kill some of it to release the
> CPUs from unnecessary load, squid complains in its log like that:
>
> WARNING: basicauthenticator #8 (FD 93) exited
>
> It's obvious that I'm wrong and this isn't the helper squid cannot
> release, but this is the actually running helper. So the questions are
>
> - why only small parts of basic helpers are affected with such load ?

credentials tests are requested of the first available helper program.

Under load every time the first helper finished it gets a new request to
handle, so is constantly in use. So the first few will get all the load
and later ones will only get load when the earlier one(s) fill up.

> - why such load even exists ? when I kill affected processes squid
> continues to run without influencing its clients for some time. Then the
> load appears again.

That is unclear. It could be anything from that being the actual request
load, to a config design problem causing unnecessary calls to the auth
helpers, to a problem in PAM dong a lot of extra work for nothing.

> - and, of course, what can be done to solve this.
>
> I had a look at the code of the helper - it seems to be very
> straightforward and simple, so I don't see how such a simple code can
> eat CPU.

If it is called too often it can east CPU, or if the PAM backend is the
actual CPU consumer.

>
> The basic helper config is:
>
> auth_param basic program /usr/local/libexec/squid/pam_auth
> auth_param basic children 35
> auth_param basic realm Squid[Kamtelecom]
> auth_param basic credentialsttl 1 minute

60 seconds between checks with the PAM helper will raise load. On small
networks with few clients this is not a problem, but larger ones it
could be.

> auth_param basic casesensitive off
>
> and the pam config for the squid service name is:
>
> auth sufficient pam_unix.so no_warn
> auth sufficient /usr/local/lib/pam_winbind.so try_first_pass
> auth sufficient pam_krb5.so no_warn try_first_pass
>
> auth required pam_deny.so no_warn
>

I don't believe pam_winbind or pam_krb5 will work with this config using
Basic auth. They are for NTLM and Negotiate auth respectively.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.6