Re: [squid-users] NOTICE: Authentication not applicable on intercepted requests.

[Amos Jeffries]

On 23/01/2014 4:46 p.m., Dan Charlesworth wrote:
> Hi folks
> 
> I’m running a Squid 3.4.2 instance which has both intercepting
> http_ports and explicit ones. We use proxy_auth on the explicit
> connections and use myportname ACLs to bypass all the auth-related
> stuff on the intercepting ports. This seems to work just fine.
> 
> However, for EVERY SINGLE intercepted request we’re now getting this
> NOTICE printed into the cache.log. Very annoying and unnecessary; if
> the system simply wants to warn me of this incompatibility, isn’t
> once enough? During startup perhaps?

That message is only printed when the auth ACL is actively tested for an
intercepted requests credentials. Apparently your myportname ACL test is
not working and your clients are being faced with a lot of unnecessary
rejections. Would you (or I) have been able to identify the cause easily
if it was only printed once?

NP: For a working config it should never appear at all.

> 
> So, assuming there is isn’t some magic http_access hierarchy that
> will prevent this, am I going to need a patch or something?

Yep, there should be a magic heirarchy that does that.

Amos

Re: AW: [squid-users] Squid 3.4 sends Windows username without backslash to external wbinfo_group helper

[Amos Jeffries]

On 23/01/2014 4:12 a.m., Alex Crow wrote:
> Hi,
> 
> Just noticed something in the changelogs for the nightly build that
> might mean this is fixed - I'm optimistic anyway:
> 
> Tue 2014-01-21 20:29:15 -0700
> 
> Amos Jeffries +10 -2
> Fix external_acl_type async loop failures
> 

If it does then we can peg the problem down to being the well-known
systemic issues in NTLM handshake.

Amos

> 
> 
> Now I just need to figure out the "Unhandled exception: c" errors that
> kill my squid every so often. It seems to be a rare issue as from
> googling only myself and two other people seem to have faced it.

That mysterious 'c' again :-(. Some part of Squid is using the Must()
exception mechanism when it should be using assert() instead.

If you have core dumps enabled you may be able to locate in there what
the details that 'c' variable contain about the exception and where its
coming from. Without that there is little hope of fixing it any time soon.

Amos

Re: [squid-users] NOTICE: Authentication not applicable on intercepted requests.

[Dan Charlesworth]

That’s a very good point ...

Well that’s good to know. I’ll keep experimenting with the http_access rules 
until I get it right.

Thanks Amos

On 23 Jan 2014, at 7:06 pm, Amos Jeffries  wrote:

> On 23/01/2014 4:46 p.m., Dan Charlesworth wrote:
>> Hi folks
>> 
>> I’m running a Squid 3.4.2 instance which has both intercepting
>> http_ports and explicit ones. We use proxy_auth on the explicit
>> connections and use myportname ACLs to bypass all the auth-related
>> stuff on the intercepting ports. This seems to work just fine.
>> 
>> However, for EVERY SINGLE intercepted request we’re now getting this
>> NOTICE printed into the cache.log. Very annoying and unnecessary; if
>> the system simply wants to warn me of this incompatibility, isn’t
>> once enough? During startup perhaps?
> 
> That message is only printed when the auth ACL is actively tested for an
> intercepted requests credentials. Apparently your myportname ACL test is
> not working and your clients are being faced with a lot of unnecessary
> rejections. Would you (or I) have been able to identify the cause easily
> if it was only printed once?
> 
> NP: For a working config it should never appear at all.
> 
>> 
>> So, assuming there is isn’t some magic http_access hierarchy that
>> will prevent this, am I going to need a patch or something?
> 
> Yep, there should be a magic heirarchy that does that.
> 
> Amos

Re: [squid-users] Re: Squid 3.4.2 workers dying then re-spawned ones don't process connections

[Amos Jeffries]

On 23/01/2014 2:07 p.m., Will Roberts wrote:
> Okay, no takers. Maybe if I describe our infrastructure a bit something
> will pop.
> 
> When we add/remove a user we push a new file over to the server and tell
> squid to reconfigure itself. This can happen at most once a minute,
> though usually it's much less frequent than that.

> 
> I've seen a lot of messages about closing old connections due to
> lifetime timeout, is there any possibility that we're hitting a fd
> limit? Or something else that would cause opening a connection to fail?
> 

This is no failure. see client_lifetime directive and its value. Your
client connections are lasting that long. They are probably being
re-used the entire time for keep-alive traffic or CONNECT tunnels until
the timeout is reached which forces it to be closed.

The current default of 1 day is quite old. As the manual notes it is
supposed to be far longer than any browser needs to remain connected.
However these days you might face persistent HTTPS (via long-lived
CONNECT tunnels), long-polling connections, 24x7 mobile device
connectivity, browsers that *never* shutdown, and proxies that support
indefinite streams of keep-alive requests. Any one of which would give
you much more long lived client connections. I extended my proxies
setting to 1 week and spotted facebook connections lasting longer than
even that some time back.


> --Will
> 
> On 01/21/2014 05:53 PM, Will Roberts wrote:
>> Hi,
>>
>> I'm having a problem with some of my squids where they'll crash with
>> one of these two messages:
>>
>> FATAL: dying from an unhandled exception:
>> AddOpenedHttpSocket(s->listenConn)
>> FATAL: dying from an unhandled exception: HttpSockets[NHttpSockets] < 0
>>
>> I haven't seen anything on the list with that text, nor do I see any
>> open issues in the bug tracker. What kind of additional information
>> can I provide to help debug this?

I think these are another bug highlighted by how you have workers with
unique ports that the coordinator does not know about. It is a new bug
definitely but have not the time to investigate properly.

Amos

Re: [squid-users] NOTICE: Authentication not applicable on intercepted requests.

[Amos Jeffries]

On 23/01/2014 9:36 p.m., Dan Charlesworth wrote:
> That’s a very good point ...
> 
> Well that’s good to know. I’ll keep experimenting with the http_access rules 
> until I get it right.

If you are able to share them I am happy to take a look and see what
coudl be done.

Amos

[squid-users] Cross compilation in version > 3.1

[Stefano Cordibella]

Hi list,
I am trying to compile squid 3.3.11 in our openembedded 
environment, but the configure step fails due to a cross compile check.

In version 3.1.23 there wasn't those checks and the build goes well...

So my questions are:
1) why from version 3.2 these checks are included in configure?
2) are there any way to cross compile 3.3 (or 3.4)?
3) I read in the FAQ that from version 3.2 C++11 compilers is required, 
I am using gcc 4.7.2, is it a supported compiler?


Thanks in advance,
Stefano.

--
*Stefano Cordibella*
EDALab s.r.l. - Networked Embedded Systems

Strada Le Grazie, 15 - 37134 Verona - Italy
email : stefano.cordibe...@edalab.it
skype : stefano.cordibella
tel. : +39 045 802 70 85
web : www.edalab.it

Re: [squid-users] Cross compilation in version > 3.1

[Amos Jeffries]

On 23/01/2014 10:39 p.m., Stefano Cordibella wrote:
> Hi list,
> I am trying to compile squid 3.3.11 in our openembedded environment,
> but the configure step fails due to a cross compile check.
> In version 3.1.23 there wasn't those checks and the build goes well...
> 
> So my questions are:
> 1) why from version 3.2 these checks are included in configure?

The change in behaviour is from newer autoconf being used to generate
the code tarballs. One of the reasons for that was to get better/easier
cross-compiling support.


