Hi Rick, Logs are owned by proxy:proxy and are 777. I did a "chown proxy:proxy squidGuard/ -R" and a "chmod 777 squidGuard/ -R" and everything related to squidGuard falls under this directory.
I was using "su proxy" but even with "su - proxy" it still runs fine. The output to screen is: [root@moria squid]# su - proxy bash-2.04$ /usr/local/squid/squidGuard/bin/squidGuard -c /usr/local/squid/squidGuard/squidGuard.conf -d 2002-11-16 14:43:47 [11823] squidGuard 1.2.0 started (1037450627.014) 2002-11-16 14:43:47 [11823] squidGuard ready for requests (1037450627.015) I ran "which squidGuard" but it isn't in the normal paths. However, a "locate squidGuard" shows the executable in only one place. On Sat, 2002-11-16 at 08:34, Rick Matthews wrote: > Mark Shearar wrote: > > > > Is it correct that it's binding to localhost? There are a total of 20 > > routable IP's for it to choose from on the box. Could that be the > > problem? > > I don't know if it is correct or not, but that's what mine does and > it seems to be working fine. :) > > > The entire dir of squidGuard is owned by proxy:proxy and permissions > > are set to 777 (not very safe I know). > > What about the ownership of the log files and database files? > > > If I su to proxy and copy and paste the relevant redirector line > > to my command prompt (ie to verify paths etc), squidGuard works. > > Did you use 'su proxy' or 'su - proxy'? > > 'su - proxy' will give you a login shell with the full user > environment for user "proxy". > > 'su proxy' will leave you with the environment of the user prior to > the su, probably root. > > Run your test again after using 'su - proxy'. You can add the -d > switch to get the log messages written back to your screen. The format > would be: > '/where/ever/squidGuard -c /some/where/else/squidGuard.conf -d' > > Run 'which squidGuard' and make sure that the squidGuard binary is > really where you think it is. > > I went back through the archive and this problem has been mentioned > here 3 times in the last two and a half years. But there is never any > mention of what the exact problem turned out to be. We need to make > sure that we post the fix back to the list once it is discovered. > > Rick Matthews
