Re: [squid-users] cache_peer name gone from logs after upgrade to 3.5
On 29/09/2016 7:38 a.m., Daniel Sutcliffe wrote: > On Wed, Sep 28, 2016 at 1:56 PM, Yuri Voinovwrote: >>> 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
On Wed, Sep 28, 2016 at 1:56 PM, Yuri Voinovwrote: >> 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
On Wed, Sep 28, 2016 at 1:56 PM, Yuri Voinovwrote: > 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
-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
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 SutcliffeChair 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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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