> 2) are there any way to cross compile 3.3 (or 3.4)?

You should only** have to specify the ./configure options to tell it
which OS the compile is happening on (--build=X) and which OS type will
run the binary (--host=Y).

What exactly is the failure you are encountering?


** besides having the appropriate *-dev library versions installed for
cross-compiling against and tools that can cross-compile.


> 3) I read in the FAQ that from version 3.2 C++11 compilers is required,
> I am using gcc 4.7.2, is it a supported compiler?

Not required. "Preferred" is the word for it. We have code to make use
of some C++11 only when available. Mostly we are taking advantage of the
increased compiler code checking in our build farm to remove bugs before
anyone notices them :-)

The switch to mandatory C++11 support for general builds is still being
discussed on squid-dev and IRC as to when the timing would offer least
pain for everyonea and how long we can procrastinate on it. It might
happen around Squid-3.6.

Any GCC 4.0+ (excluding 4.5 with broken stdlib definitions of
auto_ptr/unique_ptr) should work fine for Squid-3.2 and later. The later
versions are better though with more general C++11 support benfits than
the older ones.

Cheers
Amos

[squid-users] HTTP Response processing

[Bhagwat Yadav]

Hi,

Can anybody tell me where  HTTP response handling is being done in Squid code?
I am using squid version 3.1.20.


TIA,
Bhagwat

Re: [squid-users] Hypothetically comparing SATA\SAS to NAS\SAN for squid.

[Marcus Kool]

What you are asking for are courses for file systems and disk array performance 
tuning.
EMC, HDS, HP and Netapp have some public documents about the latter subject.

Marcus


On 01/23/2014 04:33 AM, Eliezer Croitoru wrote:

Hey Marcus,

I want to read more about these algorithms or to hear something about them.
What are my options?
I do want to lean more about these but I am not sure what to look where to look 
and how to look.
I am looking for more directions about the subject since it's important and not 
only to me.

Thanks,
Eliezer

On 22/01/14 17:06, Marcus Kool wrote:

For the NAS and SAN: algorithms are usually smarter and the larger disk
arrays can present
a virtual disk to a host that has a very high throughput, high IOPS and
low latency.

[squid-users] Re: Squid doen't throw a challenge everytime

[rt]

Any ideas?



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-doen-t-throw-a-challenge-everytime-tp4664393p4664402.html
Sent from the Squid - Users mailing list archive at Nabble.com.

[squid-users] Squid error????

[Monah Baki]

Hi all,


I am running FreeBSD 9.2 with squid 3.4.1, this machine has no users
at all yet. I saw this message and was not sure if it is squid or
freebsd related.

2014/01/22 20:13:47|  FD 15, [::] [ job1]: (53) Software caused connection abort
2014/01/22 20:30:20|  FD 15, [::] [Stopped, reason:Listener socket
closed job1]: (53) Software caused connection abort

I can still use the proxy though and browse.

No idea what it is, and what might have caused it. Any help will be
greatly appreciated.


Thanks

Re: [squid-users] Re: Squid 3.4.2 workers dying then re-spawned ones don't process connections

[Will Roberts]

On 01/23/2014 04:07 AM, Amos Jeffries wrote:

I've seen a lot of messages about closing old connections due to
lifetime timeout, is there any possibility that we're hitting a fd
limit? Or something else that would cause opening a connection to fail?


This is no failure. see client_lifetime directive and its value. Your
client connections are lasting that long. They are probably being
re-used the entire time for keep-alive traffic or CONNECT tunnels until
the timeout is reached which forces it to be closed.

The current default of 1 day is quite old. As the manual notes it is
supposed to be far longer than any browser needs to remain connected.
However these days you might face persistent HTTPS (via long-lived
CONNECT tunnels), long-polling connections, 24x7 mobile device
connectivity, browsers that *never* shutdown, and proxies that support
indefinite streams of keep-alive requests. Any one of which would give
you much more long lived client connections. I extended my proxies
setting to 1 week and spotted facebook connections lasting longer than
even that some time back.
Right, I know those messages aren't a failure. I was just pointing out 
that we were receiving a fair number of them. I can check how many fds 
are in use next time this happens.



On 01/21/2014 05:53 PM, Will Roberts wrote:

Hi,

I'm having a problem with some of my squids where they'll crash with
one of these two messages:

FATAL: dying from an unhandled exception:
AddOpenedHttpSocket(s->listenConn)
FATAL: dying from an unhandled exception: HttpSockets[NHttpSockets] < 0

I haven't seen anything on the list with that text, nor do I see any
open issues in the bug tracker. What kind of additional information
can I provide to help debug this?

I think these are another bug highlighted by how you have workers with
unique ports that the coordinator does not know about. It is a new bug
definitely but have not the time to investigate properly.


Okay. I'll file a bug with that text and poke around at the code a bit; 
see if there's anything that might be worth printing out.


--Wil

Re: [squid-users] Re: Squid 3.4.2 workers dying then re-spawned ones don't process connections

[Will Roberts]

On 01/23/2014 04:07 AM, Amos Jeffries wrote:

I've seen a lot of messages about closing old connections due to
lifetime timeout, is there any possibility that we're hitting a fd
limit? Or something else that would cause opening a connection to fail?


This is no failure. see client_lifetime directive and its value. Your
client connections are lasting that long. They are probably being
re-used the entire time for keep-alive traffic or CONNECT tunnels until
the timeout is reached which forces it to be closed.

The current default of 1 day is quite old. As the manual notes it is
supposed to be far longer than any browser needs to remain connected.
However these days you might face persistent HTTPS (via long-lived
CONNECT tunnels), long-polling connections, 24x7 mobile device
connectivity, browsers that *never* shutdown, and proxies that support
indefinite streams of keep-alive requests. Any one of which would give
you much more long lived client connections. I extended my proxies
setting to 1 week and spotted facebook connections lasting longer than
even that some time back.
Right, I know those messages aren't a failure. I was just pointing out 
that we were receiving a fair number of them. I can check how many fds 
are in use next time this happens.



On 01/21/2014 05:53 PM, Will Roberts wrote:

Hi,

I'm having a problem with some of my squids where they'll crash with
one of these two messages:

FATAL: dying from an unhandled exception:
AddOpenedHttpSocket(s->listenConn)
FATAL: dying from an unhandled exception: HttpSockets[NHttpSockets] < 0

I haven't seen anything on the list with that text, nor do I see any
open issues in the bug tracker. What kind of additional information
can I provide to help debug this?

I think these are another bug highlighted by how you have workers with
unique ports that the coordinator does not know about. It is a new bug
definitely but have not the time to investigate properly.


Okay. I'll file a bug with that text and poke around at the code a bit; 
see if there's anything that might be worth printing out.


--Will

Re: [squid-users] Squid 3.4.2 workers dying then re-spawned ones don't process connections

[Will Roberts]

On 01/23/2014 12:49 AM, Eliezer Croitoru wrote:

Hey Will,

About the 3.4.2, what OS are you using?
Is it a self compiled version of squid?
"squid -v" will give the basic idea of the squid configurations.


I'm using a self-compiled version on Debian 6 (64bit only at the moment).

configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' '--sysconfdir=/etc' 
'--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' 
'--disable-maintainer-mode' '--disable-dependency-tracking' 
'--disable-silent-rules' '--srcdir=.' '--datadir=/usr/share/squid3' 
'--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' 
'--disable-disk-io' '--disable-storeio' '--disable-removal-policies' 
'--disable-icmp' '--disable-delay-pools' '--disable-esi' 
'--disable-icap-client' '--disable-ecap' '--disable-wccp' 
'--disable-wccpv2' '--disable-snmp' '--disable-eui' '--disable-htcp' 
'--disable-ssl' '--disable-forw-via-db' '--disable-cache-digests' 
'--disable-follow-x-forwarded-for' '--disable-ident-lookups' 
'--enable-auth' '--enable-auth-basic=none' '--enable-auth-digest=file' 
'--disable-auth-negotiate' '--disable-auth-ntlm' 
'--enable-log-daemon-helpers=file' '--enable-external-acl-helpers=none' 
'--disable-url-rewrite-helpers' '--disable-storeid-rewrite-helpers' 
'--disable-zph-qos' '--disable-translation' '--disable-auto-locale' 
'--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' 
'--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' 
'--with-large-files' '--with-default-user=proxy' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -g 
-Wall -O2' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -g -Wall -O2'




In order to verify if there is or there isn't a limit of FD that is 
being reached there are couple tools that are available.
One is the /proc/ FS which can show the number of FD that is being 
used by each and every one of the instances of squid.
The other one is "lsof" which you can filter using a "grep" command or 
the internal options such as PID and\or SOCKETS.

the ulimit command in couple variations can indicate the basic limits:
ulimit -aH
ulimit -aS


The server I just checked has about 906 FDs open, however, looking at 
the limits it can have up to 65535 open. So that's probably not directly 
the issue, unless there's a select call somewhere that's failing.




Note that the squid cache-mgr interface has lots of information if 
available.


Are you using cache_dir ?


I haven't looked much at the cache-mgr interface, I'll take a look at 
that and see what it says. I am not using a cache_dir. In fact, no 
caching is allowed at all:


cache deny all


--Will

Re: [squid-users] HTTP Response processing

[Amos Jeffries]

On 23/01/2014 11:55 p.m., Bhagwat Yadav wrote:
> Hi,
> 
> Can anybody tell me where  HTTP response handling is being done in Squid code?
> I am using squid version 3.1.20.

Most of the code in src\* files is about handling HTTP responses.

Any particular piece of handling you are interested in and why?


PS. this is the *users* mailing list, the developers are mostly over in
*squid-dev*.

Amos

[squid-users] auth_param basic children question

[Scott Mayo]

Is there some standard that the auth_param basic children should be
set at when Squid is authenticating users?

Mine was set at 5.   I have moved it up some when working with my
slowness issues.  Slowness has pretty much gone away, but I am not
sure if it was that setting or some other things that I did.

I am just curious if the basic children should be close to the number
of users that I have or how I should try to figure that.

Thanks.

-- 
Scott Mayo
Mayo's Pioneer Seeds   PH: 573-568-3235   CE: 573-614-2138

Re: [squid-users] Re: Squid 3.4.2 workers dying then re-spawned ones don't process connections

[Alex Rousskov]

On 01/22/2014 06:07 PM, Will Roberts wrote:

> When we add/remove a user we push a new file over to the server and tell
> squid to reconfigure itself. This can happen at most once a minute,
> though usually it's much less frequent than that.

If you reconfigure Squid often, consider investing in better
reconfiguration support in Squid. The current reconfiguration handling
is too "heavy", not really suitable for frequent reconfigurations. You
may be disturbing user traffic every time you reconfigure.

Alternatively, redesign your configuration to avoid the need for
reconfiguring Squid when you add/remove users.


> I've seen a lot of messages about closing old connections due to
> lifetime timeout, is there any possibility that we're hitting a fd
> limit? Or something else that would cause opening a connection to fail?

If those messages appear during or right after reconfigure, it is
probably a Squid bug (or lack of better hot reconfiguration support, to
be precise). I think I have seen them too, but I am not sure.


>> FATAL: dying from an unhandled exception:
>> AddOpenedHttpSocket(s->listenConn)
>> FATAL: dying from an unhandled exception: HttpSockets[NHttpSockets] < 0
>>
>> I haven't seen anything on the list with that text, nor do I see any
>> open issues in the bug tracker. What kind of additional information
>> can I provide to help debug this?

Ideally, you should file a bug report and provide the following info:

1) A cache.log file with debug_options set to ALL,9 and as few workers
with as little traffic as possible, while still reproducing the above
bug. The cache.log file should start when Squid starts and end when  the
FATAL messages are logged after a reconfigure attempt.

2) A squid.conf file used for #1 above. The simpler it is, the better.


Please note that if you are using different ports for different SMP
workers and/or excluding those ports from Coordinator, there will be
fewer folks interested in helping you with this problem (simply because
it lies outside what they think the intended SMP use model is).


HTH,

Alex.

[squid-users] Re: Squid 3.2 doesn't build in CentOS 6

[zeratul]

It's CentOS 6.0 i686. And this is the output of yum list installed (3 parts):

ConsoleKit.i6860.4.1-3.el6
ConsoleKit-libs.i686   0.4.1-3.el6
ConsoleKit-x11.i6860.4.1-3.el6
DeviceKit-power.i686   014-1.el6
GConf2.i6862.28.0-6.el6
GConf2-devel.i686  2.28.0-6.el6
GConf2-gtk.i6862.28.0-6.el6
MAKEDEV.i686   3.24-6.el6
ModemManager.i686   0.4.0-3.git20100628.el6
NetworkManager.i6861:0.8.1-5.el6
NetworkManager-glib.i686   1:0.8.1-5.el6
NetworkManager-gnome.i686  1:0.8.1-5.el6
ORBit2.i6862.14.17-3.1.el6
ORBit2-devel.i686  2.14.17-3.1.el6
OpenEXR-libs.i686  1.6.1-8.1.el6
PackageKit.i6860.5.8-13.el6
PackageKit-device-rebind.i686  0.5.8-13.el6
PackageKit-glib.i686   0.5.8-13.el6
PackageKit-gstreamer-plugin.i686   0.5.8-13.el6
PackageKit-gtk-module.i686 0.5.8-13.el6
PackageKit-yum.i6860.5.8-13.el6
PackageKit-yum-plugin.i686 0.5.8-13.el6
SDL.i686   1.2.14-2.el6
abrt.i686  1.1.13-4.el6
abrt-addon-ccpp.i686   1.1.13-4.el6
abrt-addon-kerneloops.i686 1.1.13-4.el6
abrt-addon-python.i686 1.1.13-4.el6
abrt-cli.i686  1.1.13-4.el6
abrt-desktop.i686  1.1.13-4.el6
abrt-gui.i686  1.1.13-4.el6
abrt-libs.i686 1.1.13-4.el6
abrt-plugin-logger.i6861.1.13-4.el6
abrt-plugin-rhtsupport.i6861.1.13-4.el6
abrt-plugin-sosreport.i686 1.1.13-4.el6
abyssinica-fonts.noarch1.0-5.1.el6
acl.i686   2.2.49-4.el6
acpid.i686 1.0.10-2.1.el6
aic94xx-firmware.noarch30-2.el6
alsa-lib.i686  1.0.21-3.el6
alsa-lib-devel.i6861.0.21-3.el6
alsa-plugins-pulseaudio.i686   1.0.21-3.el6
alsa-utils.i6861.0.21-3.el6
amanda.i6862.6.1p2-7.el6
amanda-client.i686 2.6.1p2-7.el6
ant.i686   1.7.1-13.el6
ant-antlr.i686 1.7.1-13.el6
ant-apache-bcel.i686   1.7.1-13.el6
ant-apache-bsf.i6861.7.1-13.el6
ant-apache-log4j.i686  1.7.1-13.el6
ant-apache-oro.i6861.7.1-13.el6
ant-apache-regexp.i686 1.7.1-13.el6
ant-apache-resolver.i686   1.7.1-13.el6
ant-commons-logging.i686   1.7.1-13.el6
ant-commons-net.i686   1.7.1-13.el6
ant-javamail.i686  1.7.1-13.el6
ant-jdepend.i686   1.7.1-13.el6
ant-jsch.i686  1.7.1-13.el6
ant-junit.i686 1.7.1-13.el6
ant-nodeps.i6861.7.1-13.el6
ant-swing.i686 1.7.1-13.el6
ant-trax.i686  1.7.1-13.el6
anthy.i686 9100h-10.1.el6
antlr.i686   2.7.7-6.5.el6
apache-jasper.noarch   5.5.28-3.el6
apache-tomcat-apis.noarch  0.1-1.el6
apr.i686   1.3.9-3.el6
apr-util.i686  1.3.9-3.el6
apr-util-ldap.i686 1.3.9-3.el6
aspell.i686 

