Re: [squid-users] cache_peer name gone from logs after upgrade to 3.5

2016-09-28 Thread Amos Jeffries
On 29/09/2016 7:38 a.m., Daniel Sutcliffe wrote:
> On Wed, Sep 28, 2016 at 1:56 PM, Yuri Voinov  wrote:
>>> It's tragedy, man.
>>>
>>> But 3.1 is too antique against 3.5 to remain unchanged.
> 
> On Wed, Sep 28, 2016 at 2:02 PM, Daniel Sutcliffe  wrote:
>> :) Thankfully, almost all of the changes are improvements
>>
>>> Also, do not expect good documentation from open source
> 
> Also, perhaps do not expect 100% reliable answers on open source
> mailing lists ;)
> 
> In the 3.1 logformat docs -
> http://www.squid-cache.org/Versions/v3/3.1/cfgman/logformat.html
> we have a default of:
>   logformat squid %ts.%03tu %6tr %>a %Ss/%03>Hs % Whereas in the 3.5 we have:
>   logformat squid %ts.%03tu %6tr %>a %Ss/%03>Hs % 
> This is new for 3.5
>And this changed from this:
>to this:
>
> I just needed to read a bit more - problem solved :)

As for the why:
 With many sites going IPv6-enabled we were getting a lot of complaints
and queries about why some requests would work and others not work, but
the log only have one name displayed for any access to the site(s). It
often turned out to be broken connections to just one IP of several.
With the new format one can see the broken IPs more clearly and identify
the issue without guessing.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] cache_peer name gone from logs after upgrade to 3.5

2016-09-28 Thread Daniel Sutcliffe
On Wed, Sep 28, 2016 at 1:56 PM, Yuri Voinov  wrote:
>> It's tragedy, man.
>>
>> But 3.1 is too antique against 3.5 to remain unchanged.

On Wed, Sep 28, 2016 at 2:02 PM, Daniel Sutcliffe  wrote:
> :) Thankfully, almost all of the changes are improvements
>
>> Also, do not expect good documentation from open source

Also, perhaps do not expect 100% reliable answers on open source
mailing lists ;)

In the 3.1 logformat docs -
http://www.squid-cache.org/Versions/v3/3.1/cfgman/logformat.html
we have a default of:
  logformat squid %ts.%03tu %6tr %>a %Ss/%03>Hs %a %Ss/%03>Hs %
Chair Four Development Group LLC
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] cache_peer name gone from logs after upgrade to 3.5

2016-09-28 Thread Daniel Sutcliffe
On Wed, Sep 28, 2016 at 1:56 PM, Yuri Voinov  wrote:
> It's tragedy, man.
>
> But 3.1 is too antique against 3.5 to remain unchanged.

:) Thankfully, almost all of the changes are improvements

> Also, do not expect good documentation from open source - you can always
> read sources yourself and know what's changed.

Very true - I just thought this mailing list might provide a quick
answer - and it did!

> Too sad. But this it.

Unless it bugs me enough to find the change and work out how I patch
back  the old behavior ;)

Cheers
/dan
-- 
Daniel Sutcliffe 
Chair Four Development Group LLC
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] cache_peer name gone from logs after upgrade to 3.5

2016-09-28 Thread Yuri Voinov

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
It's tragedy, man.

But 3.1 is too antique against 3.5 to remain unchanged.

Also, do not expect good documentation from open source - you can always
read sources yourself and know what's changed.

Too sad. But this it.

WBR, Yuri


28.09.2016 23:48, Daniel Sutcliffe пишет:
> I have been using squid 3.1 on EL6 for a long time and recently made
> the upgrade to 3.5 - all seems to be working as expected functionality
> wise, but I'm noticing a difference in the log file content which is
> not helping me doing a bit of peer debugging...
>
> In 3.1 the access.log used to contain a:
>   *_PARENT/
> What I'm now seeing is:
>   *_PARENT/
>
> Which wouldn't be so bad if all my  are the same, 127.0.0.1
> as they are all SSH tunnels.
>
> Otherwise the cache_peer name= directive seems to be doing its job as
> far as ACLs are concerned.
>
> Maybe this is now the expected behavior but I can't seem to find it
> documented anywhere - it would be nice if the old log behavior could
> be turned back on or I could have it confirmed that what I am seeing
> is just the way it is now.
>
> Cheers
> /dan

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJX7ARNAAoJENNXIZxhPexG2isIALrnOT/TVMd5Nhchf18HFs6b
zGoI3KjFD3hpIDrUAFhzFss5WhLc0f/rFwdkEQBpwTjJm8t3jHawoMxo3yDeHqzm
4O9qknEtq1sObI4nCuI9SxK0gXkIqynUKW1fOEWVHGD990H0aw7KiZ5p9T2Ro61q
upXOYP0aYiiaTT9bJTxl5l/gzNrU5yGi/NClpV1UbFt/O4MTTrRemZd8NmeP8J2u
6uqRarDaLEv62SDOdbc8xXEw5n+GLkUEVX12I9/oXvwrwrFGfQhPaSCqgsdvK/rW
cycS672NlRu/yTkqdsnPQ/nWtG744lM/OnMwy2I36i/qBAv7q9HBPc0nRpLoZMw=
=lKgO
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


