On 20/02/2015 10:09 p.m., Odhiambo Washington wrote: > On 20 February 2015 at 04:15, Amos Jeffries <squ...@treenet.co.nz> wrote: > >> On 20/02/2015 5:15 a.m., Odhiambo Washington wrote: >>> On 19 February 2015 at 15:12, Odhiambo Washington <odhia...@gmail.com> >>> wrote: >>> >>>> Hi Amos, >>>> >>>> I did see that thread. However, the discussion was still continuing >> then. >>>> >>>> >>>> I will apply it to my server and see. >>>> >>>> Reporting back today! >>>> >>>> >>>> >>>> On 19 February 2015 at 14:07, Amos Jeffries <squ...@treenet.co.nz> >> wrote: >>>> >>>>> On 19/02/2015 10:49 p.m., Odhiambo Washington wrote: >>>>>> I have been hoping that 3.5.2 would possibly help address my problems >>>>> with >>>>>> ACLs, but alas! >>>>> >>>>> Ah, I thought you saw this announcement made just after your last >>>>> message in Jan: >>>>> >>>>> < >>>>> >> http://lists.squid-cache.org/pipermail/squid-users/2015-January/001745.html >>>>>> >>>>> >>>>> Its sounds very much like what your last few threads have been >>>>> describing as happening. Signal handling issues will affect all the >>>>> squid -k operations. >>>>> >>>>> Amos >>>>> >>>> >>> >>> I have compiled a custom kernel after applying this patch mentioned in >> that >>> thread. >> >> Er. There were two patches mentioned as being applied in the FreeBSD >> mail and bug reports. >> >>> >>> wash@mail:~$ uname -a >>> FreeBSD mail.ili.or.ug 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #4: Thu >> Feb >>> 19 16:55:56 EAT 2015 r...@mail.ili.or.ug:/usr/obj/usr/src/sys >>> /BEASTIE-10.x amd64 >>> >>> >>> However, my issues still persist. >>> >>> root@mail:/opt # /opt/squid-3.5.2/sbin/squid -k reconfigure >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL >>> >>> >>> Would this then suggest there is a problem with my squid.conf >>> <http://pastebin.com/wwwcnHnF> ? >>> >>> Or the FreeBSD problem isn't quite solved? >>> >> >> Could you re-state what the problem is? >> >> Now your pastebin is expired all we have on record about this problems >> is the sentence: "it's crashing with errors as seen from <DEAD URL>" >> > > > Generally, Squid seems to partially ignore my time-based ACLS as seen in > the squid.conf >
Oh. I thought you were talking about crashes still since you keep posting that -k reconfigure output (its odd, but only in that it should not be that visible). > It would block one site but allow the others. I expect a standard blocking > within the specied time. > > I have not been able to figure out why. > > For instance, my ACL for TIMEWASTAGESITED contains .facebook.com, .gmail.com > and .youtube.com as dstdomains. > > I find that youtube.com is blocked while facebook.com is not blocked. Both > should be blocked at this time (11:58) > > root@mail:/opt/squid-3.5.2/etc # tail -f /usr/local/squid/logs/access.log | > grep DENIED > 1424422669.545 456 192.168.2.2 TCP_DENIED/403 4345 GET > http://youtube.com/ - HIER_NONE/- text/html > 1424422671.910 1 192.168.2.2 TCP_DENIED/403 4291 GET > http://youtube.com/favicon.ico - HIER_NONE/- text/html > > root@mail:/opt/squid-3.5.2/etc # tail -f /usr/local/squid/logs/access.log | > grep 192.168.2.2 > 1424422669.545 456 192.168.2.2 TCP_DENIED/403 4345 GET > http://youtube.com/ - HIER_NONE/- text/html > 1424422671.910 1 192.168.2.2 TCP_DENIED/403 4291 GET > http://youtube.com/favicon.ico - HIER_NONE/- text/html > 1424422710.537 863 192.168.2.2 TCP_MISS/400 372 POST > http://bench.utorrent.com/e?i=36 - ORIGINAL_DST/54.221.228.66 text/html > 1424422710.578 903 192.168.2.2 TCP_MISS/400 372 POST > http://bench.utorrent.com/e?i=36 - ORIGINAL_DST/54.197.243.221 text/html > 1424422755.202 1239 192.168.2.2 TCP_MISS/200 280 POST > http://bench.utorrent.com/e?i=20 - ORIGINAL_DST/54.243.183.178 text/html > 1424422756.602 846 192.168.2.2 TCP_MISS/200 1016 GET > http://cdn.ap.bittorrent.com/control/feature/tags/ut.json - ORIGINAL_DST/ > 54.230.128. > 193 application/json > 1424422895.279 593 192.168.2.2 TCP_MISS/404 1792 GET > http://www.gstatic.com/chrome/profile_avatars/NothingToDownload - > ORIGINAL_DST/196.0 > .3.114 text/html > > > The odd part: > > While facebook.com and gmail.com are accessible, nothing appears at all in > the access.log and cache.log (debug mode) about them yet this is an > intercept proxy. The sites just load. No log enties:( The browser is maybe ... - not using the proxy for them at all (QUIC or WebSockets protocol), or - using a CONNECT tunnel which will only appear when its closed (HTTPS SPDY, HTTP/2), or - using a domain you dont have listed ("Google" services are actually *.1e100.net and "Facebook" is actually *.fbcdn.net). NP: If they are using SPDY or HTTP/2 within a CONNECT tunnel it may be used for a day or so without anything appearing in the log. Check your cachemgr active_requests report to see if there is CONNECT to facebook or gmail active. They may have been opened before your block period and stay open into it. Amos _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