[squid-users] Re: Squid 3.2 doesn't build in CentOS 6

[zeratul]

iw.i6860.9.17-4.el6
iwl1000-firmware.noarch   
128.50.3.1-1.1.el6
iwl3945-firmware.noarch15.32.2.9-4.el6
iwl4965-firmware.noarch   
228.61.2.24-2.1.el6
iwl5000-firmware.noarch8.24.2.12-3.el6
iwl5150-firmware.noarch8.24.2.2-1.el6
iwl6000-firmware.noarch9.176.4.1-2.el6
iwl6050-firmware.noarch9.201.4.1-2.el6
jakarta-commons-codec.i686 1.3-11.7.el6
jakarta-commons-discovery.noarch   1:0.4-5.4.el6
jakarta-commons-el.noarch  1.0-18.4.el6
jakarta-commons-httpclient.i6861:3.1-0.6.el6
jakarta-commons-io.noarch  1.4-3.el6
jakarta-commons-lang.noarch2.4-1.1.el6
jakarta-commons-logging.noarch 1.0.4-10.el6
jakarta-commons-net.noarch 2.0-2.1.el6
jakarta-oro.i686   2.0.8-6.6.el6
jasper-libs.i686   1.900.1-15.el6
java-1.5.0-gcj.i6861.5.0.0-29.1.el6
java-1.6.0-openjdk.i686   
1:1.6.0.0-1.21.b17.el6
java-1.6.0-openjdk-devel.i686 
1:1.6.0.0-1.21.b17.el6
java-1.6.0-openjdk-javadoc.i686   
1:1.6.0.0-1.21.b17.el6
java_cup.i686  1:0.10k-5.el6
jdepend.noarch 2.9-1.2.el6
jetty-eclipse.noarch   6.1.21-1.el6
jline.noarch   0.9.94-0.8.el6
jna.i686   3.2.4-2.el6
jomolhari-fonts.noarch 0.003-8.1.el6
jpackage-utils.noarch  1.7.5-3.12.el6
jre.i586   1.7.0_40-fcs 
 
jsch.noarch0.1.41-2.2.el6
junit.i686 3.8.2-6.5.el6
junit4.noarch  4.5-5.3.el6
jzlib.i686 1.0.7-7.5.el6
kasumi.i6862.5-1.1.el6
kbd.i686   1.15-11.el6
kbd-misc.noarch1.15-11.el6
kernel.i6862.6.32-71.el6
kernel-devel.i686  2.6.32-71.el6
kernel-devel.i686 
2.6.32-358.18.1.el6
kernel-firmware.noarch 2.6.32-71.el6
kernel-headers.i6862.6.32-71.el6
kexec-tools.i686   2.0.0-145.el6
keyutils.i686  1.4-1.el6
keyutils-libs.i686 1.4-1.el6
keyutils-libs-devel.i686   1.4-1.el6
khmeros-base-fonts.noarch  5.0-9.el6
khmeros-fonts-common.noarch5.0-9.el6
kpartx.i6860.4.9-31.el6
kpathsea.i686  2007-56.el6
krb5-devel.i6861.8.2-3.el6
krb5-libs.i686 1.8.2-3.el6
krb5-workstation.i686  1.8.2-3.el6
kurdit-unikurd-web-fonts.noarch20020502-6.el6
latencytop.i6860.5-3.el6
latrace.i686   0.5.9-2.el6
lcms-libs.i686 1.19-1.el6
less.i686  436-4.el6
libICE.i6861.0.6-1.el6
libICE-devel.i686  1.0.6-1.el6
libIDL.i6860.8.13-2.1.el6
libIDL-devel.i686  0.8.13-2.1.el6
libSM.i686 1.1.0-7.1.el6
libSM-devel.i686   1.1.0-7.1.el6
libX11.i6861.5.0-4.el6
libX11-common.noarch   1.5.0-4.el6
libX11-devel.i686  1.5.0-4.el6
libXScrnSaver.i686 1.2.0-1.el6
libXa

[squid-users] Re: Squid 3.2 doesn't build in CentOS 6

[zeratul]

perf.noarch2.6.32-71.el6
perl.i686  4:5.10.1-136.el6
perl-Archive-Extract.i686  1:0.38-136.el6
perl-Archive-Tar.i686  1.58-136.el6
perl-CGI.i686  3.51-136.el6
perl-CPAN.i686 1.9402-136.el6
perl-CPANPLUS.i686 0.88-136.el6
perl-Compress-Raw-Bzip2.i686   2.021-136.el6
perl-Compress-Raw-Zlib.i6861:2.021-136.el6
perl-Compress-Zlib.i6862.021-136.el6
perl-Crypt-SSLeay.i686 0.57-16.el6
perl-DBD-SQLite.i686   1.27-3.el6
perl-DBI.i686  1.609-4.el6
perl-DBIx-Simple.noarch1.32-3.el6
perl-Digest-SHA.i686   1:5.47-136.el6
perl-Error.noarch  1:0.17015-4.el6
perl-ExtUtils-CBuilder.i6861:0.27-136.el6
perl-ExtUtils-Embed.i686   1.28-136.el6
perl-ExtUtils-MakeMaker.i686   6.55-136.el6
perl-ExtUtils-ParseXS.i686
1:2.2003.0-136.el6
perl-File-Fetch.i686   0.26-136.el6
perl-Git.noarch1.7.1-3.el6_4.1
perl-HTML-Parser.i686  3.64-2.el6
perl-HTML-Tagset.noarch3.20-4.el6
perl-IO-Compress-Base.i686 2.021-136.el6
perl-IO-Compress-Bzip2.i6862.021-136.el6
perl-IO-Compress-Zlib.i686 2.021-136.el6
perl-IO-Zlib.i686  1:1.09-136.el6
perl-IPC-Cmd.i686  1:0.56-136.el6
perl-Locale-Maketext-Simple.i686   1:0.18-136.el6
perl-Log-Message.i686  1:0.02-136.el6
perl-Log-Message-Simple.i686   0.04-136.el6
perl-Module-Build.i686 1:0.3500-136.el6
perl-Module-CoreList.i686  2.18-136.el6
perl-Module-Load.i686  1:0.16-136.el6
perl-Module-Load-Conditional.i686  0.30-136.el6
perl-Module-Loaded.i6861:0.02-136.el6
perl-Module-Pluggable.i686 1:3.90-136.el6
perl-Object-Accessor.i686  1:0.34-136.el6
perl-Package-Constants.i6861:0.02-136.el6
perl-Params-Check.i686 1:0.26-136.el6
perl-Parse-CPAN-Meta.i686  1:1.40-136.el6
perl-Pod-Escapes.i686  1:1.04-136.el6
perl-Pod-Simple.i686   1:3.13-136.el6
perl-SGMLSpm.noarch1.03ii-21.el6
perl-Term-UI.i686  0.20-136.el6
perl-Test-Harness.i686 3.17-136.el6
perl-Test-Simple.i686  0.92-136.el6
perl-Time-HiRes.i686   4:1.9721-136.el6
perl-Time-Piece.i686   1.15-136.el6
perl-URI.noarch1.40-2.el6
perl-XML-Dumper.noarch 0.81-6.el6
perl-XML-Grove.noarch  0.46alpha-40.el6
perl-XML-Parser.i686   2.36-7.el6
perl-XML-Twig.noarch   3.34-1.el6
perl-core.i686 5.10.1-136.el6
perl-devel.i6864:5.10.1-136.el6
perl-libs.i686 4:5.10.1-136.el6
perl-libwww-perl.noarch5.833-2.el6
perl-libxml-perl.noarch0.08-10.el6
perl-parent.i686   1:0.221-136.el6
perl-version.i686  3:0.77-136.el6
phonon-backend-gstreamer.i686  1:4.6.2-16.el6
pidgin.i6862.6.6-5.el6
pilot-link.i6862:0.12.4-6.el6
pinentry.i686  0.7.6-5.el6
pinentry-gtk.i686  0.7.6-5.el6
pinfo.i686 0.6.9-12.el6
pixman.i686