[squid-users] cache_peer name gone from logs after upgrade to 3.5

2016-09-28 Thread Daniel Sutcliffe
I have been using squid 3.1 on EL6 for a long time and recently made
the upgrade to 3.5 - all seems to be working as expected functionality
wise, but I'm noticing a difference in the log file content which is
not helping me doing a bit of peer debugging...

In 3.1 the access.log used to contain a:
  *_PARENT/
What I'm now seeing is:
  *_PARENT/

Which wouldn't be so bad if all my  are the same, 127.0.0.1
as they are all SSH tunnels.

Otherwise the cache_peer name= directive seems to be doing its job as
far as ACLs are concerned.

Maybe this is now the expected behavior but I can't seem to find it
documented anywhere - it would be nice if the old log behavior could
be turned back on or I could have it confirmed that what I am seeing
is just the way it is now.

Cheers
/dan
-- 
Daniel Sutcliffe 
Chair Four Development Group LLC
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Errors in cache.log

2016-09-28 Thread erdosain9
Hi.
Another question  in reference to this topic off delay pools.
if i have "internet-limitation" (a group with 100kb for all webs) and i want
that users of that group have different youtube bandwith... is this
posible??

I need to do another group with the user of that group that i want they have
different bandwith for youtube? if i do that i will split
"internet-limitation" in "youtubegroup512kb", youtubegroup256kb... but... in
this way.. i have to give http_access for other groups to?? (youtube512/256)
or just because that users are in "internet-limitation"... It is not
necessary?

i think im completely wrong about this.. but i really dont know how
to do what i want.

Thanks.




--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Errors-in-cache-log-tp4679651p4679741.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] connections from particular users sometimes get stuck

2016-09-28 Thread Alex Rousskov
On 09/28/2016 09:41 AM, Antony Stone wrote:
> On Wednesday 28 September 2016 at 17:37:58, Alex Rousskov wrote:
> 
>> AFAICT, Squid did not receive a request for www.ru:
>>> $ egrep -c '.ru|217.112.35.75' cache.log.debug
>>> 0
>>>
>>> $ tshark -V -r squid-stuck-reference-client.pcap | egrep -c
>>> '.ru|217.112.35.75' 0
> 
> Is that a direct copy'n'paste from your terminal?
> 
> If so, you tried one too many w's :(

Indeed! Fixing that exposes one HTTP request in the capture file.
Unfortunately,

1. Squid responded to that request (with a 407 message).
   Follow (tcp.stream eq 32) in Wireshark.

2. Squid did not receive this request when debugging was on:
   $ egrep -c 'www.ru|217.112.35.75' cache.log.debug
   0

It may be important to know that the captured request was received at
minute 53 while Squid debugging starts at minute 58 (I assume the
difference in hours is due to time zone effects and such).

Another potentially important fact that it took almost two minutes for
the 407 response to show up in the capture. It is not clear (to me)
whether the delay was due to network problems (in one or both
directions) or due to Squid. Again, follow (tcp.stream eq 32) in
Wireshark to see the details.


The "I do not know which transaction got stuck and whether that
transaction go cache-logged" conclusion and suggestions in my original
response still apply AFAICT.


Thank you,

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] connections from particular users sometimes get stuck

2016-09-28 Thread Antony Stone
On Wednesday 28 September 2016 at 17:37:58, Alex Rousskov wrote:

> AFAICT, Squid did not receive a request for www.ru:
> > $ egrep -c '.ru|217.112.35.75' cache.log.debug
> > 0
> > 
> > $ tshark -V -r squid-stuck-reference-client.pcap | egrep -c
> > '.ru|217.112.35.75' 0

Is that a direct copy'n'paste from your terminal?

