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.
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