Re: [squid-users] HTTPS forward proxy?

[Alex Rousskov]

On 2014-01-22 11:44, David Deller wrote:
>>> Here's another request, this time with HTTPS:
>>>$ curl --proxy https://my-proxy-server.example:3129 \
>>>  --proxy-anyauth --proxy-user redacted:redacted -w '\n' \
>>>  http://urlecho.appspot.com/echo?body=OK
>>>curl: (56) Recv failure: Connection reset by peer
>>> Nothing in `access.log` after this one, but in `cache.log`:
>>>2014/01/20 20:46:15| clientNegotiateSSL: Error negotiating SSL
>>> connection on FD 10: error:1407609C:SSL
>>> routines:SSL23_GET_CLIENT_HELLO:http request (1/-1)
>>
>> See the serverfault response. curl is connecting to the proxy using
>> plain-text instead of SSL.

Official curl does not support SSL connections to HTTP proxies. Factory
has an experimental curl patch adding such support, including client SSL
certificate authentication IIRC. If all you need is a single
SSL-to-proxy client, that will work for you (please contact me off list
if interested). If you need SSL-to-proxy support in popular browsers and
other clients, a single patched curl will not help, of course.


> I did notice this and wondered if it might be a problem with curl
> itself. So I also tried similar tests with Google Chrome and a Ruby
> HTTP library called excon, both of which specifically mention support
> of HTTPS proxies. I also tried a few other HTTP libraries that have
> HTTP proxy support but don’t specifically mention HTTPS. Since I saw
> the same failing result with all of them, I went back to trying to
> troubleshoot Squid as the likely source of the problem.

In many cases, "HTTPS proxy support" simply means tunneling SSL
connections through HTTP proxies by sending HTTP CONNECT requests to
those HTTP proxies first. That is not SSL-to-proxy mode that you are
looking for.


HTH,

Alex.

Re: [squid-users] HTTPS forward proxy?

[David Deller]

On Jan 23, 2014, at 1:19 PM, Alex Rousskov  
wrote:

> On 2014-01-22 11:44, David Deller wrote:
 Here's another request, this time with HTTPS:
   $ curl --proxy https://my-proxy-server.example:3129 \
 --proxy-anyauth --proxy-user redacted:redacted -w '\n' \
 http://urlecho.appspot.com/echo?body=OK
   curl: (56) Recv failure: Connection reset by peer
 Nothing in `access.log` after this one, but in `cache.log`:
   2014/01/20 20:46:15| clientNegotiateSSL: Error negotiating SSL
 connection on FD 10: error:1407609C:SSL
 routines:SSL23_GET_CLIENT_HELLO:http request (1/-1)
>>> 
>>> See the serverfault response. curl is connecting to the proxy using
>>> plain-text instead of SSL.
> 
> Official curl does not support SSL connections to HTTP proxies. Factory
> has an experimental curl patch adding such support, including client SSL
> certificate authentication IIRC. If all you need is a single
> SSL-to-proxy client, that will work for you (please contact me off list
> if interested). If you need SSL-to-proxy support in popular browsers and
> other clients, a single patched curl will not help, of course.

Thanks for confirming this for me. I was only using curl in this case to 
troubleshoot my Squid server and see if I had configured it correctly. Now I at 
least know not to waste more time on it :)

What I really need is a Ruby HTTP library that can connect to Squid using SSL. 
Ruby can use libcurl (via ‘curb’), but I don’t think I can deploy a patched 
version of curl to my web host. I have tried several libraries and none of them 
so far have worked with my Squid server on its https_port.

Well, let me back up a little. If there was another way to authenticate 
securely to Squid, that would also be acceptable. As I mentioned before, I 
don’t think I’m comfortable with Digest (certainly not Basic). The only other 
options I see are NTLM and Negotiate, which both seem to be Microsoft-specific. 
Am I missing anything there?

>> I did notice this and wondered if it might be a problem with curl
>> itself. So I also tried similar tests with Google Chrome and a Ruby
>> HTTP library called excon, both of which specifically mention support
>> of HTTPS proxies. I also tried a few other HTTP libraries that have
>> HTTP proxy support but don’t specifically mention HTTPS. Since I saw
>> the same failing result with all of them, I went back to trying to
>> troubleshoot Squid as the likely source of the problem.
> 
> In many cases, "HTTPS proxy support" simply means tunneling SSL
> connections through HTTP proxies by sending HTTP CONNECT requests to
> those HTTP proxies first. That is not SSL-to-proxy mode that you are
> looking for.

Very enlightening; that hadn’t occurred to me.

Here are the docs about Chrome’s ‘secure web proxy’ support: 
http://www.chromium.org/developers/design-documents/secure-web-proxy

That page specifically mentions Squid’s https_port, suggesting it should work 
with this Chrome feature, although from the phrasing of it (‘appears to’), the 
person who wrote that may not have actually tested it to find out.

Indeed, I tried replicating the same set of tests that I did with curl, with 
Google Chrome, and had the same unsuccessful results.

David

Re: [squid-users] auth_param basic children question

[Amos Jeffries]

On 2014-01-24 04:04, Scott Mayo wrote:

Is there some standard that the auth_param basic children should be
set at when Squid is authenticating users?

Mine was set at 5.   I have moved it up some when working with my
slowness issues.  Slowness has pretty much gone away, but I am not
sure if it was that setting or some other things that I did.

I am just curious if the basic children should be close to the number
of users that I have or how I should try to figure that.



Not necessarily. There are a large number of factors involved; ratio of 
unique to repeat visitors (active user count), latency on the auth 
verification, whether concurrency is involved, frequency of new 
validation lookups, TTL of the Squid cached helper results and size of 
that cached set. Between them these all balance performance vs 
responsiveness to credential change.
It does need to be high enough to service the number of validations 
per-second that get past those performance tuning parameters.


Amos

Re: [squid-users] auth_param basic children question

[Scott Mayo]