If so, you tried one too many w's :(


Antony.

-- 
"There has always been an underlying argument that we should open up our 
source code more broadly. The fact is that we are learning from open source 
and we are opening our code more broadly through Shared Source.

Is there value to providing source code? The answer is unequivocally yes."

 - Jason Matusow, head of Microsoft's Shared Source Program, in response to 
leaks of Windows source code on the Internet.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] connections from particular users sometimes get stuck

2016-09-28 Thread Alex Rousskov
On 09/28/2016 02:22 AM, Eugene M. Zheganin wrote:
> I took the debug trace and both the tcpdump client-side and server-side
> (towards the internet) capturea.
...
> I requested a http://www.ru/index.html from a client machine Chrome. 


AFAICT, Squid did not receive a request for www.ru:

> $ egrep -c '.ru|217.112.35.75' cache.log.debug 
> 0

> $ tshark -V -r squid-stuck-reference-client.pcap | egrep -c 
> '.ru|217.112.35.75'
> 0


If you find that request in your client-to-Squid packet captures, please
point me to it. Otherwise, please fix your captures and redo the test
from scratch.

Also, please include access.log and/or some other indication of which
transactions got stuck. You may want to stop captures _after_ you cancel
the stuck request -- it is more difficult to find "what has not
happened" (no answer for X seconds) than "what has happened" (e.g., a
TCP connection was reset). Keep in mind that, in general, the request
for the URL you type in the browser may succeed, but the browser may get
stuck getting some resource on that page.

You may limit captures to TCP and DNS traffic to and from Squid.

Finally, for the future, [if you cannot isolate the problem to one HTTP
transaction(*),] it is best to capture everything that Squid receives or
sends rather than trying to guess what the browser and Squid will
receive or send -- according to cache.log, there were lots of
Squid-server packets that your tcpdump configuration did not capture.


Thank you,

Alex.
P.S. (*) Entering a regular page URL in the browser usually results in
more than one HTTP transaction between the browser and Squid.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Kerberos Ne

2016-09-28 Thread Amos Jeffries
On 29/09/2016 3:02 a.m., erdosain9 wrote:
> Hi.
> Sorry for my ignorance, but, i have squid authentication with kerberos...
> 
> all is working fine...
> 
> but i have some behavior in cache.log that... i dont know if this is the
> expected, or there is some problem
> 
> because the file is going to be huge as put the squid in production ... this
> is appropriate behavior, or is warning of a problem?
> 
> this is just a little of "cache.log" and with just one user... so i think is
> a lot of info... this is ok?? 
> 

It's not clear what you are asking about exactly.

The amount of info the helper is dumping into cache.log is because you
have the helpers debug (-d) enabled in its auth_param program line. Once
you have the auth working you should turn that off of course (remove the
-d option).

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Kerberos Ne

2016-09-28 Thread Antony Stone
On Wednesday 28 September 2016 at 16:02:42, erdosain9 wrote:

> Hi.
> Sorry for my ignorance, but, i have squid authentication with kerberos...
> 
> all is working fine...
> 
> but i have some behavior in cache.log that... i dont know if this is the
> expected, or there is some problem
> 
> because the file is going to be huge as put the squid in production ...
> this is appropriate behavior, or is warning of a problem?

Please post here your current squid.conf without comments or blank lines.

Antony.

-- 
All matter in the Universe can be placed into one of two categories:

1. Things which need to be fixed.
2. Things which need to be fixed once you've had a few minutes to play with 
them.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


[squid-users] Kerberos Ne

2016-09-28 Thread erdosain9
Hi.
Sorry for my ignorance, but, i have squid authentication with kerberos...

all is working fine...

but i have some behavior in cache.log that... i dont know if this is the
expected, or there is some problem

because the file is going to be huge as put the squid in production ... this
is appropriate behavior, or is warning of a problem?

this is just a little of "cache.log" and with just one user... so i think is
a lot of info... this is ok?? 

