[squid-users] Re: Kerberos with 2008/2003 DC
A lot of thanks Markus and sorry by my big delay in answering but I didn't
know suficient for reply you.
I read a lot of posts and I checked my configuration and I think that now I
can reply you.
My configuration
[logging]
default = FILE:/var/log/krb/krb5libs.log
kdc = FILE:/var/log/krb/krb5kdc.log
admin_server = FILE:/var/log/krb/kadmind.log
[libdefaults]
default_realm = ABG.CORP
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
[realms]
ABG.CORP = {
default_domain = abg.corp
kdc = XXX.abg.corp:88
kdc = XXX.abg.corp:88
admin_server = X.abg.corp:749
}
[domain_realm]
.abg.corp = ABG.CORP
abg.corp = ABG.CORP
-rw-r-1 root squid75 may 6 12:23 squid_w2008.keytab
kinit work properly for kdc and admin_server with 2003 and 2008
[root@proxyprueba ~]# kinit -V -kt /etc/squid/squid_w2008.keytab
HTTP/proxyprueba.abg.corp
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/proxyprueba.abg.c...@abg.corp
Using keytab: /etc/squid/squid_w2008.keytab
Authenticated to Kerberos v5
and y view the ticket
[root@proxyprueba ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/proxyprueba.abg.c...@abg.corp
Valid starting ExpiresService principal
05/07/13 09:32:53 05/07/13 19:33:15 krbtgt/abg.c...@abg.corp
renew until 05/08/13 09:32:53
All DNS resolution are good
direct -- proxyprueba.abg.corp.3600IN A 10.155.196.29
reverse -- 29.196.155.10.in-addr.arpa. 3600 INPTR
proxyprueba.abg.corp.
with DC is the same.
I configure the client (Windows XP and IE8) with the proxy name and port
8080. If I don't put autentication the client has internet if I put
authentication this doesn't have internet.
I list in the client, with kerbtray, all tickets and never view
HTTP/proxyprueba.abg.c...@abg.corp. I capture the traffic betewn
with DC is the same.
I configured the client (Windows XP and IE8) with the proxy name and port
8080, with proxypack (url). If I don't put autentication the client has
internet if I put authentication this doesn't have internet.
I list in the client, with kerbtray, all tickets and never view
HTTP/proxyprueba.abg.c...@abg.corp. I capture the traffic between proxy and
client and only view this
Hypertext Transfer Protocol
HTTP/1.0 407 Proxy Authentication Required\r\n
[Expert Info (Chat/Sequence): HTTP/1.0 407 Proxy Authentication
Required\r\n]
[Message: HTTP/1.0 407 Proxy Authentication Required\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.0
Status Code: 407
Response Phrase: Proxy Authentication Required
Server: squid/3.1.10\r\n
Mime-Version: 1.0\r\n
Date: Tue, 07 May 2013 06:53:18 GMT\r\n
Content-Type: text/html\r\n
Content-Length: 3931\r\n
[Content length: 3931]
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0\r\n
Vary: Accept-Language\r\n
Content-Language: es\r\n
Proxy-Authenticate: Negotiate\r\n
X-Cache: MISS from proxyprueba.abg.corp\r\n
X-Cache-Lookup: NONE from proxyprueba.abg.corp:8080\r\n
Via: 1.0 proxyprueba.abg.corp (squid/3.1.10)\r\n
Connection: keep-alive\r\n
After NTML requirement
Can you help me? Now, I think that all is correct.
A lot of thanks.
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Kerberos-with-2008-2003-DC-tp4659198p4659821.html
Sent from the Squid - Users mailing list archive at Nabble.com.
RE: [squid-users] multiple logfile-daemon logging to same logfile
Thanks for the hint - we already have got quite an elaborate db-logging mechanism which reads from the logfiles (as in 3.0 squid did only allow logging to file). And as we need to go live soon, I want to avoid starting with a last-minute changes to the logging... So I will have to redesign the logging for now to just log to a single file and maybe modify later... Thanks, Martin -Original Message- From: Amos Jeffries [mailto:squ...@treenet.co.nz] Sent: Dienstag, 07. Mai 2013 05:15 To: squid-users@squid-cache.org Subject: Re: [squid-users] multiple logfile-daemon logging to same logfile On 6/05/2013 9:56 p.m., Martin Sperl wrote: Hi! I need to be logging slightly different access-log pattern to the same logfile (logging different headers depending on host accessed). Looks essentially like this access_log daemon:/logfile LOGPATTERN_1 ACL_SELECTOR_1 access_log daemon:/logfile LOGPATTERN_2 ACL_SELECTOR_2 access_log daemon:/logfile LOGPATTERN_OTHER all This config produces 3 different logfile-daemon processes that all log to the same logfile. Is there a means to get only one of those logfile-daemon(s) for a single file and retain the capability to log different headers? Is there a risk (line corruption where 2 different lines from different daemons get merged into a single line,.) running these daemons in parallel? The file daemon helper bundled with Squid cannot do this safely AFAIK, it was written to be the sole writer to each log file. You will need to either patch it to append to the file and perform locking+write+unlock. Or write a different helper which can receive log lines containing both your headers on all requests and filter them into the file. The purpose of log daemons is to offload all this filtering and management from Squid after all. Alternatively, it would be much easier to use a UDP, syslog, or TCP outputs to send two streams of log line packets to one logging backend. Alternatively, using a database backend instead of file. The DB log daemon helper in 3.3+ can do what you want. Amos This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
Re: [squid-users] Squid 3.3.4 is available
Hi Amos, This patch (to 3.3.2) is still missing (which you had sent for wrong logging of IPv6 address instead of IPv4) --- squid-3.3.2/src/forward.cc 2013-02-25 03:42:35 + +++ squid-3.3.2/src/forward.cc 2013-03-07 07:38:16 + @@ -984,6 +984,7 @@ serverConn-peerType = HIER_DIRECT; #endif ++n_tries; + request-hier.note(serverConn, request-GetHost()); request-flags.pinned = 1; if (pinned_connection-pinnedAuth()) request-flags.auth = 1; Regards Amm. From: Amos Jeffries squ...@treenet.co.nz To: squid-users@squid-cache.org squid-users@squid-cache.org Sent: Saturday, 27 April 2013 7:40 PM Subject: [squid-users] Squid 3.3.4 is available The Squid HTTP Proxy team is very pleased to announce the availability of the Squid-3.3.4 release! ... Amos Jeffries
[squid-users] Re: Kerberos with 2008/2003 DC
More info [root@proxyprueba ~]# /usr/lib64/squid/squid_kerb_auth_test -d -s HTTP/proxyprueba.abg.c...@abg.corp Token: YIIFdgYGKwYBBQUCoIIFajCCBWagCjAIBgYrBgEFAgWiggVWBIIFUmCCBU4GBisGAQUCBQUBMAyhCgQIQUJHLkNPUlBsggUyMIIFLqEDAgEFogMCAQyjggTOMIIEyjCCBMahAwIBAaKCBL0EggS5boIEtTCCBLGgAwIBBaEDAgEOogcDBQAAo4ID3WGCA9kwggPVoAMCAQWhChsIQUJHLkNPUlCiHTAboAMCAQKhFDASGwZrcmJ0Z3QbCEFCRy5DT1JQo4IDoTCCA52gAwIBF6EDAgEEooIDjwSCA4sGgXVsIjPSTSSmj9i48NRBrRlek80LnsvtboVotiMg/et+gKgMGoW3Y+Psu+aLb0c4v9vSNZiFUHy19oN/5EwUwxYt/jioQwz4mV8e3/Vp0emeJKjkXKhoB/nezZqULDWiOtU9Lu3ourIcOKXEB5IMGI1XyaBnsO7yf5RPPGNCy4mehGrLM8Rjh7QWPVWzCVYs+RdPF74C8NrbXVkehL9ZS1d81cF0nbhIYF5NiabPyZx65K7ZdhXZi8NtdWUYBUrS1m9lUmRmCGov66s/gpbEVZ5cy9avfNp5UCHy55X/u/lqkxMrOd6fJs8uwisBdzpmYwc5BpFMUfTb9+2h5Xtr9NYnxctl0cYYYqw9KsFg3os+Kgzru0J0ROb1U0kisi1euQ4eXXC+81RRA6liZJfDPjblFoFtsLYNEShIu2LwGrcpLjeRDhzRs6vfKTJsBO35cTuSbnjxLz2m8hpYQQA5iUrJbZp66r http://squid-web-proxy-cache.1019090.n4.nabble.com/file/n4659824/2.png http://squid-web-proxy-cache.1019090.n4.nabble.com/file/n4659824/user.png Thanks -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Kerberos-with-2008-2003-DC-tp4659198p4659824.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] logging issues
Hi all, I'm having a problem with filtering user access specifically with Google (Mail, docs, calendars etc) - it looks to me like not all the requests the client makes are showing up in squid access log. As far as I can tell, AJAX requests aren't logged, and I know google are big AJAX fans, so I reckon this is the first place to look - is there any way of telling squid to log AJAX requests in the access.log file? thanks in advance, Jim UK
Re: [squid-users] logging issues
Hi, Google services use the HTTPS port, your SQUID is configured to listen on that port? 2013/5/7 Mr J Potter jpotter...@because.org.uk: Hi all, I'm having a problem with filtering user access specifically with Google (Mail, docs, calendars etc) - it looks to me like not all the requests the client makes are showing up in squid access log. As far as I can tell, AJAX requests aren't logged, and I know google are big AJAX fans, so I reckon this is the first place to look - is there any way of telling squid to log AJAX requests in the access.log file? thanks in advance, Jim UK -- Saludos, Pablo R Maldonado
[squid-users] 3.3.4 compilation error on Solaris 10
Compiling version 3.3.4 on Solaris 10 using Solaris Studio 12.3, I get the following error: ... Making all in format source='Config.cc' object='Config.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../cfgaux/depcomp \ /bin/bash ../../libtool --tag=CXX--mode=compile CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl-errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c -o Config.lo Config.cc libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Config.cc -KPIC -DPIC -o .libs/Config.o libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Config.cc -o Config.o /dev/null 21 source='Format.cc' object='Format.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../cfgaux/depcomp \ /bin/bash ../../libtool --tag=CXX--mode=compile CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl-errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c -o Format.lo Format.cc libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Format.cc -KPIC -DPIC -o .libs/Format.o Format.cc, line 82: Error, wvarhidemem: name hides Format::Format::name. Format.cc, line 87: Error, wvarhidemem: format hides Format::Format::format. 2 Error(s) detected. *** Error code 1 Configuration parameters are: ./configure --prefix=/usr/local/squid --with-logdir=/var/log/squid --without-krb5-config Is this just caused by the strictness of the compiler and if so is there an option to override it during the make? Thanks -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/3-3-4-compilation-error-on-Solaris-10-tp4659827.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] CONNECT acl protocol
Hi, I've some squid servers (until 3.1.20 version) which has the following configuration and works great: acl allowed_protocols proto HTTP HTTPS CONNECT FTP http_access deny !allowed_protocols After the upgrade to 3.3.3 version, sqiud print the following warning in the configuration check: WARNING: Ignoring unknown protocol 'CONNECT' in the ACL named 'allowed_protocols' and squid clients can't no more connect to HTTPS sites. How can I check the protocols like configuration in old versions?-- -- Davide Belloni
Re: [squid-users] 3.3.4 compilation error on Solaris 10
Use Solaris gcc (compiling with studio no longer works after version 2.7). Le mar. 07/05/2013 à 15:08, drewB a écrit : Compiling version 3.3.4 on Solaris 10 using Solaris Studio 12.3, I get the following error: ... Making all in format source='Config.cc' object='Config.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../cfgaux/depcomp \ /bin/bash ../../libtool --tag=CXX--mode=compile CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl-errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c -o Config.lo Config.cc libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Config.cc -KPIC -DPIC -o .libs/Config.o libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Config.cc -o Config.o /dev/null 21 source='Format.cc' object='Format.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../cfgaux/depcomp \ /bin/bash ../../libtool --tag=CXX--mode=compile CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl-errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c -o Format.lo Format.cc libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Format.cc -KPIC -DPIC -o .libs/Format.o Format.cc, line 82: Error, wvarhidemem: name hides Format::Format::name. Format.cc, line 87: Error, wvarhidemem: format hides Format::Format::format. 2 Error(s) detected. *** Error code 1 Configuration parameters are: ./configure --prefix=/usr/local/squid --with-logdir=/var/log/squid --without-krb5-config Is this just caused by the strictness of the compiler and if so is there an option to override it during the make? Thanks -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/3-3-4-compilation-error-on-Solaris-10-tp4659827.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] logging of headers after request modification
Hi!
I have configured squid 3.2.7 logging with the following pattern to log:
logformat xml ...Via%{Via}ha/Via...
access_log daemon:/var/logs/squid/access_log.xml xml all
But I have the problem, that the VIA fields stay empty (actually -)...
So I wonder why and how I can change that, so that I get the Via header as
well...
Thanks,
Martin
P.s: I am modifying the VIA header in my config like this under some
circumstances:
request_header_access Via allow CUSTOM_ACL
request_header_access Via deny all
request_header_replace Via mypersonalvalue
The application sees the expected value in the Via header, so that itself is
not an issue - only logging the header is NOT working as expected...
(it actually only works IF
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Re: [squid-users] 3.3.4 compilation error on Solaris 10
On 8/05/2013 1:32 a.m., C. Pelissier wrote: Use Solaris gcc (compiling with studio no longer works after version 2.7). It should. We had 3.1 building with Studio before the public build farm we were using to maintain the portability got discontinued. Now we are back once again reliant on people actually reporting problems and those with access to the compiler testing fixes. If either of you are interested in helping out please run Studio over the latest 3.HEAD code and report any build errors [and warnings] that are occuring still to bugzilla (bugs.squid-cache.org). If you are able to provide a patch as well that would be a great help, but simply being aware of the problems is the most important step. FWIW: the problem below is shadowed variables -Wshadow error check added in 3.3. That and several dozens of other shadowed variables have been fixed in the 3.HEAD bundles, but are still present in 3.3 and older series of releases. You may be able to get it to build with ./configure --disable-strict-error-checking. If you get it to build can you please provide some feedback on this bug: http://bugs.squid-cache.org/show_bug.cgi?id=3764. The MacOS and Windows people provided some fixes for 3.2+ which should mean its no longer relevant on Solaris (or may need only small tweaking to work). HTH Amos Le mar. 07/05/2013 à 15:08, drewB a écrit : Compiling version 3.3.4 on Solaris 10 using Solaris Studio 12.3, I get the following error: ... Making all in format source='Config.cc' object='Config.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../cfgaux/depcomp \ /bin/bash ../../libtool --tag=CXX--mode=compile CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl-errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c -o Config.lo Config.cc libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Config.cc -KPIC -DPIC -o .libs/Config.o libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Config.cc -o Config.o /dev/null 21 source='Format.cc' object='Format.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../cfgaux/depcomp \ /bin/bash ../../libtool --tag=CXX--mode=compile CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl-errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c -o Format.lo Format.cc libtool: compile: CC -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I../../libltdl -errwarn=%all,no%badargtype2w,no%wbadinit,no%wbadasg -errtags -D_REENTRANT -lpthread -g -c Format.cc -KPIC -DPIC -o .libs/Format.o Format.cc, line 82: Error, wvarhidemem: name hides Format::Format::name. Format.cc, line 87: Error, wvarhidemem: format hides Format::Format::format. 2 Error(s) detected. *** Error code 1 Configuration parameters are: ./configure --prefix=/usr/local/squid --with-logdir=/var/log/squid --without-krb5-config Is this just caused by the strictness of the compiler and if so is there an option to override it during the make? Thanks -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/3-3-4-compilation-error-on-Solaris-10-tp4659827.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] logging issues
On 8/05/2013 1:12 a.m., Mr J Potter wrote: Hi Pablo, Yes, http and https traffic all go through squid, which listens on port 3128. Clients are configured to use this with a PAC file. The HTTPS requests show up as CONNECT requests, which all work fine. I just see no entries when I'm sure AJAX communications are going on. These must be going through squid. They are probably inside the CONNECT tunnels. There is no restriction on how many requests each one contains or even protocol so you may find they are in fact SPDY requests instead of HTTPS. Amos
Re: [squid-users] CONNECT acl protocol
On 8/05/2013 1:31 a.m., China wrote: Hi, I've some squid servers (until 3.1.20 version) which has the following configuration and works great: acl allowed_protocols proto HTTP HTTPS CONNECT FTP http_access deny !allowed_protocols After the upgrade to 3.3.3 version, sqiud print the following warning in the configuration check: WARNING: Ignoring unknown protocol 'CONNECT' in the ACL named 'allowed_protocols' Squid does not at this time support URL starting with connect://. That is all this means. The older versions accepted it, but did nothing with it. So it would seem to be unrelated to the actual problem you are now having. and squid clients can't no more connect to HTTPS sites. There is a CONNECT *method* in HTTP protocol, which is used to pass HTTPS traffic through HTTP proxies. Please check your http_access lines to see what they do when an HTTP request with method CONNECT happens. The default config provided with Squid restricts CONNECT requests to opening tunnels to a specific set of SSL_Ports where HTTPS is normally seen - if you have altered that set or changed the http_access lines those changes may be the cause of your problem. How can I check the protocols like configuration in old versions?-- Please run squid -k parse on your squid.conf file. It should highlight any other problems you have in the config. Amos
[squid-users] Re: 3.3.4 compilation error on Solaris 10
Many thanks I'll try --disable-strict-error-checking first to see if it gets me up and running. I'm working to quite a tight schedule but if I get time I'll try and run it against the HEAD and feed back a list any of errors I find. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/3-3-4-compilation-error-on-Solaris-10-tp4659827p4659835.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] CONNECT acl protocol
The default config restrict methods, not protocol. The problem can be translated as: what I've to put in 'acl allowed_protocols proto ...' to permit https traffic with CONNECT method? If I start Squid in debugging mode this is the trace with problems: kid1| Eui48.cc(262) lookup: Looking up ARP address for X.X.X.X on eth0 kid1| Eui48.cc(262) lookup: Looking up ARP address for X.X.X.X on eth1 kid1| Eui48.cc(303) lookup: Got address MAC on eth1 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13776720 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13776720 kid1| Checklist.cc(153) preCheck: 0x1476118 checking slow rules kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny Gopher' kid1| Acl.cc(336) matches: ACLList::matches: checking Gopher kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'Gopher' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'Gopher' is 0 kid1| Acl.cc(339) matches: ACLList::matches: result is false kid1| Checklist.cc(275) matchNode: 0x1476118 matched=0 async=0 finished=0 kid1| Checklist.cc(299) matchNode: 0x1476118 simple mismatch kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny !allowed_ports' kid1| Acl.cc(336) matches: ACLList::matches: checking !allowed_ports kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'allowed_ports' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'allowed_ports' is 1 kid1| Acl.cc(339) matches: ACLList::matches: result is false kid1| Checklist.cc(275) matchNode: 0x1476118 matched=0 async=0 finished=0 kid1| Checklist.cc(299) matchNode: 0x1476118 simple mismatch kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny !allowed_protocols' kid1| Acl.cc(336) matches: ACLList::matches: checking !allowed_protocols kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'allowed_protocols' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'allowed_protocols' is 0 kid1| Acl.cc(343) matches: ACLList::matches: result is true kid1| Checklist.cc(275) matchNode: 0x1476118 matched=1 async=0 finished=0 kid1| Checklist.cc(260) matchNodes: 0x1476118 success: all ACLs matched kid1| Checklist.cc(146) markFinished: 0x1476118 answer DENIED for first matching rule won kid1| Checklist.cc(88) matchNonBlocking: ACLChecklist::check: 0x1476118 match found, calling back with DENIED kid1| Checklist.cc(182) checkCallback: ACLChecklist::checkCallback: 0x1476118 answer=DENIED kid1| Gadgets.cc(85) aclIsProxyAuth: aclIsProxyAuth: called for allowed_protocols kid1| Acl.cc(61) FindByName: ACL::FindByName 'allowed_protocols' kid1| Gadgets.cc(93) aclIsProxyAuth: aclIsProxyAuth: returning 0 kid1| Gadgets.cc(58) aclGetDenyInfoPage: got called for allowed_protocols kid1| Gadgets.cc(77) aclGetDenyInfoPage: aclGetDenyInfoPage: no match kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13775b80 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13775b80 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13775a60 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13775a60 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x1476118 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x1476118 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x1476118 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x1476118 kid1| client_side.cc(784) swanSong: local=Y.Y.Y.Y:Y remote=X.X.X.X:X flags=1 Thank you On Tue, May 7, 2013 at 4:54 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 8/05/2013 1:31 a.m., China wrote: Hi, I've some squid servers (until 3.1.20 version) which has the following configuration and works great: acl allowed_protocols proto HTTP HTTPS CONNECT FTP http_access deny !allowed_protocols After the upgrade to 3.3.3 version, sqiud print the following warning in the configuration check: WARNING: Ignoring unknown protocol 'CONNECT' in the ACL named 'allowed_protocols' Squid does not at this time support URL starting with connect://. That is all this means. The older versions accepted it, but did nothing with it. So it would seem to be unrelated to the actual problem you are now having. and squid clients can't no more connect to HTTPS sites. There is a CONNECT *method* in HTTP protocol, which is used to pass HTTPS traffic through HTTP proxies. Please check your http_access lines to see what they do when an HTTP request with method CONNECT happens. The default config provided with Squid restricts CONNECT requests to opening tunnels to a specific set of SSL_Ports where HTTPS is normally seen - if you have altered that set or changed the http_access lines
[squid-users] RE: logging of headers after request modification
OK, I have done some more testing:
if I send A Via Header, then this header gets logged with %{Via}h - but ONLY
the value sent (not the modified version)
if I log instead the response header with %{Via}h it gets logged without
having received the header, but then the modifications of the header (as per
the ps config) are not logged - only the original header generated by squid.
Also an observation in that area is that the Via header get set to the
modified version in the peer request, but it does NOT get sent in the
response sent to the client. That is probably why %{Via}h is logging the
squid modified version and not the version of request-header-replace.
Any ideas how to solve this logging issue?
Thanks,
Martin
p.s: As a workaround - I actually just need to know if the ACL matches or not
and log that true/false value in some form...
-Original Message-
From: Martin Sperl
Sent: Dienstag, 07. Mai 2013 16:03
To: squid-users@squid-cache.org
Subject: [squid-users] logging of headers after request modification
Hi!
I have configured squid 3.2.7 logging with the following pattern to log:
logformat xml ...Via%{Via}ha/Via...
access_log daemon:/var/logs/squid/access_log.xml xml all
But I have the problem, that the VIA fields stay empty (actually -)...
So I wonder why and how I can change that, so that I get the Via header as
well...
Thanks,
Martin
P.s: I am modifying the VIA header in my config like this under some
circumstances:
request_header_access Via allow CUSTOM_ACL
request_header_access Via deny all
request_header_replace Via mypersonalvalue
The application sees the expected value in the Via header, so that itself is
not an issue - only logging the header is NOT working as expected...
(it actually only works IF
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Re: [squid-users] logging of headers after request modification
On 05/07/2013 08:03 AM, Martin Sperl wrote:
I have configured squid 3.2.7 logging with the following pattern to log:
logformat xml ...Via%{Via}ha/Via...
access_log daemon:/var/logs/squid/access_log.xml xml all
But I have the problem, that the VIA fields stay empty (actually -)...
So I wonder why and how I can change that, so that I get the Via header as
well...
P.s: I am modifying the VIA header in my config like this under some
circumstances:
request_header_access Via allow CUSTOM_ACL
request_header_access Via deny all
request_header_replace Via mypersonalvalue
The application sees the expected value in the Via header, so that
itself is not an issue - only logging the header is NOT working as
expected... (it actually only works IF
[http::]ha logs request headers received by Squid and adapted by
ICAP/eCAP. It does not log request headers sent by Squid. There is
currently no logformat code to log the latter.
If you want to log outgoing Via, your options include:
1) add a logformat code to log outgoing request headers (requires
development);
2) use note directive and %note logformat code to log mypersonalvalue
when needed (requires Squid trunk?)
3) move Via manipulation to ICAP/eCAP while disabling Squid's Via
generation (requires writing or adjusting an adaptation service).
HTH,
Alex.
Re: [squid-users] CONNECT acl protocol
On 8/05/2013 3:13 a.m., China wrote: The default config restrict methods, not protocol. The problem can be translated as: what I've to put in 'acl allowed_protocols proto ...' to permit https traffic with CONNECT method? Try NONE. CONNECT URLs have no protocol scheme, just a TCP IP:port (or FQDN:port). I highly recommend you go back to the settings we distribute with Squid: http_access deny !Safe_ports http_access deny CONNECT !SSL_ports These two rules prohibit traffic going to ports known to be unsafe for HTTP traffic delivery, and prohibit CONNECT tunnels to ports where HTTPS is not normally found. You adjust them further by altering the contents of Safe_ports and SSL_ports ACLs. You seem to have renamed Safe_ports to allowed_ports for some reason, and removed the controls on CONNECT. Amos If I start Squid in debugging mode this is the trace with problems: kid1| Eui48.cc(262) lookup: Looking up ARP address for X.X.X.X on eth0 kid1| Eui48.cc(262) lookup: Looking up ARP address for X.X.X.X on eth1 kid1| Eui48.cc(303) lookup: Got address MAC on eth1 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13776720 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13776720 kid1| Checklist.cc(153) preCheck: 0x1476118 checking slow rules kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny Gopher' kid1| Acl.cc(336) matches: ACLList::matches: checking Gopher kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'Gopher' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'Gopher' is 0 kid1| Acl.cc(339) matches: ACLList::matches: result is false kid1| Checklist.cc(275) matchNode: 0x1476118 matched=0 async=0 finished=0 kid1| Checklist.cc(299) matchNode: 0x1476118 simple mismatch kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny !allowed_ports' kid1| Acl.cc(336) matches: ACLList::matches: checking !allowed_ports kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'allowed_ports' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'allowed_ports' is 1 kid1| Acl.cc(339) matches: ACLList::matches: result is false kid1| Checklist.cc(275) matchNode: 0x1476118 matched=0 async=0 finished=0 kid1| Checklist.cc(299) matchNode: 0x1476118 simple mismatch kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny !allowed_protocols' kid1| Acl.cc(336) matches: ACLList::matches: checking !allowed_protocols kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'allowed_protocols' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'allowed_protocols' is 0 kid1| Acl.cc(343) matches: ACLList::matches: result is true kid1| Checklist.cc(275) matchNode: 0x1476118 matched=1 async=0 finished=0 kid1| Checklist.cc(260) matchNodes: 0x1476118 success: all ACLs matched kid1| Checklist.cc(146) markFinished: 0x1476118 answer DENIED for first matching rule won kid1| Checklist.cc(88) matchNonBlocking: ACLChecklist::check: 0x1476118 match found, calling back with DENIED kid1| Checklist.cc(182) checkCallback: ACLChecklist::checkCallback: 0x1476118 answer=DENIED kid1| Gadgets.cc(85) aclIsProxyAuth: aclIsProxyAuth: called for allowed_protocols kid1| Acl.cc(61) FindByName: ACL::FindByName 'allowed_protocols' kid1| Gadgets.cc(93) aclIsProxyAuth: aclIsProxyAuth: returning 0 kid1| Gadgets.cc(58) aclGetDenyInfoPage: got called for allowed_protocols kid1| Gadgets.cc(77) aclGetDenyInfoPage: aclGetDenyInfoPage: no match kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13775b80 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13775b80 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13775a60 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13775a60 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x1476118 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x1476118 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x1476118 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x1476118 kid1| client_side.cc(784) swanSong: local=Y.Y.Y.Y:Y remote=X.X.X.X:X flags=1 Thank you On Tue, May 7, 2013 at 4:54 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 8/05/2013 1:31 a.m., China wrote: Hi, I've some squid servers (until 3.1.20 version) which has the following configuration and works great: acl allowed_protocols proto HTTP HTTPS CONNECT FTP http_access deny !allowed_protocols After the upgrade to 3.3.3 version, sqiud print the following warning in the configuration check: WARNING: Ignoring unknown protocol 'CONNECT' in the ACL named 'allowed_protocols' Squid does not at this time support URL starting with connect://. That is all this
RE: [squid-users] logging of headers after request modification
Hi Alex!
Is there any other configuration option (in squid 3.2) to log if an ACL matches
in the access-log? (which is all I essentially need) (besides logging to 2
different logfiles - been there and there was this issue with multiple
instances of the logger daemon writing to the same file)
Everything else is a development/testing effort that is not possible in our
timeframe to deploying...
Thanks,
Martin
-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
Sent: Dienstag, 07. Mai 2013 17:37
To: squid-users@squid-cache.org
Subject: Re: [squid-users] logging of headers after request modification
On 05/07/2013 08:03 AM, Martin Sperl wrote:
I have configured squid 3.2.7 logging with the following pattern to log:
logformat xml ...Via%{Via}ha/Via...
access_log daemon:/var/logs/squid/access_log.xml xml all
But I have the problem, that the VIA fields stay empty (actually -)...
So I wonder why and how I can change that, so that I get the Via header as
well...
P.s: I am modifying the VIA header in my config like this under some
circumstances:
request_header_access Via allow CUSTOM_ACL
request_header_access Via deny all
request_header_replace Via mypersonalvalue
The application sees the expected value in the Via header, so that
itself is not an issue - only logging the header is NOT working as
expected... (it actually only works IF
[http::]ha logs request headers received by Squid and adapted by
ICAP/eCAP. It does not log request headers sent by Squid. There is
currently no logformat code to log the latter.
If you want to log outgoing Via, your options include:
1) add a logformat code to log outgoing request headers (requires
development);
2) use note directive and %note logformat code to log mypersonalvalue
when needed (requires Squid trunk?)
3) move Via manipulation to ICAP/eCAP while disabling Squid's Via
generation (requires writing or adjusting an adaptation service).
HTH,
Alex.
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Re: [squid-users] logging of headers after request modification
On 8/05/2013 2:03 a.m., Martin Sperl wrote:
Hi!
I have configured squid 3.2.7 logging with the following pattern to log:
logformat xml ...Via%{Via}ha/Via...
access_log daemon:/var/logs/squid/access_log.xml xml all
But I have the problem, that the VIA fields stay empty (actually -)...
So I wonder why and how I can change that, so that I get the Via header as
well...
%ha logs the header received from the client, after they have been
altered by ICAP, eCAP, or url_rewrite adaptation.
However what you are talking about is the header delivered to the server
or peer. I'm not sure if we have anything which logs that in logformat
codes yet.
Amos
RE: [squid-users] logging of headers after request modification
Yes, I am EXACTLY talking about this...
Or a means to log if an ACL matches of not in true/false (or maybe via notes,
which are not fully documented yet on the website).
But then Trunk is definitely not ready for a production envirionment...
So if you can think of something else that may get me this information into the
logfile - help would be greatly appreciated...
Martin
-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz]
Sent: Dienstag, 07. Mai 2013 17:55
To: squid-users@squid-cache.org
Subject: Re: [squid-users] logging of headers after request modification
On 8/05/2013 2:03 a.m., Martin Sperl wrote:
Hi!
I have configured squid 3.2.7 logging with the following pattern to log:
logformat xml ...Via%{Via}ha/Via...
access_log daemon:/var/logs/squid/access_log.xml xml all
But I have the problem, that the VIA fields stay empty (actually -)...
So I wonder why and how I can change that, so that I get the Via header as
well...
%ha logs the header received from the client, after they have been
altered by ICAP, eCAP, or url_rewrite adaptation.
However what you are talking about is the header delivered to the server
or peer. I'm not sure if we have anything which logs that in logformat
codes yet.
Amos
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Re: [squid-users] logging of headers after request modification
On 05/07/2013 09:49 AM, Martin Sperl wrote:
Is there any other configuration option (in squid 3.2) to log if an
ACL matches in the access-log? (which is all I essentially need)
I have listed all the options I could think of, but I missed the
different logformat options you mentioned. I think they boil down to:
4) Use multiple stdio/daemon loggers to append records to the same file.
This does not require development (assuming current stdio/daemon code
use O_APPEND when opening a log file). If you do not use NFS and manual
page for open(2) implications are correct, then there should be no
conflicts.
5) Use a single tcp logger address to log to the same file (requires
not-yet-accepted trunk patch to work well). Here is a sketch for such a
logger:
nc -k -l 127.0.0.1 1234 one-and-only.log
HTH,
Alex.
-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
Sent: Dienstag, 07. Mai 2013 17:37
To: squid-users@squid-cache.org
Subject: Re: [squid-users] logging of headers after request modification
On 05/07/2013 08:03 AM, Martin Sperl wrote:
I have configured squid 3.2.7 logging with the following pattern to log:
logformat xml ...Via%{Via}ha/Via...
access_log daemon:/var/logs/squid/access_log.xml xml all
But I have the problem, that the VIA fields stay empty (actually -)...
So I wonder why and how I can change that, so that I get the Via header as
well...
P.s: I am modifying the VIA header in my config like this under some
circumstances:
request_header_access Via allow CUSTOM_ACL
request_header_access Via deny all
request_header_replace Via mypersonalvalue
The application sees the expected value in the Via header, so that
itself is not an issue - only logging the header is NOT working as
expected... (it actually only works IF
[http::]ha logs request headers received by Squid and adapted by
ICAP/eCAP. It does not log request headers sent by Squid. There is
currently no logformat code to log the latter.
If you want to log outgoing Via, your options include:
1) add a logformat code to log outgoing request headers (requires
development);
2) use note directive and %note logformat code to log mypersonalvalue
when needed (requires Squid trunk?)
3) move Via manipulation to ICAP/eCAP while disabling Squid's Via
generation (requires writing or adjusting an adaptation service).
Re: [squid-users] CONNECT acl protocol
Ok, tomorrow morning I'll try and reply! Thank again! On Tue, May 7, 2013 at 5:46 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 8/05/2013 3:13 a.m., China wrote: The default config restrict methods, not protocol. The problem can be translated as: what I've to put in 'acl allowed_protocols proto ...' to permit https traffic with CONNECT method? Try NONE. CONNECT URLs have no protocol scheme, just a TCP IP:port (or FQDN:port). I highly recommend you go back to the settings we distribute with Squid: http_access deny !Safe_ports http_access deny CONNECT !SSL_ports These two rules prohibit traffic going to ports known to be unsafe for HTTP traffic delivery, and prohibit CONNECT tunnels to ports where HTTPS is not normally found. You adjust them further by altering the contents of Safe_ports and SSL_ports ACLs. You seem to have renamed Safe_ports to allowed_ports for some reason, and removed the controls on CONNECT. Amos If I start Squid in debugging mode this is the trace with problems: kid1| Eui48.cc(262) lookup: Looking up ARP address for X.X.X.X on eth0 kid1| Eui48.cc(262) lookup: Looking up ARP address for X.X.X.X on eth1 kid1| Eui48.cc(303) lookup: Got address MAC on eth1 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13776720 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13776720 kid1| Checklist.cc(153) preCheck: 0x1476118 checking slow rules kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny Gopher' kid1| Acl.cc(336) matches: ACLList::matches: checking Gopher kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'Gopher' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'Gopher' is 0 kid1| Acl.cc(339) matches: ACLList::matches: result is false kid1| Checklist.cc(275) matchNode: 0x1476118 matched=0 async=0 finished=0 kid1| Checklist.cc(299) matchNode: 0x1476118 simple mismatch kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny !allowed_ports' kid1| Acl.cc(336) matches: ACLList::matches: checking !allowed_ports kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'allowed_ports' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'allowed_ports' is 1 kid1| Acl.cc(339) matches: ACLList::matches: result is false kid1| Checklist.cc(275) matchNode: 0x1476118 matched=0 async=0 finished=0 kid1| Checklist.cc(299) matchNode: 0x1476118 simple mismatch kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny !allowed_protocols' kid1| Acl.cc(336) matches: ACLList::matches: checking !allowed_protocols kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'allowed_protocols' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'allowed_protocols' is 0 kid1| Acl.cc(343) matches: ACLList::matches: result is true kid1| Checklist.cc(275) matchNode: 0x1476118 matched=1 async=0 finished=0 kid1| Checklist.cc(260) matchNodes: 0x1476118 success: all ACLs matched kid1| Checklist.cc(146) markFinished: 0x1476118 answer DENIED for first matching rule won kid1| Checklist.cc(88) matchNonBlocking: ACLChecklist::check: 0x1476118 match found, calling back with DENIED kid1| Checklist.cc(182) checkCallback: ACLChecklist::checkCallback: 0x1476118 answer=DENIED kid1| Gadgets.cc(85) aclIsProxyAuth: aclIsProxyAuth: called for allowed_protocols kid1| Acl.cc(61) FindByName: ACL::FindByName 'allowed_protocols' kid1| Gadgets.cc(93) aclIsProxyAuth: aclIsProxyAuth: returning 0 kid1| Gadgets.cc(58) aclGetDenyInfoPage: got called for allowed_protocols kid1| Gadgets.cc(77) aclGetDenyInfoPage: aclGetDenyInfoPage: no match kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13775b80 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13775b80 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13775a60 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13775a60 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x1476118 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x1476118 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x1476118 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x1476118 kid1| client_side.cc(784) swanSong: local=Y.Y.Y.Y:Y remote=X.X.X.X:X flags=1 Thank you On Tue, May 7, 2013 at 4:54 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 8/05/2013 1:31 a.m., China wrote: Hi, I've some squid servers (until 3.1.20 version) which has the following configuration and works great: acl allowed_protocols proto HTTP HTTPS CONNECT FTP http_access deny !allowed_protocols After the upgrade to 3.3.3 version, sqiud print the
[squid-users] Content Encoding Error
Squid 3.3.3-2 on Debian Testing. Suddenly today after a dist-upgrade yesterday, I am getting a plague of: Content Encoding Error The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression. This is intolerable. Does anyone know the cause?
[squid-users] Re: Empty macros in request_header_add for SSL connections [Squid 3.3.3]
Norman...I am testing squid3.3.3 running on Ubuntu and using the request_header_add setting but it is not working for me. I am just testing HTTP only, no HTTPS. I tried both of these settings: acl allip src 0.0.0.0/0.0.0.0 request_header_add X-YouTube-Edu-Filter abc123 allip and also, request_header_add X-YouTube-Edu-Filter abc123 all I verified with wireshark that the outgoing requests does not contain the HTTP header: X-YouTube-Edu-Filter:abc123 Can you confirm that 'request_header_add' working for you under squid3.3.3? Thanks. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Empty-macros-in-request-header-add-for-SSL-connections-Squid-3-3-3-tp4659578p4659846.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Content Encoding Error
On 8/05/2013 4:36 a.m., cac...@quantum-sci.com wrote: Squid 3.3.3-2 on Debian Testing. Suddenly today after a dist-upgrade yesterday, I am getting a plague of: Content Encoding Error The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression. This is intolerable. Does anyone know the cause? What Squid version were you upgrading from? What user-agent / browser software are you using? What does your squid.conf contain? Also, if you can find the header to/from the client when these requests are happening it woudl be a big help in diagnosing. debug_options 11,2 will give you this in Squid-3.3 but will produce a LOT of output on a busy proxy. Amos
Re: [squid-users] Re: Empty macros in request_header_add for SSL connections [Squid 3.3.3]
On 8/05/2013 11:24 a.m., frodie123 wrote: Norman...I am testing squid3.3.3 running on Ubuntu and using the request_header_add setting but it is not working for me. I am just testing HTTP only, no HTTPS. I tried both of these settings: acl allip src 0.0.0.0/0.0.0.0 request_header_add X-YouTube-Edu-Filter abc123 allip and also, request_header_add X-YouTube-Edu-Filter abc123 all I verified with wireshark that the outgoing requests does not contain the HTTP header: X-YouTube-Edu-Filter:abc123 Can you confirm that 'request_header_add' working for you under squid3.3.3? Please enable debug_options ALL,1 11,2 28,3 55,3 cache.log should then contain a trace of the headers Squid is outputting and what was done with them. Amos
[squid-users] Re: Empty macros in request_header_add for SSL connections [Squid 3.3.3]
I figured out what I was doing wrong. I was running squid2 and upgraded to squid3.3.3. Squid3 was installed in the /etc/squid3 directory which is different than the previous /etc/squid. I needed to modify /etc/squid3/squid.conf configuration. The setting request_header_add is working now. Thanks. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Empty-macros-in-request-header-add-for-SSL-connections-Squid-3-3-3-tp4659578p4659849.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Content Encoding Error
On Tuesday, May 07, 2013 07:04:54 PM Amos Jeffries wrote: What Squid version were you upgrading from? I didn't notice what version it was before. What user-agent / browser software are you using? Tor Browser, which is Firefox long-term release. I switch between Squid and Tor with the addon Proxy Switcher. What does your squid.conf contain? http://pastebin.com/ke5WQkdj Also, if you can find the header to/from the client when these requests are happening it woudl be a big help in diagnosing. debug_options 11,2 will give you this in Squid-3.3 but will produce a LOT of output on a busy proxy. I remember Squid logs. But that was a long time ago. They stopped working for some reason. Just like I remember Squid being able to do FTP, but that was even longer ago.
Re: [squid-users] CONNECT acl protocol
Good, that solved the problem! Thank you On Tue, May 7, 2013 at 6:27 PM, China davide.bell...@gmail.com wrote: Ok, tomorrow morning I'll try and reply! Thank again! On Tue, May 7, 2013 at 5:46 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 8/05/2013 3:13 a.m., China wrote: The default config restrict methods, not protocol. The problem can be translated as: what I've to put in 'acl allowed_protocols proto ...' to permit https traffic with CONNECT method? Try NONE. CONNECT URLs have no protocol scheme, just a TCP IP:port (or FQDN:port). I highly recommend you go back to the settings we distribute with Squid: http_access deny !Safe_ports http_access deny CONNECT !SSL_ports These two rules prohibit traffic going to ports known to be unsafe for HTTP traffic delivery, and prohibit CONNECT tunnels to ports where HTTPS is not normally found. You adjust them further by altering the contents of Safe_ports and SSL_ports ACLs. You seem to have renamed Safe_ports to allowed_ports for some reason, and removed the controls on CONNECT. Amos If I start Squid in debugging mode this is the trace with problems: kid1| Eui48.cc(262) lookup: Looking up ARP address for X.X.X.X on eth0 kid1| Eui48.cc(262) lookup: Looking up ARP address for X.X.X.X on eth1 kid1| Eui48.cc(303) lookup: Got address MAC on eth1 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13776720 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13776720 kid1| Checklist.cc(153) preCheck: 0x1476118 checking slow rules kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny Gopher' kid1| Acl.cc(336) matches: ACLList::matches: checking Gopher kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'Gopher' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'Gopher' is 0 kid1| Acl.cc(339) matches: ACLList::matches: result is false kid1| Checklist.cc(275) matchNode: 0x1476118 matched=0 async=0 finished=0 kid1| Checklist.cc(299) matchNode: 0x1476118 simple mismatch kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny !allowed_ports' kid1| Acl.cc(336) matches: ACLList::matches: checking !allowed_ports kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'allowed_ports' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'allowed_ports' is 1 kid1| Acl.cc(339) matches: ACLList::matches: result is false kid1| Checklist.cc(275) matchNode: 0x1476118 matched=0 async=0 finished=0 kid1| Checklist.cc(299) matchNode: 0x1476118 simple mismatch kid1| Checklist.cc(160) checkAccessList: 0x1476118 checking 'http_access deny !allowed_protocols' kid1| Acl.cc(336) matches: ACLList::matches: checking !allowed_protocols kid1| Acl.cc(319) checklistMatches: ACL::checklistMatches: checking 'allowed_protocols' kid1| Acl.cc(321) checklistMatches: ACL::ChecklistMatches: result for 'allowed_protocols' is 0 kid1| Acl.cc(343) matches: ACLList::matches: result is true kid1| Checklist.cc(275) matchNode: 0x1476118 matched=1 async=0 finished=0 kid1| Checklist.cc(260) matchNodes: 0x1476118 success: all ACLs matched kid1| Checklist.cc(146) markFinished: 0x1476118 answer DENIED for first matching rule won kid1| Checklist.cc(88) matchNonBlocking: ACLChecklist::check: 0x1476118 match found, calling back with DENIED kid1| Checklist.cc(182) checkCallback: ACLChecklist::checkCallback: 0x1476118 answer=DENIED kid1| Gadgets.cc(85) aclIsProxyAuth: aclIsProxyAuth: called for allowed_protocols kid1| Acl.cc(61) FindByName: ACL::FindByName 'allowed_protocols' kid1| Gadgets.cc(93) aclIsProxyAuth: aclIsProxyAuth: returning 0 kid1| Gadgets.cc(58) aclGetDenyInfoPage: got called for allowed_protocols kid1| Gadgets.cc(77) aclGetDenyInfoPage: aclGetDenyInfoPage: no match kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13775b80 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13775b80 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x7fff13775a60 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x7fff13775a60 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x1476118 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x1476118 kid1| FilledChecklist.cc(77) ~ACLFilledChecklist: ACLFilledChecklist destroyed 0x1476118 kid1| Checklist.cc(334) ~ACLChecklist: ACLChecklist::~ACLChecklist: destroyed 0x1476118 kid1| client_side.cc(784) swanSong: local=Y.Y.Y.Y:Y remote=X.X.X.X:X flags=1 Thank you On Tue, May 7, 2013 at 4:54 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 8/05/2013 1:31 a.m., China wrote: Hi, I've some squid servers (until 3.1.20 version) which has the following configuration and works great: acl allowed_protocols proto HTTP
