2016-06-15 14:24 GMT+03:00 reqman <reqman@xxxxxxxxxxx>: > 2016-06-15 13:48 GMT+03:00 Marcus Kool <marcus.kool@xxxxxxxxxxxxxxx>: >> >> >> On 06/15/2016 04:22 AM, reqman wrote: >>> >>> Hello all, >>> >>> I have been running squid 2.7.X alongside squidguard 1.4 on a FreeBSD >>> 8.x box for years. Started out some 10 years ago, with a much older >>> squid/squidguard/FreeBSD combination. >>> >>> Having to upgrade to FreeBSD 10.3, I examined my option regarding >>> squid. 3.5.19 was available which I assumed would behave the same as >>> 2.7, regarding compatibility. Squidguard 1.4 was also installed. >> >> >> A great decision to go to Squid 3.5.19, but it is a large leap so >> you might expect some compatibility issues. >> >> Squidguard has no support nor maintenance for many years and the patch >> for squidguard to become compatible with squid 3.4+ was written by a Squid >> developer. >> Hence I recommend to install ufdbGuard, which is a fork of squidGuard and >> does have support and updates. ufdbGuard is also 3x faster and uses less >> memory, so plenty of reasons to say goodbye to squidGuard. > > I have been using squidGuard for 10+ years. Not the best one could > have, but I am accustomed to its use and idiosyncrasies. Furthermore, > it is package well supported on FreeBSD. > > You are mentioning ufdbGuard. Are its lists free for government use? > If not, then I can not use it, since we have very strict purchasing > requirements, even if it costs $1. And of course, I would have to go > through evaluation, the usual learning curve etc. > > Don't get me wrong here, I'm not saying no. I'm just saying that even > though it seems to be easy to say "yes", reality is much different. > > M.- > Hi! I've made a freebsd port for ufdbGuard. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212044 I'd appreciate any kind of feedback. >> >> Marcus >> >> >>> - Squid was configured to behave along the lines of what I had on 2.7. >>> - For squidguard I used the exact same blocklists and configurations. >>> Note that I do not employ an URL rewriting in squidguard, only >>> redirection. >>> - no SSL-bump or other SSL interception takes place >>> - the squidguard-related lines on squid are the following: >>> >>> url_rewrite_program /usr/local/bin/squidGuard >>> url_rewrite_children 8 startup=4 idle=4 concurrency=0 >>> url_rewrite_access allow all >>> >>> - In squidGuard.conf, the typical redirect section is like: >>> >>> default { >>> pass local-ok !block1 !block2 !blockN all >>> redirect >>> >>> 301:http://localsite/block.htm?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u >>> } >>> >>> I am now experiencing problems that I did not have. Specifically, >>> access to certain but *not* all HTTPS sites seems to timeout. >>> Furthermore, I see entries similar to the following in cache.log: >>> >>> 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 >>> remote=192.168.2.239:3446 FD 591 flags=1 >>> 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 >>> remote=192.168.2.239:3448 FD 592 flags=1 >>> 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 >>> remote=192.168.2.239:3452 FD 594 flags=1 >>> 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 >>> remote=192.168.2.239:3456 FD 596 flags=1 >>> 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 >>> remote=192.168.2.239:3454 FD 595 flags=1 >>> 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 >>> remote=192.168.2.239:3458 FD 597 flags=1 >>> 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 >>> remote=192.168.2.239:3462 FD 599 flags=1 >>> >>> Searching around, the closest I have come to an answer is the >>> following: >>> http://www.squid-cache.org/mail-archive/squid-users/201211/0165.html >>> I am not sure though whether I am plagued by the same issue, >>> considering that the thread refers to a squid version dated 4 years >>> ago. And I definitely do not understand what the is meant by the >>> poster's proposal: >>> >>> "If you can't alter the re-writer to perform redirection you can work >>> around that by using: >>> >>> acl foo ... some test to match the re-written URL ... >>> deny_info 302:%s foo >>> adapted_http_access deny foo " >>> >>> Can someone help resolve this? Is the 2.7 series supported at all? As >>> is if everything fails, I'll have to go back to it if there's some >>> support. >>> >>> BR, >>> >>> >>> Michael.- >> >> >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