2016/09/28 10:58:08 kid1| helperOpenServers: Starting 1/10
'negotiate_kerberos_auth' processes
negotiate_kerberos_auth.cc(487): pid=9723 :2016/09/28 10:58:08|
negotiate_kerberos_auth: INFO: Starting version 3.0.4sq
negotiate_kerberos_auth.cc(546): pid=9723 :2016/09/28 10:58:08|
negotiate_kerberos_auth: INFO: Setting keytab to /etc/squid/PROXY.keytab
negotiate_kerberos_auth.cc(570): pid=9723 :2016/09/28 10:58:08|
negotiate_kerberos_auth: INFO: Changed keytab to
MEMORY:negotiate_kerberos_auth_9723
negotiate_kerberos_auth.cc(610): pid=9723 :2016/09/28 10:58:08|
negotiate_kerberos_auth: DEBUG: Got 'YR
YIIGcQYGKwYBBQUCoIIGZTCCBmGgMDAuBgkqhkiC9xIBA
gIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBisEggYnYIIGIwYJKoZIhvcSAQICAQBuggYSMIIGDqADAgEFoQMCAQ6iBwMFACCjggSaYYIEljCCBJKgAwIBBaEUGxJFU1
BBQ0lPTUVNT1JJQS5MQU6iKzApoAMCAQKhIjAgGwRIVFRQGxhzcXVpZC5lc3BhY2lvbWVtb3JpYS5sYW6jggRGMIIEQqADAgESoQMCAQGiggQ0BIIEMKZf4kp8jYe6rqDiqZVclO1QD0fVSDYKdMt
teiw3I/nw0dvJwaQzgLbbs1hnhVfbKD77eKbQfJNBFcwcRr6bQRE/AySa+qOGZj3flRwxJgzcf6/wAMgfUNqU0qubkpH8BYhzd7q1KFI2t0vxAIZyj+O8Ot0HdKb3QH2ZC8EW5yCvGeYmLzkNBR4c
JLm6vLOAdwdqyHnBLuwjQyXrLEcEOS9CmBCF9AJMAr3Kmegicax2fzhzz2MgYE80O+aJ983ffVU2wFW1W1r766cEDYtxNT7CWVf1zRnAeOLpj7dSp3a5o3gMke0Y526zidlgkrEX2XCnMot2PnD9t
NNbcUwS1Hgp+Dkq7mJ6hsPTB0rDh/GGhS/yTTB0s/aT6++dq3CXl3glCy3bfax9UMnrHYSOrI8SVuPrva4SLgbTAcHPrmfWPbowf/ZOqGJ+94mOMdKzkhJIJcPz5KE5PiaOX/6N+hTGWc1mTzIzP3
V7/Wy8jWIPY+vBbE2hgykpgPCYEkVSz6KbuSiOx0TUEYG0d4hIvlwpx1VhSJoHU3/yStiodVpuSYiDr9UTrPe36c/hAd0G4IyTq/HC6JIicIf5joMsp6TKwp7q5+MQWLBNuQnXDl6bBrAw2sqvT96
mGkf4ZfowzWVgV8GeObZopIbMRYtG1C/NmgzK1ro9JiPDwsCS+bMs4rpNfiw7i+0LBGI5DTkWZwAhaZTZsbCXGSyeYnUkbKtuSLlczHCiAOyN4hQgXtXbL26rN4AqmF7rLlCgMlQPvxrVAjQ1cOqq
t9ZBxej/JzSrq5Xhifu0KqurZ5oZ8baNZJ/nBv2N5ntXpUli/9S5Qs4T5hR0khUdt2Vb9Hzx/pLRbF6Wo4iTCw1I7qH+QYVqDH2ZzlWC18ZVN1mPXLIsdii6edbNl/PY5o8htGfZnOOf8nlij3ZFl
CquzYKQNusQgN7RK/DcqJlxfE9CIoZyOPic5rC7nJ3Q55Bzx2+UTdS6JvNRVy+QmFMyUYpbDVF7VIZan6J2hf+2ND8+D5X3VhVhLYqQFPfmgJGeWUkcb/FGJoNPWTl5t3JSh6ASS2JzHwfChTwOwy
NXs2ej8s2IVYh8H6TLKdDiWmuhJZAyE5r8wnAgpIwgq+Jt1Cpj1wAToCJrXc6XZ77yA9NlD5iyz4Us2JsUBmXO1RpSXWBCev3il/TiL/+Ifu3ShrIeusUNDEMzsFjlhRuXuSKhzH9dolnKl8fSwKu
P4HyObuySUKP+4tCdOMZ/4VN1Rp8UCnrmbDcAvhPxpkoDx34KuXD4OYNtjwoJnyPMb1LUe0Z5K4ll0Ray66Ake/YjFuaWY/P7cTpwEe7TmfUNGghmB3iHxY1EQT9ySgBS0A+X5PBY/IkAgwG3teXUGIOx08g60Yme1Kq7nJcu1IQqUtCCNYN9s7Etcgbw9ecYbtz79rzT32KkggFZMIIBVaADAgESooIBTASCAUirSsLoI1x0RGwC84lXB4HADhLTlMA2gy7nx3J8DJmAoRLj9akJVJvoPhRqmxJdIs7vNZ1XbhZBcJ/84cz8yqiXOFMq9C3vvIAw57diqp6uDUd2yyQAMoB2WyAu/VIIvXkJ2v5iUu77VxTUNtV/VGmYM+SonXMWEFXi81VRPoVTIXySAFXRO7NF8rugf7TiAtB5SYHtC8EG0+jBV3ZBPeIAaDEWHWnHdDi4kQnWA5biuRf5FEP0elnxzEwh6Fzp/cTdrAMBLucbtjr1kInT5dwN0UePEGxtTzo7ajVCK/8uaHz1X2vPSKSSp/z5W3leoEtq3JMYQCn6RaERrQ1cjZ0+zVtWaWDu6KgIOcCo1jcY+SZ4ZFwox2BqdGkJJxi3AfW+1/MJBV9eA1YDV0cwZu77F+ymkB32z8d+jGvBFewGkDaKQX8GrQL6'
from squid (length: 2207).
negotiate_kerberos_auth.cc(663): pid=9723 :2016/09/28 10:58:08|
negotiate_kerberos_auth: DEBUG: Decode

