Stephen Holland wrote:
> 
> /usr/local/squidGuard
> 
> [EMAIL PROTECTED] squidGuard]# ls -al
> total 20
> drw-r-----    4 squid    squid        4096 Mar 25 14:16 .
> drwxr-xr-x   17 root     root         4096 Mar 25 13:56 ..
> drw-r-----   13 squid    squid        4096 Mar 25 10:54 blacklists
> drw-r--r--    2 squid    squid        4096 Mar 25 11:03 log
> -rw-r--r--    1 squid    squid         413 Mar 25 14:16 squidGuard.conf
> [EMAIL PROTECTED] squidGuard]# pwd
> /usr/local/squidGuard
> [EMAIL PROTECTED] squidGuard]#

(Your blacklists and log directories were executable the first time 
you posted them.)  Change the log directory to root.root and 
drwxr-xr-x.  The squidGuard log is fine as you have listed it below.
'squid -k reconfigure' and that will solve your log file problem.
While you are at it, change squidGuard.conf to root.root. 
(squid.squid is important from the blacklists directory on down.)

> /usr/local/squidGuard/log  The information contained in the cat of 
> squidGuard.log is from when I run squidGuard commands independent of 
> squid.

This is always a good indicator of an ownership/permissions problem.
You are probably manually running the commands as root (which means  
squidGuard is running as root) and the logging works, but when
squidGuard runs as squid the logging fails.

I see from the squidGuard -v posted earlier that you are running
SquidGuard: 1.2.0 and Sleepycat Software: Berkeley DB 2.7.7.  I also
see from your squidGuard.log that you have created the .db files.
For the short term you'll need to delete those .db files and let
squidGuard run from the plain text files.  After you get squidGuard
running we'll need to talk about upgrading your Berkeley DB to 3.2.9,
and then you'll be able to recreate the .db files.  I have a little 
checklist that makes that upgrade a no-brainer; just let me know 
when you want the checklist and I'll send it to you.

A quick comment about your config file... The default acl processes 
unknown users/terminals. Known users/terminals are identified by
your source block(s) and have their own acl, leaving the unknown 
users/terminals for the default acl.  That being the case, 
"pass none" is a better choice than "pass all".

Keep us informed on how it goes!

Rick

Reply via email to