On Thu, Jan 23, 2014 at 2:55 PM, Amos Jeffries  wrote:
> On 2014-01-24 04:04, Scott Mayo wrote:
>>
>> Is there some standard that the auth_param basic children should be
>> set at when Squid is authenticating users?
>>
>> Mine was set at 5.   I have moved it up some when working with my
>> slowness issues.  Slowness has pretty much gone away, but I am not
>> sure if it was that setting or some other things that I did.
>>
>> I am just curious if the basic children should be close to the number
>> of users that I have or how I should try to figure that.
>>
>
> Not necessarily. There are a large number of factors involved; ratio of
> unique to repeat visitors (active user count), latency on the auth
> verification, whether concurrency is involved, frequency of new validation
> lookups, TTL of the Squid cached helper results and size of that cached set.
> Between them these all balance performance vs responsiveness to credential
> change.
> It does need to be high enough to service the number of validations
> per-second that get past those performance tuning parameters.
>


Amos,
  Would you have any suggestions?  Here is a basic outline of my school.

1.  Around 400 devices.
2.  Classes change each hour so probably within the first 5 minutes of
class, the students would be logging in.  Most teacher machines would
already be logged in and just staying on.
3.  Even though there are 400 devices, I would guess there are around
100 students logging in each hour within those first five minutes of
class.

I think that would be a typical scenario.  Just looking for a
suggestion to start with.

Thank you very much.

-- 
Scott Mayo
Mayo's Pioneer Seeds   PH: 573-568-3235   CE: 573-614-2138

Re: [squid-users] HTTPS forward proxy?

[Amos Jeffries]

On 2014-01-24 09:31, David Deller wrote:

On Jan 23, 2014, at 1:19 PM, Alex Rousskov
 wrote:


On 2014-01-22 11:44, David Deller wrote:

Here's another request, this time with HTTPS:
  $ curl --proxy https://my-proxy-server.example:3129 \
--proxy-anyauth --proxy-user redacted:redacted -w '\n' \
http://urlecho.appspot.com/echo?body=OK
  curl: (56) Recv failure: Connection reset by peer
Nothing in `access.log` after this one, but in `cache.log`:
  2014/01/20 20:46:15| clientNegotiateSSL: Error negotiating SSL
connection on FD 10: error:1407609C:SSL
routines:SSL23_GET_CLIENT_HELLO:http request (1/-1)


See the serverfault response. curl is connecting to the proxy using
plain-text instead of SSL.


Official curl does not support SSL connections to HTTP proxies. 
Factory
has an experimental curl patch adding such support, including client 
SSL

certificate authentication IIRC. If all you need is a single
SSL-to-proxy client, that will work for you (please contact me off 
list
if interested). If you need SSL-to-proxy support in popular browsers 
and

other clients, a single patched curl will not help, of course.


Thanks for confirming this for me. I was only using curl in this case
to troubleshoot my Squid server and see if I had configured it
correctly. Now I at least know not to waste more time on it :)

What I really need is a Ruby HTTP library that can connect to Squid
using SSL. Ruby can use libcurl (via ‘curb’), but I don’t think I can
deploy a patched version of curl to my web host. I have tried several
libraries and none of them so far have worked with my Squid server on
its https_port.

Well, let me back up a little. If there was another way to
authenticate securely to Squid, that would also be acceptable. As I
mentioned before, I don’t think I’m comfortable with Digest (certainly
not Basic). The only other options I see are NTLM and Negotiate, which
both seem to be Microsoft-specific. Am I missing anything there?


Those are the ones currently supported by Squid.

Negotiate is only sort-of MS specific. It is usually a MS wrapper 
protocol around the Kerberos scheme. This is currently the most secure 
of auth schemes supported explicitly by Squid.


NTLM is second best. NTLMv2 has most of the same high-security 
properties as Kerberos (slightly less algorithms though) but is much 
more MS-specific and violates HTTP protocol in nasty ways that block 
usage over the Internet / WAN.


Digest is next best. The MD5 step is simply to one-way hash a short 
lived nonce, the password itself is never sent and the system can be 
configured to rotate nonces fast enough that replay attacks are very 
difficult (but not impossible).


Basic auth is ironically both the worst and the best of all of them. It 
is just a scheme for sending two credential tokens to the service. 
Historically is has been used to send user:password details and that is 
terribly bad. However, provided you can configure both the sender and 
receiver to agree on algorithms out-of-band (the HTTP scheme provides no 
way to do so) you can send any type of secured one-use token in the 
"password" field. You just need the client to be able to generate them 
and a Squid Basic auth helper to verify and accept/reject. Properly done 
this can be far more secure than even Negotiate.





I did notice this and wondered if it might be a problem with curl
itself. So I also tried similar tests with Google Chrome and a Ruby
HTTP library called excon, both of which specifically mention support
of HTTPS proxies. I also tried a few other HTTP libraries that have
HTTP proxy support but don’t specifically mention HTTPS. Since I saw
the same failing result with all of them, I went back to trying to
troubleshoot Squid as the likely source of the problem.


In many cases, "HTTPS proxy support" simply means tunneling SSL
connections through HTTP proxies by sending HTTP CONNECT requests to
those HTTP proxies first. That is not SSL-to-proxy mode that you are
looking for.


Very enlightening; that hadn’t occurred to me.

Here are the docs about Chrome’s ‘secure web proxy’ support:
http://www.chromium.org/developers/design-documents/secure-web-proxy

That page specifically mentions Squid’s https_port, suggesting it
should work with this Chrome feature, although from the phrasing of it
(‘appears to’), the person who wrote that may not have actually tested
it to find out.



We have had some responses about success with Chrome here on the list 
years back. No mention recently. And Chrome is very much out there alone 
in the browser market on this now.




Indeed, I tried replicating the same set of tests that I did with
curl, with Google Chrome, and had the same unsuccessful results.


Note that the UI is not mentioned in that page. Only the PAC and command 
line options support this type of connection AFAIK.


Amos

Re: [squid-users] auth_param basic children question

[Amos Jeffries]

On 2014-01-24 10:13, Scott Mayo wrote:
On Thu, Jan 23, 2014 at 2:55 PM, Amos Jeffries  
wrote:

On 2014-01-24 04:04, Scott Mayo wrote:


Is there some standard that the auth_param basic children should be
set at when Squid is authenticating users?

Mine was set at 5.   I have moved it up some when working with my
slowness issues.  Slowness has pretty much gone away, but I am not
sure if it was that setting or some other things that I did.

I am just curious if the basic children should be close to the number
of users that I have or how I should try to figure that.



Not necessarily. There are a large number of factors involved; ratio 
of

unique to repeat visitors (active user count), latency on the auth
verification, whether concurrency is involved, frequency of new 
validation
lookups, TTL of the Squid cached helper results and size of that 
cached set.
Between them these all balance performance vs responsiveness to 
credential

change.
It does need to be high enough to service the number of validations
per-second that get past those performance tuning parameters.




Amos,
  Would you have any suggestions?  Here is a basic outline of my 
school.


1.  Around 400 devices.
2.  Classes change each hour so probably within the first 5 minutes of
class, the students would be logging in.  Most teacher machines would
already be logged in and just staying on.
3.  Even though there are 400 devices, I would guess there are around
100 students logging in each hour within those first five minutes of
class.

I think that would be a typical scenario.  Just looking for a
suggestion to start with.



I would suggest something like the following parameters:

 # To make garbage collection run outside of regular class times
 # so during the period when we expect peaks of login traffic GC
 # does not get in the way.
 # NP: the proxy should only be restarted at the time of evening you 