Re: [squid-users] The Squid “Persona”- Squid 3.5.21+4.0.14 Release

2016-09-28 Thread Bruno de Paula Larini

Em 28/09/2016 08:39, Eliezer Croitoru escreveu:

Take a look at the page source to get the full article: 
http://www1.ngtech.co.il/wpe/?p=345

Who Is The Squid Girl Persona?
[Squid 
Persona|http://www1.ngtech.co.il/wpe/wp-content/uploads/2016/09/squid_girl__shinryaku__ika_musume__minimalism_by_greenmapple17-d8u9mum-768x432.png]

As a Squidder I know a girl or two but others are in the lookup for their Squid 
Girl Persona. Its’s not a simple task!!
To illustrate the idea: We as males used to the web with all sort of GET, POST, 
OPTIONS, PROFIND and all sort of normal methods.
But the Squid Girls is something else. She has brains!

[Artist of the Persona|http://www.deviantart.com/tag/squid_girl?offset=3]


Is she a kid or a squid?
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] The Squid “Persona”- Squid 3.5.21+4.0.14 Release

2016-09-28 Thread Yuri Voinov

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
It seems to me more important than the quality of the product debugging
instead invention mascot for it.


28.09.2016 17:43, Antony Stone пишет:
> On Wednesday 28 September 2016 at 13:39:04, Eliezer Croitoru wrote:
>
>> Take a look at the page source to get the full article:
>> http://www1.ngtech.co.il/wpe/?p=345
>
> If this is to be used as publicity material or a news item associated
with the
> Squid project, I humbly recommend that a native English speaker is
engaged to
> proofread and edit it.
>
> Regards,
>
> Antony.
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJX67yCAAoJENNXIZxhPexGbD4H/Apve4VU3ksfk8hYymmmi9bq
VVmVNjYIgWb5Q76H4nlU5hmDTAd2bUX7UgbtsCIpib/hlbk/0UQ8zglnt23z+pyT
WEdT7hIMRJMxz43biMzhAxMZdS/CsL+ipeqn+4jMPrPUL2LuYb3KScwE6+LsrMf5
jGML1rbrqBOZIkYJQLEbYQ0gSprmG9iiFJ41STc1a+cmPxk6RKViKB1gGchX7FKF
+PIKvqpVqy8V19lYvY5dR37gETpmXm/hID/CbrLRwu6DHovL20DoJyyA8c39vgjt
eqeKXgb1P0ahwy04P6VUPeZv+YWXT3GR5zPTgYHnnRnIeierOJHWnIP/4RRPKI8=
=xAA4
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] The Squid “Persona”- Squid 3.5.21+4.0.14 Release

2016-09-28 Thread Antony Stone
On Wednesday 28 September 2016 at 13:39:04, Eliezer Croitoru wrote:

> Take a look at the page source to get the full article:
> http://www1.ngtech.co.il/wpe/?p=345

If this is to be used as publicity material or a news item associated with the 
Squid project, I humbly recommend that a native English speaker is engaged to 
proofread and edit it.

Regards,

Antony.

