[squid-users] Squid-3.5.2 and FreeBSD 10.1

[Amos Jeffries]

On 20/02/2015 10:09 p.m., Odhiambo Washington wrote:
> On 20 February 2015 at 04:15, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> 
>> On 20/02/2015 5:15 a.m., Odhiambo Washington wrote:
>>> On 19 February 2015 at 15:12, Odhiambo Washington <odhiambo at 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 <squid3 at 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 at 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     root at mail.ili.or.ug:/usr/obj/usr/src/sys
>>> /BEASTIE-10.x  amd64
>>>
>>>
>>> However, my issues still persist.
>>>
>>> root at 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 at 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 at 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