want the
 # GC cycle to occur. It will be run every 12hrs from last 
start/restart.

 authenticate_cache_garbage_interval 12 hour

 # concurrency * children = 500 ... So that worst-case if the whole 
school
 # logs in at the same single second there is no overload on the 
helpers.

 auth_param basic children 5 startup=5 idle=1 concurrency=100

 # How long to go between checking the credentials with the helper.
 # With Basic auth this is the main means for reducing helper load, but
 # does mean if you change a users password or remove an account it will
 # take up to this long for the change to take effect in the proxy.
 auth_param basic credentialsttl 3 hour


NP: if your helper does not support concurrency use the helper-mux.pl 
which is bundled with recent Squid or downloaded from 
ftp://ftp.squid-cache.org/pub/squid/contrib/helper-mux/. This is very 
useful both in the higher speed concurrency offers and in reducing 
helper virtual memory needs if your main Squid process has a large 
memory footprint (eg. cache_mem or cache_dir data).


Amos

Re: [squid-users] HTTP Response processing

[Amos Jeffries]

On 2014-01-24 02:49, Bhagwat Yadav wrote:

Thanks Amos,

Actually in my deployment I have url filtering engine after squid. When
anybody accesses any blocked url, then filtering engine responds with a
page showing that the accessed url is blocked. I want to check that if 
the
error code is that particular code in case of blocked url, then 
customize

page should be shown.

So for this I want to know where in particular http responses handled 
in

code.


Aha. No need for code patching in the current Squid.

1) Set the following configuration:
 debug_options 11,2

2) reconfigure Squid,

3) run your test traffic

4) search your cache.log for the words "HTTP Server "

NP: you can correlate requests and responses by the connection FD and 
IP:port details of the line preceeding each displayed header.


Amos

Re: [squid-users] HTTPS forward proxy?

[David Deller]

On Jan 23, 2014, at 4:20 PM, Amos Jeffries  wrote:

>> Well, let me back up a little. If there was another way to
>> authenticate securely to Squid, that would also be acceptable. As I
>> mentioned before, I don’t think I’m comfortable with Digest (certainly
>> not Basic). The only other options I see are NTLM and Negotiate, which
>> both seem to be Microsoft-specific. Am I missing anything there?
> 
> Those are the ones currently supported by Squid.
> 
> Negotiate is only sort-of MS specific. It is usually a MS wrapper protocol 
> around the Kerberos scheme. This is currently the most secure of auth schemes 
> supported explicitly by Squid.
> 
> NTLM is second best. NTLMv2 has most of the same high-security properties as 
> Kerberos (slightly less algorithms though) but is much more MS-specific and 
> violates HTTP protocol in nasty ways that block usage over the Internet / WAN.
> 
> Digest is next best. The MD5 step is simply to one-way hash a short lived 
> nonce, the password itself is never sent and the system can be configured to 
> rotate nonces fast enough that replay attacks are very difficult (but not 
> impossible).
> 
> Basic auth is ironically both the worst and the best of all of them. It is 
> just a scheme for sending two credential tokens to the service. Historically 
> is has been used to send user:password details and that is terribly bad. 
> However, provided you can configure both the sender and receiver to agree on 
> algorithms out-of-band (the HTTP scheme provides no way to do so) you can 
> send any type of secured one-use token in the "password" field. You just need 
> the client to be able to generate them and a Squid Basic auth helper to 
> verify and accept/reject. Properly done this can be far more secure than even 
> Negotiate.

Very interesting idea. I will have to think about that.

David

[squid-users] Squid error????

[Monah Baki]

Hi all,


I am running FreeBSD 9.2 with squid 3.4.1, this machine has no users
at all yet. I saw this message and was not sure if it is squid or
freebsd related.

2014/01/22 20:13:47|  FD 15, [::] [ job1]: (53) Software caused connection abort
2014/01/22 20:30:20|  FD 15, [::] [Stopped, reason:Listener socket
closed job1]: (53) Software caused connection abort

I can still use the proxy though and browse.

No idea what it is, and what might have caused it. Any help will be
greatly appreciated.


Thanks

Re: [squid-users] Squid error????

[Amos Jeffries]

On 24/01/2014 12:36 p.m., Monah Baki wrote:
> Hi all,
> 
> 
> I am running FreeBSD 9.2 with squid 3.4.1, this machine has no users
> at all yet. I saw this message and was not sure if it is squid or
> freebsd related.
> 
> 2014/01/22 20:13:47|  FD 15, [::] [ job1]: (53) Software caused connection 
> abort
> 2014/01/22 20:30:20|  FD 15, [::] [Stopped, reason:Listener socket
> closed job1]: (53) Software caused connection abort
> 
> I can still use the proxy though and browse.
> 
> No idea what it is, and what might have caused it. Any help will be
> greatly appreciated.

"Software caused connection abort" is an operating system error message
about the socket.

 What was FD 15 opened for?

Amos

Re: [squid-users] Re: Squid 3.2 doesn't build in CentOS 6

[Eliezer Croitoru]

On 23/01/14 19:39, zeratul wrote:

It's CentOS 6.0 i686. And this is the output of yum list installed (3 parts):

OK yet to look at the info since it might not be related to the issue.
There was an issue with i686 compilation of squid.
I have tried to build it on i686 and had couple of successes SRPMS.
For now I do not have a machine that I can test it on.
I will try to install one later on.
The "--disable-arch-native" option for configure should help if I 
understood right the issue from the past questions.


If you can verify it before me it will help.

Eliezer

Re: [squid-users] Squid 3.4.2 workers dying then re-spawned ones don't process connections

[Eliezer Croitoru]

On 23/01/14 15:17, Will Roberts wrote:


The server I just checked has about 906 FDs open, however, looking at
the limits it can have up to 65535 open. So that's probably not directly
the issue, unless there's a select call somewhere that's failing.

How do you see that exactly if not from the cache-mgr interface?

Eliezer

Re: [squid-users] Squid error????

[Monah Baki]

Hi Amos,

Upon starting squid, (See before last line below)


root@devsrvr:/var/log # 2014/01/23 19:14:31| Set Current Directory to
/usr/local/squid/var/cache/
squid
2014/01/23 19:14:31| Starting Squid Cache version 3.4.1 for
i386-unknown-freebsd9.2...



2014/01/23 19:14:31| WARNING: no_suid: setuid(0): (1) Operation not permitted
2014/01/23 19:14:31| WARNING: no_suid: setuid(0): (1) Operation not permitted
.
2014/01/23 19:14:33| Accepting HTTP Socket connections at
local=[::]:80 remote=[::] FD 15 flags=9
2014/01/23 19:14:33| Accepting SNMP messages on [::]:3401



Thanks

On Thu, Jan 23, 2014 at 7:02 PM, Amos Jeffries  wrote:
> On 24/01/2014 12:36 p.m., Monah Baki wrote:
>> Hi all,
>>
>>
>> I am running FreeBSD 9.2 with squid 3.4.1, this machine has no users
>> at all yet. I saw this message and was not sure if it is squid or
>> freebsd related.
>>
>> 2014/01/22 20:13:47|  FD 15, [::] [ job1]: (53) Software caused connection 
>> abort
>> 2014/01/22 20:30:20|  FD 15, [::] [Stopped, reason:Listener socket
>> closed job1]: (53) Software caused connection abort
>>
>> I can still use the proxy though and browse.
>>
>> No idea what it is, and what might have caused it. Any help will be
>> greatly appreciated.
>
> "Software caused connection abort" is an operating system error message
> about the socket.
>
>  What was FD 15 opened for?
>
> Amos