-- 
3 logicians walk into a bar. The bartender asks "Do you all want a drink?"
The first logician says "I don't know."
The second logician says "I don't know."
The third logician says "Yes!"

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


[squid-users] The Squid “Persona”- Squid 3.5.21+4.0.14 Release

2016-09-28 Thread Eliezer Croitoru
Take a look at the page source to get the full article: 
http://www1.ngtech.co.il/wpe/?p=345

Who Is The Squid Girl Persona?
[Squid 
Persona|http://www1.ngtech.co.il/wpe/wp-content/uploads/2016/09/squid_girl__shinryaku__ika_musume__minimalism_by_greenmapple17-d8u9mum-768x432.png]

As a Squidder I know a girl or two but others are in the lookup for their Squid 
Girl Persona. Its’s not a simple task!!
To illustrate the idea: We as males used to the web with all sort of GET, POST, 
OPTIONS, PROFIND and all sort of normal methods.
But the Squid Girls is something else. She has brains!

[Artist of the Persona|http://www.deviantart.com/tag/squid_girl?offset=3]


Eliezer Croitoru

Eliezer Croitoru
Linux System Administrator
Mobile+WhatsApp: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: squid-announce [mailto:squid-announce-boun...@lists.squid-cache.org] On 
Behalf Of Amos Jeffries
Sent: Sunday, September 11, 2016 5:36 PM
To: squid-annou...@lists.squid-cache.org
Subject: [squid-announce] Squid 3.5.21 is available

The Squid HTTP Proxy team is very pleased to announce the availability of the 
Squid-3.5.21 release!


This release is a bug fix release resolving several issues found in the prior 
Squid releases.


The major changes to be aware of:


* Bug #4534: assertion failure in xcalloc when using many cache_dir

Squid is documented as supporting up to 64 cache directories, but would crash 
with a memory allocation error if more than a few were actually configured.


* Bug #4542: authentication credentials IP TTL updated incorrectly

This bug caused error in max_user_ip ACL accounting to allow clients to shift 
IP address more times than configured. This bug fix may have an effect on IPv6 
clients using "proviacy adressing" to rotate IPs.


* Bug #4428: mal-formed Cache-Control:stale-if-error header

This bug shows up as incorrect stale-if-error values being relayed by Squid 
breaking the use of this feature in the recipients. Squid now relays the header 
values correctly.


* Bug #3025: Proxy-Authenticate problem using ICAP server

With this change Squid now treats the ICAP REQMOD adaptation point as a part of 
itself with regards to proxy authentication. The Proxy-Authentication header 
received from the client is delivered as part of the HTTP request headers in 
expectation that the ICAP service may authenticate and/or produce 407 response 
itself.

Note that use of stateful or connection-oriented authentication schemes is not 
possible. HTTP is designed to operate in a stateless way and any deviation from 
that design requires Squid to perform special message processing.


* HTTP: MUST always revalidate Cache-Control:no-cache responses.

This bug shows up as Squid not revalidating some responses until they became 
stale according to refresh_pattern heuristic rules (specifically the minimum 
caching age). Squid now revalidates these objects on every request.


* HTTP: do not allow Proxy-Connection to override Connection header

The Proxy-Connection: header is a long-deprecated experimental header.
For the past decade Squid has been actively stripping it out of relayed 
traffic. This release continues the removal process by also preventing it from 
having any effect on Squid client connection persistence when a
Connection: header is present.


* SSL CN wildcard must only match a single domain component [fragment].

This bug shows up as incorrect matching (or non-matching) of the 
ss::server_name ACL against TLS certificate values. Squid now treats the 
certificate CN fields according to X.509 domain matching requirements instead 
of HTTP domain matching requirements.



 All users of Squid-3 are encouraged to upgrade to this release as soon as 
possible.


 See the ChangeLog for the full list of changes in this and earlier  releases.

Please refer to the release notes at
http://www.squid-cache.org/Versions/v3/3.5/RELEASENOTES.html
when you are ready to make the switch to Squid-3.5

Upgrade tip:
  "squid -k parse" is starting to display even more
   useful hints about squid.conf changes.

This new release can be downloaded from our HTTP or FTP servers

 http://www.squid-cache.org/Versions/v3/3.5/
 ftp://ftp.squid-cache.org/pub/squid/
 ftp://ftp.squid-cache.org/pub/archive/3.5/

or the mirrors. For a list of mirror sites see

 http://www.squid-cache.org/Download/http-mirrors.html
 http://www.squid-cache.org/Download/mirrors.html

If you encounter any issues with this release please file a bug report.
http://bugs.squid-cache.org/


Amos Jeffries

___
squid-announce mailing list
squid-annou...@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-announce

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


[squid-users] Caching application/octet-stream

2016-09-28 Thread Michael Varun
Team -

Would like to know is there any specific config that we need to enable to
cache MIME attachement of application/octet-stream type

We are trying to caching docker image blobs which is of
application/octet-stream  and everytime we hit the docker registry via)GET
call squid throws up TCP_MISS/200  I had never got a CACHE HIT or MEM HIT
for these contents. Can someone show pointers to how to succeed in cache
hit


Logs

1475056789.667  0 10.0.0.160 TAG_NONE/200 0 CONNECT :443 - HIER_NONE/- -
1475056789.706   1633 10.0.0.160 TCP_MISS/200 1114 GET https://docker
registry/v2/blobs/sha256:36e0da2b6e166c5e7b1f243e9257590d4fbd1be729773df7f3d6a779941b22d9
- FIRSTUP_PARENT/IP.xx.xx.xxapplication/octet-stream
1475056789.708  0 10.0.0.160 TAG_NONE/200 0 CONNECT 443 - HIER_NONE/- -
1475056791.259   1545 10.0.0.160 TCP_MISS/200 1698 GET https://docker
registry/v2/blobs/sha256:2a00f8fcea92b16de0de328c557da476e930aa038ccee482daf91a62de5afa33
- FIRSTUP_PARENT/IP.xx.xx.xx application/octet-stream


Configuration
=
http_port docker registry:443 ssl-bump cert=/etc/ssl/private/docker
registry.certkey=/etc/ssl/private/docker registry.key
maximum_object_size 8 GB
maximum_object_size_in_memory 102400 KB
quick_abort_min -1
cache_dir ufs /data/squid/cache/squid 204800 16 256
cache_mem 51200 MB
cache allow all
cache_peer docker registry parent 443 0 no-query originserver no-digest
name=upstream ssl sslflags=DONT_VERIFY_PEER
never_direct allow all
#
acl site dstdomain /etc/mirror-dstdomain.acl
acl site1 dstdomain docker-registry.xx.xx
http_access allow site
http_access allow site1
cache_peer_access upstream allow site1
cache_peer_access upstream deny all
ssl_bump bump site1
ssl_bump splice all
sslproxy_flags DONT_VERIFY_PEER

-- 
_
The information contained in this communication is intended solely for the 
use of the individual or entity to whom it is addressed and others 
authorized to receive it. It may contain confidential or legally privileged 
information. If you are not the intended recipient you are hereby notified 
that any disclosure, copying, distribution or taking any action in reliance 
on the contents of this information is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify 
us immediately by responding to this email and then delete it from your 
system. The firm is neither liable for the proper and complete transmission 
of the information contained in this communication nor for any delay in its 
receipt.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


[squid-users] R: Re: R: Re: problem reload configuration with workers

2016-09-28 Thread ama...@tin.it
Hi Alex

I have used like reference the example backend.conf in 
/ConfigExamples/SmpCarpCluster

Every swap.state is updated so I 
suppose that it's working.

Mau
Messaggio originale
Da: 
rouss...@measurement-factory.com
Data: 27-set-2016 17.38
A: 
Cc: "ama...@tin.it"
Ogg: 
Re: R: Re: [squid-users] problem reload configuration with workers

On 
09/27/2016 03:15 AM, ama...@tin.it wrote:
> I have resolve my problem 
changing the workers configuration from:
> 
> workers 4
> http_access 
allow localhost
> http_port localhost:
> 400${process_number}
> 
cache_dir aufs /var/spool/squid 16384 32 512
> 
> cache_dir rock 
/var/spool/squid/rock 16384 max-size=32768
> cache_dir aufs 
/var/spool/squid/squid-cache0${process_number} 16384 16 512 min-
size=32769

The above combination of SMP-aware and SMP-unaware caches 
is unsupported
and probably will not work.


> to
> 
> workers 4
> 
http_access allow localhost
> http_port 
> localhost:
400${process_number}
> cache_dir rock /var/spool/squid/rock 16384 max-
size=32768
> 
> if ${process_number} = 1
> cache_dir aufs 
/var/spool/squid/squid-cache01 16384 16 512 min-size=32769
> endif
> 
if 
> ${process_number} = 2
> cache_dir aufs 
/var/spool/squid/squid-cache02 16384 16 512 min-size=32769
> endif
> if 
${process_number} = 3 
> cache_dir aufs /var/spool/squid/squid-
cache03 16384 16 512 min-size=32769
> endif
> if ${process_number} = 4

> cache_dir aufs /var/spool/squid/squid-cache04 16384 16 512 
min-size=32769
> endif

The above is equivalent to

  workers 4
  
http_access allow localhost
  http_port
  localhost:
400${process_number}
  cache_dir rock /var/spool/squid/rock 16384 max-
size=32768
  cache_dir aufs /var/spool/squid/squid-
cache${process_number} 16384 ...

which is still an unsupported 
combination of SMP-aware and SMP-unaware
caches that probably will not 
work.

BTW, why do you give each worker a dedicated listening port (i.
e.,
"400${process_number}")?

Alex.


> Messaggio originale
> 
Da: rousskov@measurement-factory.
> com
> Data: 26-set-2016 16.12
> A: 

> Cc: 
> "ama...@tin.it"
> Ogg: Re: [squid-users] problem reload 
> configuration with 
workers
> 
> On 09/26/2016 08:02 AM, ama...@tin.it 
> wrote:
> 
>> I'm 
using squid 3.5.21-20160908-r14081 and for the first time 
> I'm 
>> 
using workers configuration. I have a problem:
>> when I reload 
> 
configuration (via init script)
>> suid -k reconfigure -f 
> 
/et/squid/squid.conf
> 
> I assume that by "suid" you meant "squid". 
If 
> yes, then the above
> command is a correct way to reconfigure 
Squid, 
> including SMP Squid.
> 
> 
>> the system kill squid-coord and 
squid-disk
> 
> 
> Does "the system" do more than run "squid -k 
reconfigure ..."?
> 
> * If 
> not, then "the system" does not kill 
squid-coord and squid-disk
> 
> (something else does).
> 
> * If yes, 
then you should fix your system 
> script. Perhaps it thinks that
> 
Squid died and tries to kill/restart it?
> 
> 
> 
>> So I have to 
remove pd 
>> file and lock files and restart squid.
>>
> Please, do it 
exist a solution 
>> to reload with restart squid?
> 
> 
> 
Reconfiguration should work "as is". If it does not work, file a bug
> 

> report with details such as your system command(s) and resulting
> 
cache.
> log and syslog output.
> 
> 
>> I tried also using something 
like:
>>
>>
> pid_filename /var/run/squid/squid-{proccess_number}.
> 
> 
Please do not do 
> that. SMP Squid is designed to work with a single
> 
configuration file 
> without SMP macros.
> 
> 
> Thank you,
> 
> Alex.

> 
> 
> 




___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] connections from particular users sometimes get stuck

