# uname -a Linux zelva 2.6.31.5-127.fc12.i686.PAE #1 SMP Sat Nov 7 21:25:57 EST 2009 i686 i686 i386 GNU/Linux # cat /etc/redhat-release Fedora release 12 (Constantine) # rpm -qa | grep squid squid-3.1.0.14-1.fc12.i686 squidGuard-1.4-8.fc12.i686 I am unable to start squidGuard. There's a good chance this is user error, since I know very little about squidGuard or squid. Here are steps I took. yum install squidGuard create /etc/squid/squidGuard.conf (attached) chkconfig --level 2345 squid on chkconfig --level 2345 squidGuard on chkconfig --level 2345 transparent-proxying on service squid start service squidGuard start ...it failed looked at the rc script to see what the command is and noticed the config file should be /etc/squid/squid-squidGuard.conf, created an appropriate symlink with this other name and tried again, it still failed tried the command from the command line # squid -D -f /etc/squid/squid-squidGuard.conf it failed with the attached output The errors indicate that the squid attempting to parse the config file doesn't know those directives. So maybe I have the wrong squid version? Using the obsoleted -D option also indicates that. While I didn't expect it to help I noticed that the /var/squidGuard/blacklists.tar.gz was still compressed. So I expanded it and also ran 'squidGuard -C all' (which required me to create some empty urls files and the local-* dirs with empty domains and urls files to complete). It didn't help.
Created attachment 372899 [details] squid-squidGuard.conf
Created attachment 372900 [details] squidGuard.errors
I'm a bit new to it as well, I just took it over awhile back. I'm a bit confused, I'm not sure why this program needs an init script, and it doesn't work, anyway. Instead of using it, try the bit at the bottom of this page: http://squidguard.org/Doc/verify.html And restart squid. See what happens. If that works, I may rip out the init script. From what I can see, it just tries to start squid, but with the squidGuard config file, not the squid one, and yet requires that squid already be running. From my understanding based on the docs, it doesn't run as a daemon, it's called by squid.
I got a chance to try this today. The instructions from your link made me think it was going to work. 1) chown -R squid:squid /var/squidGuard 2) try dry-run for both my uid and uid of kid for a bad web page, it redirected for kid's uid. 3) add following line to /etc/squid/squid.conf url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf 4) chkconfig --level 2345 squidGuard off service squidGuard off service squid restart ps -ef | grep squid root 1357 1 0 11:27 ? 00:00:00 squid -f /etc/squid/squid.conf squid 1359 1357 0 11:27 ? 00:00:02 (squid) -f /etc/squid/squid.conf squid 1366 1359 0 11:27 ? 00:00:00 (unlinkd) squid 2086 1359 0 11:27 ? 00:00:00 (squidGuard) -c /etc/squid/squidGuard.conf squid 2087 1359 0 11:27 ? 00:00:00 (squidGuard) -c /etc/squid/squidGuard.conf squid 2088 1359 0 11:27 ? 00:00:00 (squidGuard) -c /etc/squid/squidGuard.conf squid 2089 1359 0 11:27 ? 00:00:00 (squidGuard) -c /etc/squid/squidGuard.conf squid 2090 1359 0 11:27 ? 00:00:00 (squidGuard) -c /etc/squid/squidGuard.conf But then I tried a web page with firefox, and it didn't redirect for the kid. transparent-proxying looks ok to me... # iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination REDIRECT tcp -- anywhere anywhere tcp dpt:http redir ports 3128 I saw errors in /var/log/squid/cache.log like (squidGuard): can't write to logfile /var/log/squidGuard/... so I also did chown -R squid:squid /var/log/squidGuard. It made everything look happy as far as the logs go, but still no redirecting. Maybe we need more modifications to squid.conf? I'll try to add some logging in iptables and squid to see if we're redirecting to squid at all.
Hmm... it seems I have two problems. 1) The transparent proxy doesn't appear to be working (nothing shows up in /var/log/squid/access.log when I use http). I've added a couple more rules to try and log it, as well as get it to work, with no luck. Not logs and not working. Chain PREROUTING (policy ACCEPT 1 packets, 328 bytes) pkts bytes target prot opt in out source destination 0 0 LOG tcp -- eth1 any anywhere anywhere tcp dpt:http LOG level debug prefix `http request' 0 0 DNAT tcp -- any any anywhere anywhere tcp dpt:http to:192.168.1.102:3128 0 0 REDIRECT tcp -- any any anywhere anywhere tcp dpt:http redir ports 3128 2) squid doesn't accept my connections. If I just manually set the proxy to localhost:3128 or use squidclient to test the proxy, then I get TCP_DENIED in /var/log/squid/access.log. This doesn't make sense to me since I have localhost and localnet (192.168.0.0/16) allowed in the squid.conf. This is frustrating because everything _appears_ to be configured correctly. Can someone else try to use this package and see if they get better luck than me?
Hmm. Unfortunately I don't have a working Squid I can test with currently. Are you getting any SELinux denials, out of curiosity? (find /var/log/ | xargs grep -i avc)
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.