Mike Rambo wrote:
>
> I've looked at implementing this suggestion and like some of what it
> would allow me to do. The problem I've run into is that the squid
> cachemgr.cgi will no longer run correctly with the default acl set to
> pass none. The cgi comes and I can authenticate but I don't see the
> list of items I should see from the cachemgr.cgi script.
>
> Here is my default acl. The cgi works as it sits now. If I comment out
> the first pass statement and uncomment 'pass none' cachemgr.cgi dies.
>
> default {
> pass !local-block local-ok !ads !aggressive !drugs\
> !gambling !hacking !porn !violence !warez all
> #pass none
> redirect http://192.168.189.9/cgi-bin/squidGuard.cgi?\
> clientaddr=%a&clientname=%n&clientident=%i\
> &srcclass=%s&targetgroup=%t&url=%u
> }
>
> Why would I be hitting the default acl anyway?
If you were being processed by a 'pass none' default squidGuard acl
you would have been looking at your redirect screen, not a partial
squid cachemgr.cgi screen.
> I'm accessing the cachemgr from a machine this is in a subnet
> covered by another acl. It seems like it must be because the cgi
> script itself is doing the access to get the information and is
> seen as making the access not from the subnet of my client but
> rather the subnet of the squid box (or not?)? I've tried putting
> the subnet (and even the host) for the squid box in another acl
> and once tried a no_cache directive for the squid box in squid.conf
> to no avail. I'm missing something here.
Me too! :) Are we talking about squidGuard.conf or squid.conf? I
think you said that cachemgr.cgi works fine, then you make one change
in squidGuard.conf (changing default acl to pass none) and
cachemgr.cgi doesn't work (correctly) anymore?
I'm not sure what's going on, but without seeing your squidGuard.conf
file I can't even make a guess. But I can tell you the things I do
to research problems of that sort.
First, I want to look at the transaction in squid's access.log. A
quick way to do that is to enter this in a shell session on your
squid box:
'tail -f /var/log/squid/access.log > mycapture'
Run the transaction that is failing from the problem location, then
enter <ctrl>c in the shell session where you started the capture.
(If you need a utility to convert squid time to human time you can
find linux and windows versions here:
<http://techno-abn.narod.ru/EN/PROGS/index.html>)
Here's the squid access.log entry for my test transaction:
2004/Apr/20 10:13:08.135 48 192.168.44.3 TCP_HIT/200 973 GET \
http://www.foxnews.com/ Rick NONE/- text/html
I can see that squid saw the requesting ip address as 192.168.44.3
and the user ident was Rick.
Next, I want to see how squidGuard handled the transaction. (That's
the reason my squidGuard.conf contains a 'log' statement in each
section that can deny a transaction.) So I look in my squidGuard
blocked.log and find:
2004-04-20 10:13:08 [21930] Request(default/none/-) \
http://www.foxnews.com/ 192.168.44.3/- rick GET
This shows me that the user information that squidGuard received from
squid matches my expectations (192.168.44.3, rick). It also tells me
why squidGuard decided to redirect: (default/none/-). The transaction
was processed using source group=default and destination group=none.
[The fields are (source group/destination group/rewrite group)]
At this point I have verified that squidGuard is seeing the expected
ip address and user ident, therefore my squidGuard.conf is telling
squidGuard to use the default acl. I can then focus my energies on
debugging my squidGuard.conf file.
Hope that helps!
Rick