2016-09-28 Thread Eugene M. Zheganin
Hi.

On 28.09.2016 01:36, Alex Rousskov wrote:
> On 09/27/2016 02:02 PM, Eugene M. Zheganin wrote:
>
>> I guess squid
>> didn't get a way to increase debug level on the fly ? 
> "squid -k debug" (or sending an equivalent signal) does that:
> http://wiki.squid-cache.org/SquidFaq/BugReporting#Detailed_Debug_Output
>
> You will not get ALL,9 this way, unfortunately, but ALL,7 might be enough.
>
>
I took the debug trace and both the tcpdump client-side and server-side
(towards the internet) capturea.
Since the debug log is way heavy, I decided to put all of the three
files on the web-server. Here they are:

Squid debug log (ALL,7):

http://zhegan.in/files/squid/cache.log.debug

tcpdump client-side capture (windump -s 0 -w
squid-stuck-reference-client.pcap -ni 1):

http://zhegan.in/files/squid/squid-stuck-reference-client.pcap

tcpdump server-side capture, towards the outer world, empty - obviously,
server didn't send anything outside (tcpdump -s 0 -w
squid-stuck-reference-server.pcap -ni vlan23 host 217.112.35.75):

http://zhegan.in/files/squid/squid-stuck-reference-server.pcap

Test sequence:

client - 192.168.3.215
squid - 192.168.3.1:3128
URL - http://www.ru/index.html

I requested a http://www.ru/index.html from a client machine Chrome. No
other applications were requesting this URL at this time there (however,
capture does contain a lot of traffic, including HTTP sessions). Then I
waited about a minute (loader in Chrome was spinning), and aborted both
captures, then aborted the request. The aborted request probably made it
to the squid log.

Eugene.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users