Re: [squid-users] Squid error????

[Eliezer Croitoru]

On 24/01/14 02:58, Monah Baki wrote:

Hi Amos,

Upon starting squid, (See before last line below)


root@devsrvr:/var/log # 2014/01/23 19:14:31| Set Current Directory to
/usr/local/squid/var/cache/
squid
2014/01/23 19:14:31| Starting Squid Cache version 3.4.1 for
i386-unknown-freebsd9.2...



2014/01/23 19:14:31| WARNING: no_suid: setuid(0): (1) Operation not permitted
2014/01/23 19:14:31| WARNING: no_suid: setuid(0): (1) Operation not permitted
.
2014/01/23 19:14:33| Accepting HTTP Socket connections at
local=[::]:80 remote=[::] FD 15 flags=9
2014/01/23 19:14:33| Accepting SNMP messages on [::]:3401



I will probably have a VM with FBSD 64 bit to test it.

Eliezer

Re: [squid-users] Squid error????

[Monah Baki]

I am running it on VMWare workstation 9.0.2 (32 bit)

On Thu, Jan 23, 2014 at 8:09 PM, Eliezer Croitoru  wrote:
> On 24/01/14 02:58, Monah Baki wrote:
>>
>> Hi Amos,
>>
>> Upon starting squid, (See before last line below)
>>
>>
>> root@devsrvr:/var/log # 2014/01/23 19:14:31| Set Current Directory to
>> /usr/local/squid/var/cache/
>> squid
>> 2014/01/23 19:14:31| Starting Squid Cache version 3.4.1 for
>> i386-unknown-freebsd9.2...
>> 
>> 
>> 
>> 2014/01/23 19:14:31| WARNING: no_suid: setuid(0): (1) Operation not
>> permitted
>> 2014/01/23 19:14:31| WARNING: no_suid: setuid(0): (1) Operation not
>> permitted
>> .
>> 2014/01/23 19:14:33| Accepting HTTP Socket connections at
>> local=[::]:80 remote=[::] FD 15 flags=9
>> 2014/01/23 19:14:33| Accepting SNMP messages on [::]:3401
>>
>
> I will probably have a VM with FBSD 64 bit to test it.
>
> Eliezer

Re: [squid-users] Squid error????

[Eliezer Croitoru]

On 24/01/14 03:12, Monah Baki wrote:

I am running it on VMWare workstation 9.0.2 (32 bit)

Should be the same effect for 64 and 32 bit..
I do understand that there are many 32 bit machines out there and indeed 
there is no need to replace them since they do their job pretty well!!

for example a 32 bit 3.2Ghz CPU can do a lot of web traffic!
I have seen one of these:
http://www-01.ibm.com/common/ssi/rep_ca/9/897/ENUS106-239/index.html

Which seems to me to run pretty well.
So what 350W dedicated for one machine?
RH support it SUSE support it..
Once it out there and running it should run for 10 years by default.
I would first five it a trial period of 5 years just to make sure that 
the product works fine.
Then we can migrate from this machine to a more powerful machine which 
can hold more then only one machine.(mainframe?)

I suppose that a mainframe cannot be "just" have HA capability.

For now I will test it on a kvm host but later on if needed I will test 
it on another physical machine that lay around here.


Eliezer

[squid-users] Would a Compilation of 3.4.2 requires perl?

[Eliezer Croitoru]

I am wondering to myself:
Why would I need perl for squid?
Is it a "must"?
it should be an external utility that can be used with squid but not a 
requirement? am I right about the assumption?


Thanks,
Eliezer

Re: [squid-users] Squid 3.4.2 workers dying then re-spawned ones don't process connections

[Will Roberts]

On 01/23/2014 07:26 PM, Eliezer Croitoru wrote:

On 23/01/14 15:17, Will Roberts wrote:


The server I just checked has about 906 FDs open, however, looking at
the limits it can have up to 65535 open. So that's probably not directly
the issue, unless there's a select call somewhere that's failing.

How do you see that exactly if not from the cache-mgr interface?

Eliezer
I looked at the list in /proc//fd/ and the limit info in 
/proc//limits . I had access to the cache manager completely 
blocked, so I didn't think to look there.


--Will

Re: [squid-users] Squid 3.4.2 workers dying then re-spawned ones don't process connections

[Eliezer Croitoru]

Great,

Sometimes it take a while to understand the issue and the path to 
understand it.


I am not sure what the situation is but it seems like a bug..
If there is no bug report that is similar in the symptoms or the actual 
bug assumption you can file a bug report at the bugzilla.
However I would try to first make sure what the issue is and maybe 
consider posting about the issue in suqid-dev list to analyze the issue 
properly before filing a bug report.


Eliezer

On 24/01/14 04:25, Will Roberts wrote:

I looked at the list in /proc//fd/ and the limit info in
/proc//limits . I had access to the cache manager completely
blocked, so I didn't think to look there.

--Will

Re: [squid-users] Would a Compilation of 3.4.2 requires perl?

[Amos Jeffries]

On 24/01/2014 3:10 p.m., Eliezer Croitoru wrote:
> I am wondering to myself:
> Why would I need perl for squid?
> Is it a "must"?
> it should be an external utility that can be used with squid but not a
> requirement? am I right about the assumption?


It is not needed for the main Squid binary and tools.


It is required for several of the helpers though. To build the helper
documentation and locate the appropriate perl binaries path to insert
into the scripts.

Amos

Fwd: [squid-users] Cache-Control is ignored upon 202 (accept) response

[Boaz Citrin]

I am using 2.7.STABLE8 on Windows. No patch, just the installer from
http://sourceforge.net/projects/squidwindowsmsi/

Also NOT using Store ID/Url features, also probably not using SMP
either as I am not familiar with it.

Not sure about the "Vary" question anyway the request/response don't
contain this header.

Thanks.


On Thu, Jan 23, 2014 at 9:19 AM, Amos Jeffries  wrote:
> On 23/01/2014 3:04 a.m., Boaz Citrin wrote:
>> Hello,
>>
>> I want to invalidate the cache when my server returns 202 to a PUT
>> request, however it seems like Squid ignores the Cache-Control when
>> return code is 202.
>> Tried to set must-revalidate or even not to return any Cache-Control
>> header but these all result no update to cache so subsequent GET
>> request results HIT while I expect a MISS.
>
> Which version of Squid are you using?
>
> Have you any unusual patch applied which might affect caching?
>
> Are you using Store-URL or Store-ID features?
>
> Have you enabled SMP workers?
>
> Is the URL used in PUT presenting a Vary response to GET?
>
> Amos
>

Re: [squid-users] Would a Compilation of 3.4.2 requires perl?

[Eliezer Croitoru]

OK so there is something that needs to be checked later.

On a FreeBSD system 9.2 amd64 suqid compiles fine!!
it runs file as long as I am not using the "http_port 3128" when I see 
that it't trying to bind "::3128"

Else then that it works fine for me on basic tests.
We had a patch for that but it seems to me like something is weird.
Why would a 9.2 version of FreeBSD would not support ipv6 out of the box?
And how can it be detected while compiling squid?


Eliezer

On 24/01/14 05:24, Amos Jeffries wrote:


It is not needed for the main Squid binary and tools.


It is required for several of the helpers though. To build the helper
documentation and locate the appropriate perl binaries path to insert
into the scripts.

Amos