Re: [squid-users] squid.conf.documented instead of squid.conf?

[Silamael]

On 04/14/2010 04:02 PM, Boniforti Flavio wrote:
> Hello list.
> 
> I'm on Debian SID and wanted to update squid3 to the latest 3.1.1-2
> version. What happened is that dpkg returned me following error:
> 
> Configurazione di squid3 (3.1.1-2)...
> sed: errore di lettura su stdin: Is a directory
> dpkg: errore nell'elaborare squid3 (--configure):
>  il sottoprocesso vecchio script di post-installation ha restituito lo
> stato di errore 4
> Si sono verificati degli errori nell'elaborazione:
>  squid3
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> The *second* line is the one that made me investigate a little bit:
> "sed: error reading stdin: Is a directory"... Thus I checked /etc/squid3
> and got this:
> 
> drwxr-xr-x  2 root root 4096 14 apr 15:54 squid.conf
> 
> Entering that directory, I discovered:
> 
> -rw-r--r-- 1 root root 198563 12 apr 16:09 squid.conf.documented
> 
> My questions are:
> 
> A) where did my customized squid.conf disappear to?
> B) is it normal that now the /etc/squid3/squid.conf is not anymore a
> file, but a directory?
> C) how can I extract the actual configuration from the running squid3?

I would say, instead of asking here in the squid mailing list, you
should better file a bug report against the debian package. Looks like
something is wrong there. I don't think this is a Squid problem.

-- Matthias

[squid-users] OpenBSD 4.6: Squid 3.1.3 compilation error (patch attached)

[Silamael]

Hello!

I'm getting some error when compiling Squid 3.1.3 on OpenBSD 4.6 due to
a redefinition of FD_SETSIZE in compat/fdsetsize.h.
Patch attached which fixed this for me.

Greetings,
Matthias
Fix redefinition error for FD_SETSIZE on OpenBSD 4.6.

--- compat/fdsetsize.h.orig Mon May  3 12:56:05 2010
+++ compat/fdsetsize.h  Mon May  3 12:59:49 2010
@@ -71,6 +71,7 @@

 /* Increase FD_SETSIZE if SQUID_MAXFD is bigger */
 #if CHANGE_FD_SETSIZE && SQUID_MAXFD > DEFAULT_FD_SETSIZE
+#undef FD_SETSIZE
 #define FD_SETSIZE SQUID_MAXFD
 #endif

Re: [squid-users] OpenBSD 4.6: Squid 3.1.3 compilation error (patch attached)

[Silamael]

On 05/03/2010 02:04 PM, Amos Jeffries wrote:
> Silamael wrote:
>> Hello!
>>
>> I'm getting some error when compiling Squid 3.1.3 on OpenBSD 4.6 due to
>> a redefinition of FD_SETSIZE in compat/fdsetsize.h.
>> Patch attached which fixed this for me.
>>
>> Greetings,
>> Matthias
>>
> 
> Thanks for the thought, but...
> 
>  Code in Squid is NOT permitted to include system headers before the
> FD_* compat code. Kernel defines will be allocated with incompatible
> size and overflows happen.
> 
> Can you provide a full compiler trace of the clash so we can fix the
> include sequence?
> 
> Amos

No problem. Here you are.

-- Matthias
Making all in smbval
cc -DHAVE_CONFIG_H  -I/ports/www/squid3/w-squid3/squid-3.1.3 
-I/ports/www/squid3/w-squid3/squid-3.1.3/include 
-I/ports/www/squid3/w-squid3/squid-3.1.3/src  -I../../../../include  
-I/ports/www/squid3/w-squid3/squid-3.1.3/helpers/ntlm_auth/smb_lm/smbval -g 
-I/usr/local/include 
-DDEFAULT_SQUID_ERROR_DIR=\"/usr/local/share/squid/errors\"   -Wall 
-Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations 
-Wcomments -Werror -O2 -pipe -MT valid.o -MD -MP -MF .deps/valid.Tpo -c -o 
valid.o 
/ports/www/squid3/w-squid3/squid-3.1.3/helpers/ntlm_auth/smb_lm/smbval/valid.c
mv -f .deps/valid.Tpo .deps/valid.Po
cc -DHAVE_CONFIG_H  -I/ports/www/squid3/w-squid3/squid-3.1.3 
-I/ports/www/squid3/w-squid3/squid-3.1.3/include 
-I/ports/www/squid3/w-squid3/squid-3.1.3/src  -I../../../../include  
-I/ports/www/squid3/w-squid3/squid-3.1.3/helpers/ntlm_auth/smb_lm/smbval -g 
-I/usr/local/include 
-DDEFAULT_SQUID_ERROR_DIR=\"/usr/local/share/squid/errors\"   -Wall 
-Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations 
-Wcomments -Werror -O2 -pipe -MT session.o -MD -MP -MF .deps/session.Tpo -c -o 
session.o 
/ports/www/squid3/w-squid3/squid-3.1.3/helpers/ntlm_auth/smb_lm/smbval/session.c
In file included from /ports/www/squid3/w-squid3/squid-3.1.3/compat/compat.h:34,
 from 
/ports/www/squid3/w-squid3/squid-3.1.3/include/config.h:58,
 from /ports/www/squid3/w-squid3/squid-3.1.3/include/util.h:37,
 from 
/ports/www/squid3/w-squid3/squid-3.1.3/helpers/ntlm_auth/smb_lm/smbval/std-includes.h:27,
 from 
/ports/www/squid3/w-squid3/squid-3.1.3/helpers/ntlm_auth/smb_lm/smbval/session.c:33:
/ports/www/squid3/w-squid3/squid-3.1.3/compat/fdsetsize.h:74:1: "FD_SETSIZE" 
redefined
In file included from /usr/include/sys/types.h:224,
 from /usr/include/stdlib.h:41,
 from 
/ports/www/squid3/w-squid3/squid-3.1.3/helpers/ntlm_auth/smb_lm/smbval/session.c:27:
/usr/include/sys/select.h:47:1: this is the location of the previous definition
*** Error code 1

Stop in /ports/www/squid3/w-squid3/build-i386/helpers/ntlm_auth/smb_lm/smbval 
(line 92 of /usr/share/mk/sys.mk).
*** Error code 1

Stop in /ports/www/squid3/w-squid3/build-i386/helpers/ntlm_auth/smb_lm (line 
418 of Makefile).
*** Error code 1

Stop in /ports/www/squid3/w-squid3/build-i386/helpers/ntlm_auth (line 311 of 
Makefile).
*** Error code 1

Stop in /ports/www/squid3/w-squid3/build-i386/helpers (line 306 of Makefile).
*** Error code 1

Stop in /ports/www/squid3/w-squid3/build-i386 (line 366 of Makefile).
*** Error code 1

Stop in /ports/www/squid3 (line 2189 of 
/usr/ports/infrastructure/mk/bsd.port.mk).

Re: [squid-users] OpenBSD 4.6: Squid 3.1.3 compilation error (patch attached)

[Silamael]

On 05/03/2010 02:04 PM, Amos Jeffries wrote:
> Thanks for the thought, but...
> 
>  Code in Squid is NOT permitted to include system headers before the
> FD_* compat code. Kernel defines will be allocated with incompatible
> size and overflows happen.
> 
> Can you provide a full compiler trace of the clash so we can fix the
> include sequence?
> 
> Amos

Hello Amos,

Here i have another patch fixing the include file ordering for the
ntlm_auth helper. Not sure if this is the best patch but it works for me.

-- Matthias
Fix include order to ensure that FD_SETSIZE from the compat/fdsetsize.h is set
before it is set by sys/select.h (included by stdlib.h).

--- helpers/ntlm_auth/smb_lm/smbval/rfcnb-util.c.orig   Mon May  3 16:17:35 2010
+++ helpers/ntlm_auth/smb_lm/smbval/rfcnb-util.cMon May  3 16:21:23 2010
@@ -23,12 +23,11 @@
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-#include 
-#include 
-
 #include "std-includes.h"
 #include "rfcnb-priv.h"
 #include "rfcnb-util.h"
+#include 
+#include 
 #include "rfcnb-io.h"
 #include 
 
--- helpers/ntlm_auth/smb_lm/smbval/session.c.orig  Sun May  2 12:47:07 2010
+++ helpers/ntlm_auth/smb_lm/smbval/session.c   Mon May  3 16:20:53 2010
@@ -23,9 +23,6 @@
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-#include 
-#include 
-
 int RFCNB_errno = 0;
 int RFCNB_saved_errno = 0;
 #define RFCNB_ERRNO
@@ -34,6 +31,8 @@
 #include 
 #include "rfcnb-priv.h"
 #include "rfcnb-util.h"
+#include 
+#include 
 #include "rfcnb-io.h"
 #include "rfcnb.h"
 

Re: [squid-users] OpenBSD 4.6: Squid 3.1.3 compilation error (patch attached)

[Silamael]

On 05/04/2010 01:42 AM, Brett Lymn wrote:
> On Mon, May 03, 2010 at 05:08:29PM +0200, Silamael wrote:
> 
>> Fix include order to ensure that FD_SETSIZE from the compat/fdsetsize.h is 
>> set
>> before it is set by sys/select.h (included by stdlib.h).
>>
> 
> To be strictly correct about this, the problem is really an OpenBSD
> one.  There should not be an order dependence on the inclusion of
> system headers.  You could try logging it as a bug on OpenBSD - good
> luck with that.
> 

No, i dont think thats an OpenBSD only problem. The ordering of include
files in this authentication helper always would first include the
system headers - also on Linux, MacOS X, whatever - and then redefine
FD_SETSIZE with some own value given to configure. In my opinion this
compiler warning will be happen on most systems except the ones for
which compat/fdsetsize.h has some hacks to prevent setting FD_SETSIZE.

-- Matthias

[squid-users] [PATCH] Squid 3.1.4 not building under OpenBSD 4.6

[Silamael]

Hello!

Yesterday i tried to build the new version of Squid on OpenBSD 4.6.
Unfortunately there's some problem in src/mem.cc. new_pool_limit is of
type size_t which is a long unsigned int. In line 359 a -1 is written
into new_pool_limit. Newer g++ versions seems to accept this as valid
but OpenBSD's g++ 3.3.5 complains about it.
Attached is a small patch to fix this.

PS: Your bugzilla site seems to be down at moment. I'm just getting some
Perl error messages.

-- Matthias
gcc of OpenBSD does not like the original assignment.
Newer versions of gcc seem to have no problem.
The explicit cast fixes this error for gcc 3.3.5 in OpenBSD

--- src/mem.cc.orig Tue Jun  1 17:24:03 2010
+++ src/mem.cc  Tue Jun  1 17:24:22 2010
@@ -356,7 +356,7 @@
 else {
if (Config.MemPools.limit == 0)
debugs(13, 1, "memory_pools_limit 0 has been chagned to 
memory_pools_limit none. Please update your config");
-new_pool_limit = -1;
+new_pool_limit = static_cast(-1);
 }
 
 #if 0

Re: [squid-users] [PATCH] Squid 3.1.4 not building under OpenBSD 4.6

[Silamael]

On 06/02/2010 08:54 AM, Silamael wrote:
> Hello!
> 
> Yesterday i tried to build the new version of Squid on OpenBSD 4.6.
> Unfortunately there's some problem in src/mem.cc. new_pool_limit is of
> type size_t which is a long unsigned int. In line 359 a -1 is written
> into new_pool_limit. Newer g++ versions seems to accept this as valid
> but OpenBSD's g++ 3.3.5 complains about it.
> Attached is a small patch to fix this.
> 
> PS: Your bugzilla site seems to be down at moment. I'm just getting some
> Perl error messages.
> 
> -- Matthias

Further looked into this and for me it now just seems to be a typo.
In MemPools::setIdleLimit the argument type is ssize_t.
The new patch attached should fix this properly.

-- Matthias
Seems to be a typo. In setIdleLimit the limit value is a ssize_t.
Newer versions of gcc do not complain about this but OpenBSD's gcc does.

--- src/mem.cc.orig Wed Jun  2 12:10:25 2010
+++ src/mem.cc  Wed Jun  2 12:10:41 2010
@@ -346,7 +346,7 @@
 void
 memConfigure(void)
 {
-size_t new_pool_limit;
+ssize_t new_pool_limit;
 
 /** Set to configured value first */
 if (!Config.onoff.mem_pools)

Re: [squid-users] Build Fail for 3.1.4 on IBM PowerPC64

[Silamael]

On 06/18/2010 08:27 PM, Steve wrote:
> Hi
> I am getting a compile error with 3.1.4 on IBM Power ppc64 running Red Hat
> Enterprise Linux AS release 4 (Nahant Update 8).
> The error is :-
> mem.cc: In function `void memConfigure()':
> mem.cc:359: warning: converting of negative value `-0x1' to
> `size_t'
> 
> src/mem.cc has a change from 3.1.3 from
>>  new_pool_limit = mem_unlimited_size;
> To
> < new_pool_limit = -1;
> which seems to be the problem.
> Compiler is gcc version 3.4.6 20060404 (Red Hat 3.4.6-11).
> Thanks
> Steve
> 

Hi Steve,

That's a typo. new_pool_limit shoul be a ssize_t. I think i sent already
some patch.
Seems that our older c++ compiler are more picky about types than the
newer versions ;)

Greetings,
Matthias

[squid-users] Question about SquidGuard and blocking pages

[Silamael]

Hello!

We're using SquidGuard for blocking certain URLs. Now, the problem is
that SquidGuard redirects to some internal://.../error-access-denied
URL, but in this page this internal URL is shown as blocked URL instead
of the original URL.
Is that any configuration problem or did i stumble over some Squid bug here?

Thanks!

-- Matthias

Re: [squid-users] Question about SquidGuard and blocking pages

[Silamael]

On 07/22/2010 03:24 PM, Beavis wrote:
> looks like a config is missing. in my setup i have prepared the
> internal access-denied page and put a fqdn on use an internal dns zone
> you have to resolv it. squid does pretty good on filtering, and it
> includes filter via IP. try to have the page with url resolved to a
> zone entry you have, and try it again. if not you can always whitelist
> the url.

Hi Beavis,

sorry, i don't get it. As far as i understand the code, squid seems to
throw away the original URL and create a complete new request for the
URL returned by SquidGuard.

What do you mean with all this DNS stuff? For what i need an internal
dns zone? Sounds pretty complicated for just blocking some pages based
on the SquidGuard blacklists...

-- Matthias

Re: [squid-users] Question about SquidGuard and blocking pages

[Silamael]

On 07/24/2010 06:10 AM, Amos Jeffries wrote:
> Yes. This is why the interface is called URL re-write.
> It alters the URL being fetched in-transit to whatever the re-writer
> sends back. Squid then fetches that URL from the server in the Host:
> header or a cache_peer.
> 
> Another catch is that all the other URLs in the headers and body of the
> request are NOT re-written, which leads to clashes.

Hi Amos,

Ok, so this works as intended. No bug and no misconfiguration.
Thank you!

-- Matthias

[squid-users] OpenBSD: Compile error in tools.cc, line 70

[Silamael]

Hi there!

Yesterday i tried to compile the brand new version 3.1.6 on OpenBSD.
Got some compiler error on src/ip/tools.cc, line 70. Seems that at least
on OpenBSD the include of unistd.h is missing. If I add
#include  myself, tools.cc compiles fine.

-- Matthias

Re: [squid-users] Problem: unable to compile squid with TPROXY, broken libcap?

[Silamael]

On 08/25/2010 04:34 PM, Leonardo wrote:
> Hi all,
> 
> I am re-posting this as a separate thread so to handle one problem at once.
> 
> My aim is to use Squid with TPROXY capabilities enabled, so I am
> trying to build the latest source (3.1.6) on Debian Lenny 5.0.5:
> ./configure --enable-linux-netfilter
> 
> The build issues a warning complaining that libcap is missing;
> however, I have libcap1 and libcap2 installed and up-to-date.
> 
> Could anybody who has experience with Squid as a transparent proxy
> please give me feedback on this?

Are you sure that also the corresponding -dev packets are installed?
Perhaps you just have the libs but not the needed headers installed.

-- Matthias

Re: [squid-users] Squid 3.1.16: Startup problem on OpenBSD 4.9

[Silamael]

On 11/03/2011 03:50 PM, Silamael wrote:
> Hello!
> 
> Sometimes starting Squid in OpenBSD 4.9 fails with the following message
> in cache.log:
> 
>> diskHandleWrite: FD 10: disk write error: (14) Bad address
> 
> So far, I was unable to get some more information when enabling some
> debug options. The only bit of information I was able to gather was a
> ktrace:
> 
>> 7990 squid 1319702036.377575 CALL stat(0x3c17e4c0,0xcfbdc7d0)
>> 7990 squid 1319702036.377577 NAMI
> "/var/squid/cache/cache-127.0.0.1:24567/0F"
>> 7990 squid 1319702036.377582 RET stat 0
>> 7990 squid 1319702036.377586 CALL open(0x3c17dfc0,0x209,0x1a4)
>> 7990 squid 1319702036.377588 NAMI
> "/var/squid/cache/cache-127.0.0.1:24567/swap.state"
>> 7990 squid 1319702036.377602 RET open 10/0xa
>> 7990 squid 1319702036.377605 CALL fcntl(0xa,0x1,0)
>> 7990 squid 1319702036.377607 RET fcntl 0
>> 7990 squid 1319702036.377608 CALL fcntl(0xa,0x2,0x1)
>> 7990 squid 1319702036.377610 RET fcntl 0
>> 7990 squid 1319702036.377619 CALL stat(0x89107d80,0xcfbdc76c)
>> 7990 squid 1319702036.377622 NAMI
> "/var/squid/cache/cache-127.0.0.1:24567/swap.state"
>> 7990 squid 1319702036.377628 RET stat 0
>> 7990 squid 1319702036.377630 CALL close(0xa)
>> 7990 squid 1319702036.377632 RET close 0
>> 7990 squid 1319702036.377635 CALL open(0x82016680,0x609,0x1a4)
>> 7990 squid 1319702036.377637 NAMI
> "/var/squid/cache/cache-127.0.0.1:24567/swap.state.new"
>> 7990 squid 1319702036.377647 RET open 10/0xa
>> 7990 squid 1319702036.377649 CALL fcntl(0xa,0x1,0)
>> 7990 squid 1319702036.377651 RET fcntl 0
>> 7990 squid 1319702036.377653 CALL fcntl(0xa,0x2,0x1)
>> 7990 squid 1319702036.377655 RET fcntl 0
>> 7990 squid 1319702036.377659 CALL write(0xa,0x8a624fd0,0x34)
>> 7990 squid 1319702036.377682 RET write -1 errno 14 Bad address
>> 7990 squid 1319702036.377694 CALL
> mmap(0,0x1000,0x3,0x1002,0x,0,0,0)
>> 7990 squid 1319702036.377698 RET mmap -2101538816/0x82bd1000
>> 7990 squid 1319702036.377705 CALL gettimeofday(0x3c15cdb8,0)
>> 7990 squid 1319702036.377708 RET gettimeofday 0
>> 7990 squid 1319702036.377712 CALL write(0x3,0x7e7dd000,0x50)
>> 7990 squid 1319702036.377714 GIO fd 3 wrote 80 bytes
>> "2011/10/27 09:53:56| diskHandleWrite: FD 10: disk write error: (14)
> Bad address"
>> 7990 squid 1319702036.377716 RET write 80/0x50
> 
> The error is unfortunately hard to reproduce. One of about 10 startups
> the problem occurs.
> 
> Thanks for any advice!
> 
> Greetings,
> Matthias

Hi!

It seems this problem also existed before 3.1.16. Today i compiled and
tested the previous version of Squid and encountered the same problem once.

Greetings,
Matthias

Re: [squid-users] Squid 3.1.16: Startup problem on OpenBSD 4.9

[Silamael]

On 11/03/2011 05:34 PM, Silamael wrote:
> On 11/03/2011 03:50 PM, Silamael wrote:
>> Hello!
>>
>> Sometimes starting Squid in OpenBSD 4.9 fails with the following message
>> in cache.log:
>>
>>> diskHandleWrite: FD 10: disk write error: (14) Bad address

Hello together,

I think i found the cause of said problems when starting squid and filed
a new bug: http://bugs.squid-cache.org/show_bug.cgi?id=3408

Greetings,
Matthias

Re: [squid-users] Problem compiling Squid 3.1.18 on Ubuntu 10.04 LTS - store.cc

[Silamael]

On 12/06/2011 04:09 AM, Amos Jeffries wrote:
> It is only affecting adaptation (ICAP/eCAP) builds, so if you can run
> happily without those features use --disable, or comment out line 376 of
> src/store.cc.
> 
> 
> Thank you for the testing offer. We can replicate it already so the only
> help needed is C++ familiar eyes to find which of this nested set of
> templates is missing a required print() operator.
> 
> Amos

Hi,

I can confirm this problem with ICAP enabled for OpenBSD too. The fix
suggested fixes the compilation.

Greetings,
Matthias

[squid-users] Question about refresh_pattern and TCP_MEM_HIT

[Silamael]

Hello,

I have a simple question about refresh_pattern and TCP_MEM_HIT.
Given the following configuration:

refresh_pattern foo.example.org 0 0% 0
refresh_pattern . 0 20% 14400

Now, if i fetch something from foo.example.org i get a
TCP_CLIENT_REFRESH_MISS/200
The following request for the same url is shown in the squid.log with
TCP_MEM_HIT/200.
If i understand this correctly the TCP_MEM_HIT means that squid did not
reload the requested url but served the request with the object still in
memory, isn't it?
If so, I'm wondering why this url is kept in the memory cache. The
refresh_pattern above should prevent this case and force squid to reload
the asked object every time.

So, what's the explanation for this behaviour?

Thanks in advance!

-- Matthias

Re: [squid-users] Question about refresh_pattern and TCP_MEM_HIT

[Silamael]

On 09/19/2012 02:12 AM, Amos Jeffries wrote:
> On 19/09/2012 9:10 a.m., Eliezer Croitoru wrote:
>> On 9/18/2012 6:01 PM, Silamael wrote:
>>> refresh_pattern foo.example.org 0 0% 0
>>> refresh_pattern . 0 20% 14400
>>>
>>> Now, if i fetch something from foo.example.org i get a
>>> TCP_CLIENT_REFRESH_MISS/200
>>> The following request for the same url is shown in the squid.log with
>>> TCP_MEM_HIT/200.
>>> If i understand this correctly the TCP_MEM_HIT means that squid did not
>>> reload the requested url but served the request with the object still in
>>> memory, isn't it?
>>> If so, I'm wondering why this url is kept in the memory cache. The
>>> refresh_pattern above should prevent this case and force squid to reload
>>> the asked object every time.
>>>
>>> So, what's the explanation for this behaviour?
>>>
>>> Thanks in advance!
>> The refresh_pattern is regex which might just not match all your request.
>> if you do not want to cache you dont change the refresh_pattern to
>> 0... but use the:
>> cache deny acl
> 
> refresh_pattern is *only* a set of default values to apply in absence of
> cache-control and expiry headers from the server for Squid to use to
> determine staleness on followup requests.
> 
> This is why the default (/cgi-bin/|\?) pattern with all zeros is
> recommended for use on dynamic content. It defaults to not caching
> *unless* the server provides proper caching headers. In which case it is
> safe to cache.
> 
> I would say from that description that your requested resource response
> contains all the required HTTP/1.1 headers to permit and specify both
> cacheing and expiry limitations on the tested URL.
> 
> Amos

Ok, so if a response contains valid headers concerning caching, these
are taken instead of using the matching refresh_pattern? So, if i want
some URLs being served completely without caching, i have to use cache
deny, right?

-- Matthias

Re: [squid-users] Question about refresh_pattern and TCP_MEM_HIT

[Silamael]

On 09/19/2012 10:12 AM, Amos Jeffries wrote:
> On 19/09/2012 6:51 p.m., Silamael wrote:
>>
>> Ok, so if a response contains valid headers concerning caching, these
>> are taken instead of using the matching refresh_pattern? So, if i want
>> some URLs being served completely without caching, i have to use cache
>> deny, right?
> 
> Yes. Exactly so.
> 
> Amos

Thank you for the explanation Amos!

-- Matthias

Re: [squid-users] WARNING: no_suid: setuid(0): (1) Operation not permitted

[Silamael]

On 02/01/2013 01:09 AM, Amos Jeffries wrote:
> Hmm. Yes the warning is new since we started adding debugs() about
> failed system calls to display reviously hidden system errors.
> 
> Looking at all the documentation about setuid() and seteuid() I'm
> wondering if this was supposed to be seteuid(0) - to clear any
> effective-user restrictions before dropping privileges down to the
> low-privileges UID.
> 
> I'm also wondering if setuid(uid) was done earlier and the low-privilege
> user is what is being dened the setuid(0) - but I can't see any sign of
> the "Dropping privileges" message that should appear first. Can one of
> you start your Squid with level-3 debug and see where in this startup
> list the dropping message appears?
> 
> There is also http://bugs.squid-cache.org/show_bug.cgi?id=3751 involved
> with this somehow.
> 
> 
> Amos

Just for the record, I see the same warning under OpenBSD. As far is i
read the sources it seems to happen when the helpers are started. I
think it's the call of no_suid() in ipcCreate in ipc.cc.

-- Matthias

[squid-users] Squid 3.2: squid -z forking?

[Silamael]

Hi!

I just noticed that the squid -z command seems to fork and the child is
creating the cache directories. The parent immediatly returns with exit
code 0. There's a race for cases like: squid -z; squid
Is this behaviour intended?

Greetings,
Matthias

Re: [squid-users] Squid 3.2: squid -z forking?

[Silamael]

On 02/06/2013 02:05 AM, Amos Jeffries wrote:
> Partially. The parent returning immediately is not agood thing. BUT, 
> "squid -z ; squid" is not a good way to do things even if it did. If
> that were possible we would simply have made squid startup perform the
> -z operations by default.
> 
> squid -z is a create operation pure and simple. The manual way to create
> directories before the *first* time you run Squid.
> 
> squid -z will create missing directories. BUT, does not ensure they are
> valid if already existing.
> Also, for some storage types they will create by destroying existing
> content. That was a bug and we are working on the fix.

Hi Amos!

Will this fix or another one include that the parent process does not
return until the cache initialization is done?
Or is the said fix just addressing the problem that the initialization
would destroy the already existing cache in certain cases?

-- Matthias

Re: [squid-users] Squid 3.2: squid -z forking?

[Silamael]

On 02/06/2013 10:42 PM, Alex Rousskov wrote:
> Yes, it is. In old Squids, -z implied no-daemon mode. Then folks wanted
> to use SMP macros in their configurations, including their cache_dir
> lines. Those macros require SMP mode (each Squid kid gets its own set of
> macro values) so we removed that implication. IIRC, there was a bug
> report and/or a squid-dev thread discussing this choice and the
> alternatives. In other words, this change and its backward
> incompatibility were not accidental.
> 
> Technically, it would be possible to revert -z to no-daemon mode if and
> only if there are no SMP macros (or similar SMP dependencies) in the
> configuration file, but there is currently no patch implementing that
> feature.
> 
> 
> FWIW, neither rock nor ufs-based cache_dirs themselves require daemon
> mode for initialization. However, if your cache_dirs use SMP macros for
> directory names (and most ufs-based cache_dirs do), then daemon mode is
> required.
> 
> 
>> There's a race for cases like: squid -z; squid
> 
> If you want squid to block (i.e., prevent the parent process from
> exiting immediately), and your configuration allows cache_dir
> initialization without SMP, then start Squid in no-daemon mode using the
> -N command line option:
> 
> squid -z -N
> 
> If that does not work, please file a bug report.
> 
> 
> If your configuration does not allow blocking cache_dir initialization,
> then you need to adjust your startup script to wait for the Squid daemon
> to exit.

Hi Alex!

Thank you for the clarification. We don't need these new SMP macros so I
can use the -N option. Works like intended now.

Greetings,

Matthias

[squid-users] Squid 3.2: Mismatch of code and release notes for ACL types

[Silamael]

Hi there!

I just stumbled over the part in the release notes where it's said that
the ACL types myip and myport have been renamed to localip and
localport. But these new types do not work! In the source code it's
still myip and myport.

Greetings,
Matthias

[squid-users] Question about forward.cc and possible patch

[Silamael]

Hi there!

Last week we had a problem that a cache peer's DNS resolved to 13 v6 and
13 v4 addresses but the system lacked IPv6 connectivity at all. While
debugging the problem (the solution was just to increase
forward_max_tries) I stumbled over a line in forward.cc where n_tries is
always checked against the constant value of 10 (which is the default
for forward_max_tries). At another line of code n_tries is checked
against the value for forward_max_tries from the configuration file.
The attached patch fixes the first line so that the check is also done
against the configured forward_max_tries value.

Greetings,
Matthias
--- src/forward.cc.orig Tue May  7 08:08:31 2013
+++ src/forward.cc  Tue May  7 08:24:41 2013
@@ -514,7 +514,7 @@ FwdState::checkRetry()
 if (!entry->isEmpty())
 return false;
 
-if (n_tries > 10)
+if (n_tries > Config.forward_max_tries)
 return false;
 
 if (origin_tries > 2)

Re: [squid-users] Question about forward.cc and possible patch

[Silamael]

On 05/13/2013 10:22 AM, Amos Jeffries wrote:
> Please submit your change for audit:
>  http://wiki.squid-cache.org/MergeProcedure#Submission_Format
> 
> Amos

Done :)

[squid-users] Squid 3.1.8: Removing cache_dir + SIGHUP --> disk cache still in use

[Silamael]

Hello,

I just debugged something i think it probably not working as intended:
I start Squid with some cache_dir option in its configuration file.
Afterwards i remove the cache_dir line from the config and send Squid a
SIGHUP (or do squid -k reconfigure).
When accessing further URLs after this, i see that Squid still is
creating new files in its disk cache although the disk cache is no
longer configured in the configuration file.

So, my question: is this working as intended or have i stumbled over
some reconfiguration bug not disabling the disk cache on the
reconfiguration?

Thanks in advance!

-- Matthias

[squid-users] Squid 3.1.11 compilation problem on OpenBSD 4.9

[Silamael]

I together,

When compiling Squid 3.1.11 on the current OpenBSD, i get an error
because netinet/in.h is not included in include/util.h before including
arpa/inet.h.

Attached is a simple patch fixing this issue.

-- Matthias
--- include/util.h.orig Thu Mar  3 14:04:15 2011
+++ include/util.h  Thu Mar  3 14:02:14 2011
@@ -46,6 +46,7 @@
 #include 
 #endif
 #if HAVE_ARPA_INET_H
+#include 
 #include 
 #endif
 

Re: [squid-users] Fwd: squid-3.2.0.6 - make issue on OpenBSD 4.8 - 64 bit

[Silamael]

On 04/05/2011 12:05 PM, Indunil Jayasooriya wrote:
> Hi ALL,
> 
> I downloaded squid-3.2.0.6 from below URL
> 
> http://www.squid-cache.org/Versions/v3/3.2/squid-3.2.0.6.tar.gz
> 
> 
> I ran (this is on OpenBSD 4.8 - 64 bit)
> 
> ./configure
> 
> It went fine.
> 
> Then, ran
> 
> make
> 
> stoped at below error
> 
> 
> /usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside
> parameter list
> /usr/include/arpa/inet.h:74: warning: its scope is only this
> definition or declaration, which is probably not what you want
> /usr/include/arpa/inet.h:75: warning: 'struct in_addr' declared inside
> parameter list
> *** Error code 1
> 
> Stop in /root/software/squid-3.2.0.6/lib (line 589 of Makefile).
> *** Error code 1
> 
> Stop in /root/software/squid-3.2.0.6/lib (line 708 of Makefile).
> *** Error code 1
> 
> Stop in /root/software/squid-3.2.0.6 (line 433 of Makefile).

Hi Indunil,

The problem is that netinet/in.h must be included before arpa/inet.h in
include/util.h (at least for 3.1.11). Just add
#include  before the #include  line in this
file. At least that fixed the same problem with Squid 3.1.11 on OpenBSD 4.9.

-- Matthias

[squid-users] Question about Connection: keep-alive and Proxy-Connection: keep-alive

[Silamael]

Hello there,

We have some application encountering problems if it's communicating via
Squid:
- the application sends a HTTP/1.1 HEAD-Request with Proxy-Connection:
keep-alive set
- Squid then forwards the request to the server with Connection: keep-alive
- the server replies with the headers and a Connection: close header -
Squid returns the response with only Proxy-Connection: keep-alive to the
client which afterwards hangs

Is that the correct behavior or have we encountered a problem with Squid
itself?
Thanks for your answers!

Greetings,
Matthias

[squid-users] Squid 3.1.16: Startup problem on OpenBSD 4.9

[Silamael]

Hello!

Sometimes starting Squid in OpenBSD 4.9 fails with the following message
in cache.log:

> diskHandleWrite: FD 10: disk write error: (14) Bad address

So far, I was unable to get some more information when enabling some
debug options. The only bit of information I was able to gather was a
ktrace:

> 7990 squid 1319702036.377575 CALL stat(0x3c17e4c0,0xcfbdc7d0)
> 7990 squid 1319702036.377577 NAMI
"/var/squid/cache/cache-127.0.0.1:24567/0F"
> 7990 squid 1319702036.377582 RET stat 0
> 7990 squid 1319702036.377586 CALL open(0x3c17dfc0,0x209,0x1a4)
> 7990 squid 1319702036.377588 NAMI
"/var/squid/cache/cache-127.0.0.1:24567/swap.state"
> 7990 squid 1319702036.377602 RET open 10/0xa
> 7990 squid 1319702036.377605 CALL fcntl(0xa,0x1,0)
> 7990 squid 1319702036.377607 RET fcntl 0
> 7990 squid 1319702036.377608 CALL fcntl(0xa,0x2,0x1)
> 7990 squid 1319702036.377610 RET fcntl 0
> 7990 squid 1319702036.377619 CALL stat(0x89107d80,0xcfbdc76c)
> 7990 squid 1319702036.377622 NAMI
"/var/squid/cache/cache-127.0.0.1:24567/swap.state"
> 7990 squid 1319702036.377628 RET stat 0
> 7990 squid 1319702036.377630 CALL close(0xa)
> 7990 squid 1319702036.377632 RET close 0
> 7990 squid 1319702036.377635 CALL open(0x82016680,0x609,0x1a4)
> 7990 squid 1319702036.377637 NAMI
"/var/squid/cache/cache-127.0.0.1:24567/swap.state.new"
> 7990 squid 1319702036.377647 RET open 10/0xa
> 7990 squid 1319702036.377649 CALL fcntl(0xa,0x1,0)
> 7990 squid 1319702036.377651 RET fcntl 0
> 7990 squid 1319702036.377653 CALL fcntl(0xa,0x2,0x1)
> 7990 squid 1319702036.377655 RET fcntl 0
> 7990 squid 1319702036.377659 CALL write(0xa,0x8a624fd0,0x34)
> 7990 squid 1319702036.377682 RET write -1 errno 14 Bad address
> 7990 squid 1319702036.377694 CALL
mmap(0,0x1000,0x3,0x1002,0x,0,0,0)
> 7990 squid 1319702036.377698 RET mmap -2101538816/0x82bd1000
> 7990 squid 1319702036.377705 CALL gettimeofday(0x3c15cdb8,0)
> 7990 squid 1319702036.377708 RET gettimeofday 0
> 7990 squid 1319702036.377712 CALL write(0x3,0x7e7dd000,0x50)
> 7990 squid 1319702036.377714 GIO fd 3 wrote 80 bytes
> "2011/10/27 09:53:56| diskHandleWrite: FD 10: disk write error: (14)
Bad address"
> 7990 squid 1319702036.377716 RET write 80/0x50

The error is unfortunately hard to reproduce. One of about 10 startups
the problem occurs.

Thanks for any advice!

Greetings,
Matthias

[squid-users] Squid 3.1 Release Date

[Silamael]

Hello there!

Is there any date when Squid 3.1 will be official released?
Thanks in advance!

-- Matthias

Re: [squid-users] Squid 3.1 Release Date

[Silamael]

Francois Cami wrote:
> On Tue, Mar 3, 2009 at 8:32 AM, Silamael  wrote:
>> Is there any date when Squid 3.1 will be official released?
>> Thanks in advance!
> 
> http://wiki.squid-cache.org/ReleaseProcess#head-eea0e990c0003af12917552175691a5120980cdd
> 

Thanks for the reply but this doesn't answer my question.
I now that Squid 3.1 is already released in X.Y.0.z. I just wanted to
know if there is any planned date. If you say, most likely in April,
that's already enough. Just need an approximate date for some internal
plannings.

-- Matthias

Re: [squid-users] Squid 3.1 Release Date

[Silamael]

Amos Jeffries wrote:
> We don't exactly date things here. With everyone working on voluntary
> time its unpredictable. Though there has been a fairly regular 4-week
> cycle for new X.Y.0.z beta releases.
> 
> For planning and upgrade testing, 3.1.0.6 is a fairly stable point to
> begins with.
> 
> Back before we/I decided to adopt the fluid feature inclusion we had a
> set of approved features for 3.1. The last of these given a guarantee of
> being in 3.1 is still grinding it's way through testing (far too
> slowly). I expect that will take us through March and maybe April before
> 3.1 gets a chance of even starting the stable waiting period.
> 
> There is also a short list of RC bugs which we consider major enough to
> need fixing before we call it stable.
> Many of these bugs are only confirmed to exist in 3.0. But they are
> serious enough that we really NEED someone who can see them in 3.0 to
> test 3.1 and confirm they are not still hiding.
> 
> Last time I had to guesstimate a timeline I said mid-year (june/july)
> 2009, I've seen no reason to change it for better or worse yet.
> 
> Amos

Thank you for your answer Amos. This is exactly what i wanted to know.

-- Matthias

[squid-users] Using DNSSEC in Squid

[Silamael]

Hello!

Is there any possibility at moment to use DNSSEC in Squid?
We want to present a special error page if a DNS answer is received
which fails the DNSSEC check.
Are there any built-in features, patches or anything else to realize this?
Thanks in advance!

Greetings,
Matthias

[squid-users] Running Squid 3.1.0.7 without disk cache

[Silamael]

Hello,

Is there a possibility to run Squid without using a disk cache?
Former versions had the null module for storeio which could be used for
that. Now there is no such null module.
Thanks in advance!

-- Matthias

Re: [squid-users] Running Squid 3.1.0.7 without disk cache

[Silamael]

Amos Jeffries wrote:
>> Hello,
>>
>> Is there a possibility to run Squid without using a disk cache?
>> Former versions had the null module for storeio which could be used for
>> that. Now there is no such null module.
>> Thanks in advance!
> 
> Running without disk cache is now the default :)
> 
> A Squid-3.1 squid.conf that contains no cache_dir entries will use
> cache_mem for caching in RAM and nothing else.
> 
> Amos


Thank you for the quick answer Amos. Then i will adjust our conig
generator accordingly.

Greetings,
Matthias

[squid-users] Question about: Changes to squid-cache.org FTP servers

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello there,

Will the paths on the HTTP-Server also change?

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpKKn0ACgkQGgHcOSur6dRwKQCcCTqqLNuUOu7X9YOYHpiDWvbu
igMAnj/xS44h5SmZM5tGa64IL7kryyUl
=9Xrh
-END PGP SIGNATURE-

Re: AW: AW: [squid-users] Squid 3.1.0.11 beta is available

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Zeller, Jan wrote:
> Hi Amos,
> 
> thank you very much for your patch ! Great ! 
> Applied it like this :
> 
> $ patch -p0 < b9052.patch 
> patching file src/client_side.cc
> Hunk #1 succeeded at  (offset 81 lines).
> 
> $ make && make install - this time is successful but now I get :
> 
> squid-3.1.0.11/sbin# ./squid -k check -f /etc/squid3/squid.conf-3.1.0.11 
> 2009/07/20 14:38:43| assertion failed: mem.cc:236: "size == 
> StrPoolsAttrs[i].obj_size"
> Aborted
> 
> Any ideas ?
> 
> kind regards,
> 
> Jan

I have the same problem under OpenBSD 4.4.

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpld0cACgkQGgHcOSur6dS2OQCdG4JmIQFVrdIfv3RKPyP/BRtR
8KMAniSHZfmbj+3GJqRZlOOWYu9PnCsQ
=QdIz
-END PGP SIGNATURE-

Re: AW: AW: AW: AW: AW: [squid-users] Squid 3.1.0.11 beta is available

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Zeller, Jan wrote:
> Hi Amos,
> 
> I now explicitly enabled 
> 
> --enable-stacktraces Enable automatic call backtrace on fatal errors
> 
> during the build and added CFLAGS="-g -ggdb" in front of ./configure 
> but the result seems to be the same...
> 
> # ./squid -v
> Squid Cache: Version 3.1.0.11
> configure options:  '--prefix=/opt/squid-3.1.0.11' '--enable-icap-client' 
> '--enable-ssl' '--enable-linux-netfilter' '--disable-ipv6' 
> '--disable-translation' '--disable-auto-locale' '--with-pthreads' 
> '--with-filedescriptors=32768' '--enable-stacktraces' 'CFLAGS=-g -ggdb' 
> --with-squid=/usr/local/src/squid-3.1.0.11 --enable-ltdl-convenience
> 2009/07/21 15:43:50| assertion failed: mem.cc:236: "size == 
> StrPoolsAttrs[i].obj_size"
> Aborted
> 
> # gdb --args ./squid -NCXd9
> GNU gdb 6.8-debian
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu"...
> (gdb) bt
> No stack.
> (gdb) quit
> 

You forgot to tell gdb to run the program.
# gdb --args ./squid -NCXd9
start gdb and tell it to use -NCXd9 as arguments for squid
When you get the gdb prompt, enter:
(gdb) r
which will run squid. When it crashes you type
(gdb) bt
to get the backtrace. If squid does not crash, typing bt is pretty
useless. Same, if it even didn't run before ;)

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpl0pYACgkQGgHcOSur6dRRagCfQpDfLaFqg1mLwJCVTcAUJRWP
R+oAn2LnoLTxNJV6+YX+Q8Ja8ILUHayl
=JhHL
-END PGP SIGNATURE-

[squid-users] Squid 3.1.0.12: assertion failed in http.cc, line 705: !eof

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello together,

Squid 3.1.0.12 runs pretty well except this assertion problem i've also
seen on the mailing list for Squid 3.0 Stable17.
Every time the assertion fails, before following is logged:
> ... HttpMsg.cc(157) parse: first line of HTTP message is invalid

Is there any patch i can apply to Squid version 3.1.0.12 to fix this
problem?

Thanks in advance!

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkp3CfYACgkQGgHcOSur6dSqowCfV1PYSv0WsmVGynTXhORNdVWa
KXgAoKDJQyB0wls26BVpEchIM8kkwYkH
=3+F6
-END PGP SIGNATURE-

Re: [squid-users] Squid crashes - Create Bugreport?

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas Jackowski wrote:
> Hi,
> 
> Squid crashes with this message in cache.log:
> 
> 2009/08/11 06:54:31| assertion failed: store_client.cc:430:
> "STORE_DISK_CLIENT == getType()"
> 2009/08/11 06:54:35| Starting Squid Cache version 3.0.STABLE8 for
> x86_64-pc-linux-gnu...
> 
> OS: Debian Lenny
> Squid Version: 3.0STABLE8-3+lenny2
> 
> Is there a chance that this bug is fixed in newer Verions of Squid3(not
> the Debian Package) or is the problem elsewhere?
> 
> Please tell me what informations I should provide to you :)

As Debian Lenny contains only 3.0STABLE8 and the bug is said to be fixed
 in 3.0STABLE18 i would suggest to file a bug report for the Debian
package so the maintainer can backport the fix for this problem into the
Debian package.

For Squid itself there is the already closed bug:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2155

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqBOfUACgkQGgHcOSur6dR85ACbB8zY+/pBHAAw8nCn/p85+yE4
ZrcAoJ5AF+iL+XIdvLwYF/J15uNjxA7Q
=nVYB
-END PGP SIGNATURE-

[squid-users] Squid 3.1.0.13: assertion failed: src/store_client.cc:430: "STORE_DISK_CLIENT == getType()"

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello everyone,

We're running Squid version 3.1.0.12 with the fix for the DoS
vulnerability applied and have from time to time crashes due to this
assertion:
assertion failed: src/store_client.cc:430: "STORE_DISK_CLIENT == getType()"

I searched in Squids Bugzilla and only found the Bug#2155 which is
marked as resolved fixed.
Can anyone confirm that this problem got fixed in version 3.1.0.13?

Thanks in advance!

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqbfIEACgkQGgHcOSur6dRIwgCgzW/cd3Bd3kyBsYn6CqMYTunZ
JBQAn20Zvg4AjKqkRXkETt92doOKXnql
=M+mD
-END PGP SIGNATURE-

[squid-users] Squid 3.1.12 - Parent Proxy and DNS queries

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello everyone!

We're running a Squid version 3.1.12 with a cache peer configured.
Furthermore Squid is configured to forward every request directly to the
cache peer. Nevertheless Squid is doing a DNS query for every requests
received. At this point only internal hostnames can be resolved so
resolving any internet hostname will fail.
This causes Squid to wait 2 minutes (default timeout for DNS requests)
before the request is finally forwarded to the parent proxy.
Is this a bug in Squid or some change in the default behaviour since
2.6? The same configuration works as intended in 2.6.

Thank you for any advice!

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqxAiMACgkQGgHcOSur6dTTTwCbB6QK/gNqDzSzZo/UzwArr1RO
pkwAnj/82cc+rsarGnR+MG1Od0iFuPx/
=R5me
-END PGP SIGNATURE-

Re: [squid-users] Squid 3.1.12 - Parent Proxy and DNS queries

[Silamael]

Amos Jeffries wrote:
> This is usually a configuration problem.
> 
> Please provide your squid.conf file contents (minus empty and comment
> lines)
> 
> Amos

Hello Amos,

Here is our configuration.
Thank you for your help.

-- Matthias
#
# WARNING: Do not edit this file, it has been automatically generated.
#
# Prepends
append_domain .domain.de
unlinkd_program /usr/local/libexec/unlinkd
ipcache_high 95
icp_port 0
ipcache_size 1024
http_port 127.0.0.1:8000
cache_dir ufs /var/squid/cache/cache-8000 100MB 8 16
debug_options ALL,1
server_persistent_connections on
cache_swap_high 95
log_ip_on_direct off
maximum_object_size 2 KB
minimum_direct_hops 4
udp_incoming_address 127.0.0.1
pid_filename /var/squid/logs/squid-8000.pid
ftp_user sq...@domain.de
forwarded_for off
cache_access_log /var/squid/logs/access-8000.log
visible_hostname domaind193.domain.de
client_persistent_connections on
cache_swap_low 90
logfile_rotate 0
ipcache_low 90
cache_effective_user _squid
cache_log /var/squid/logs/cache-8000.log
cache_effective_group _squid
hosts_file none
refresh_pattern . 0 20% 14400
cache_mem 8 MB
cache_store_log none
hierarchy_stoplist cgi-bin ?
error_directory /usr/local/share/squid/errors/de
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl localdomain srcdomain domain.de
acl localdst dstdomain .domain.de
acl localhost-dst dst 127.0.0.1/32
# user defined ACLs
always_direct deny all
refresh_pattern .domain.de 0 1% 0
refresh_pattern www.domain.de 0 1% 0
cache_peer 10.254.0.17 parent  0 default no-query
always_direct allow localdst
never_direct allow all

# Authentication

# User options

# Append
acl Dangerous_ports port 7 9 19
acl CONNECT method CONNECT
http_access deny Dangerous_ports
http_access deny manager !localhost
acl SSL_ports port 443 563 881
http_access deny CONNECT !SSL_ports
http_access deny localhost-dst
http_access allow all

Re: [squid-users] Squid 3.1.12 - Parent Proxy and DNS queries

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Silamael wrote:
> Amos Jeffries wrote:
>> This is usually a configuration problem.
>>
>> Please provide your squid.conf file contents (minus empty and comment
>> lines)
>>
>> Amos


No one has some idea what's wrong with our configuration?

- --Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq2AsMACgkQGgHcOSur6dQTZgCgn/O8WK5nXbbtmD4/HORnqFea
p/MAnj8V2eIJ+nsWgo3uOrlQp7VvKdva
=3UQx
-END PGP SIGNATURE-

Re: [squid-users] Squid 3.1.12 - Parent Proxy and DNS queries

[Silamael]

Amos Jeffries wrote:
> ... 
>anything resolving to 127.0.0.1 on this host is not necessarily
> resolving to 127.0.0.1 on any other host (ie the parent proxy)
> 
> NP: having a DNS server resolve 127.0.0.1 for anything public is very
> nasty.

Hi Amos,

Thank you for your help. Meanwhile i did some more testing and found
something strange. The test system cannot resolve any internet domains
itself so its nameserver uses a forwarder. If i silently drop the DNS
request packets through the packet filter, everything works fine. There
is no delay on any requests.
But, if i just remove the forwarder in DNS, so that every request for
external domains result in a NXDOMAIN DNS reply, a request takes about
90 seconds until it's finally processed.
The point i don't understand is, why Squid forwards the request without
any DNS reply but seems to do some timeout handling if NXDOMAIN is replied?
I also checked if there is any communcation between local squid and the
parent proxy but there isn't any in the latter test case.

Greetings,
Matthias

Re: [squid-users] Squid 3.1.12 - Parent Proxy and DNS queries

[Silamael]

Amos Jeffries wrote:
> That seems very strange. Very strange.
> 
> Squid using internal DNS resolver sends out UDP packets and waits for a
> reply positive or negative. Using that.
> 
> The NXDOMAIN results make sense if we assume they come back with some
> TTL so short Squid needs to run through the DNS timeouts on every request.
> 
> The silent drop case is a head scratcher of a puzzle. That is the one
> that should be getting very long timeouts while Squid waits for a reply
> that will never arrive.
> 
> 
> Anyway, getting rid of the "dst" ACL and making sure the peer is
> configured with an IP address should prevent any DNS lookups.
> IIRC your config already has the log_fqdn setting turned off.
> 
> Amos

Hello Amos,

My last assumption was wrong. It seems that there is some "optimization"
 in the kernel so that a silent drop of packets is handled the same as a
drop with ICMP packet. Therefore the named replied a lot faster than
usual with SERVFAIL.
Nevertheless, we're going to remove the dst-ACL which is not needed in
this case.
Thank you for your help!

-- Matthias

[squid-users] Squid 3.1: ICAP and Round Robin for ICAP Services

[Silamael]

Hello together,

Is there any possiblity to realize a round robin scheduling for requests
sent to ICAP services? Goal is to forward each HTTP request to the next
available ICAP service due to load balancing issues.
As far as i read the configuration manual, there is no option to to
this. Can this behavior somehow realized by some sophisticated ACLs or
some such?
Thanks in advance!

-- Matthias

Re: [squid-users] Squid 3.1: ICAP and Round Robin for ICAP Services

[Silamael]

Silamael wrote:
> Hello together,
> 
> Is there any possiblity to realize a round robin scheduling for requests
> sent to ICAP services? Goal is to forward each HTTP request to the next
> available ICAP service due to load balancing issues.
> As far as i read the configuration manual, there is no option to to
> this. Can this behavior somehow realized by some sophisticated ACLs or
> some such?
> Thanks in advance!
> 
> -- Matthias

No ideas or is it just impossible to do with Squid? If the latter i
perhaps have to add this functionality into Squid myself...

The point because i need this is that we are currently running a setup
using Squid 2.5 with the ICAP patch and that patch has the functionality
of scheduling the requests to all configured ICAP servers.

-- Matthias

Re: [squid-users] Squid-3.1: comm_open: socket failure: (97) Address family not supported by protocol

[Silamael]

Amos Jeffries wrote:
> You have IPv6 disabled in your system somehow.
> 
> Squid opens IPv4/IPv6 hybrid sockets to receive and send both v4 and v6
> traffic in one socket for simplicity and ease of transition. If that fails
> like in your case it falls back to IPv4-only sockets.
> 
> I recommend re-enabling IPv6 socket capability in your OS.
> 
> If you have OpenBSD or MacOSX they do not support these hybrid socket
> features at all. I'm still working on getting support for their
> 'split-stack'. So they will work very slightly better for now with IPv6
> disabled in Squid.
> 
> Amos

What are the plans here? I just tried to run Squid 3.1.0.14 on OpenBSD
4.6 with IPv6 enabled. I get:
> 2009/10/14 09:34:18| comm_open: setsockopt(IPV6_V6ONLY) on FD 15: (22)
> Invalid Argument
So, is IPv6 currently not usable under OpenBSD at all? Or do i have to
set some special compile options?

-- Matthias

Re: [squid-users] Problem with cache_peer - cannot open websites

[Silamael]

On 11/16/2009 01:45 PM, Werner Müller wrote:

The Problem is, that i cannot reach a Server over the IP:

with this cache_peer entry i get a failure:
cache_peer 1.1.1.1 parent 3128 0 default no-query no-digest

The localhost entry was only a test. But it's very strange that it
works with the localhost entry (localhost 1.1.1.1) and if i change the
cache_peer entry in squid.conf it will not work.


Here the entries from cache.log:
...
| TCP connection to 1.1.1.1 (1.1.1.1:3128) failed
  Detected DEAD Parent: 1.1.1.1
| TCP connection to 1.1.1.1 (1.1.1.1.1:3128) failed
| temporary disabling (Gateway Time-out) digest from 1.1.1.1
  TCP connection to 1.1.1.1 (7.21.32.137:3128) failed
...

(I changed the real IP for this post to 1.1.1.1)


Hm, that must not be a Squid specific problem. Can you reach the server 
manually? Works a telnet on the other server on port 3128?


-- Matthias

[squid-users] Squid 3.1.0.14: ICAP REQMOD - Not returning 403 error page to client

[Silamael]

Hello together!

We're using the ICAP interface of Squid for some request filtering.
When the ICAP server denies access to a page, it responds with an 403 
HTTP return code and some error page. Squid only forwards the return 
code to the client but the body of the response is not forwarded.

Is this intended, a bug or just an error in the configuration?

Kind regards,
Matthias

Re: [squid-users] Squid 3.1.0.14: ICAP REQMOD - Not returning 403 error page to client

[Silamael]

On 11/18/2009 01:59 AM, Amos Jeffries wrote:

Maybe yes, maybe no

  What configuration are you referring too?
  Is the ICAP server setting Content-Length correctly to the size of the
  error page body?


Hello Amos,

As far as i can say, the Content-Length is set properly. I have some 
simple test working as intended with an ancient Squid 2.5 + ICAP patch.

Configuration for ICAP is quite simple:
> icap_enable on
> icap_service icap_server reqmod_precache 0 icap:///
> adaption_service_set class_1 icap_server
> adaption_access class_1 allow all

In the debug output for ICAP i cannot see any errors or some hint that 
the Content-Length in the response body is set wrong.

If needed i can provide the debugging output.

-- Matthias

Re: [squid-users] Squid 3.1.0.14: ICAP REQMOD - Not returning 403 error page to client

[Silamael]

On 11/18/2009 08:22 AM, Silamael wrote:

On 11/18/2009 01:59 AM, Amos Jeffries wrote:

Maybe yes, maybe no

What configuration are you referring too?
Is the ICAP server setting Content-Length correctly to the size of the
error page body?


Hello Amos,

As far as i can say, the Content-Length is set properly. I have some
simple test working as intended with an ancient Squid 2.5 + ICAP patch.
Configuration for ICAP is quite simple:
 > icap_enable on
 > icap_service icap_server reqmod_precache 0 icap:///
 > adaption_service_set class_1 icap_server
 > adaption_access class_1 allow all

In the debug output for ICAP i cannot see any errors or some hint that
the Content-Length in the response body is set wrong.
If needed i can provide the debugging output.

-- Matthias


Hello Amos,

I found out that my test creates an invalid Encapsulated header. After
fixing it, squid dies with an assertion failure in BodyPipe::undoCheckout().
Attached you find the cache.log of my test.

Greetings,
Matthias
starting 'build-i386/src/squid -f /var/tmp/t_23908/etc/squid/squid-127.0.0.1:18190.conf -N' DEBUGINC=
2009/11/23 09:15:16| WARNING cache_mem is larger than total disk cache space!
2009/11/23 09:15:16| Starting Squid Cache version 3.1.0.14 for i386-unknown-openbsd4.4...
2009/11/23 09:15:17.037| squid-3.1.0.14/src/adaptation/Config.cc(91) finalize: Found 1 service configs.
2009/11/23 09:15:17.037| AsyncJob of type Adaptation::Icap::ServiceRep constructed, this=0x839a7098 [async1]
2009/11/23 09:15:17.037| squid-3.1.0.14/src/adaptation/Service.cc(12) Service: creating adaptation service icap_server
2009/11/23 09:15:17.037| squid-3.1.0.14/src/adaptation/Config.cc(105) finalize: Created 1 message adaptation services.
2009/11/23 09:15:17.037| Adaptation support is on
2009/11/23 09:15:17.037| squid-3.1.0.14/src/adaptation/Config.cc(117) FinalizeEach: Initialized 1 message adaptation services
2009/11/23 09:15:17.037| squid-3.1.0.14/src/adaptation/ServiceGroups.cc(78) finalize: finalized adaptation set: class_1
2009/11/23 09:15:17.037| squid-3.1.0.14/src/adaptation/Config.cc(117) FinalizeEach: Initialized 1 message adaptation service groups
2009/11/23 09:15:17.037| squid-3.1.0.14/src/adaptation/Config.cc(117) FinalizeEach: Initialized 1 message adaptation access rules
2009/11/23 09:15:17.768| AsyncJob of type ConnStateData constructed, this=0x8730f100 [async2]
2009/11/23 09:15:17.768| AsyncJob of type ClientHttpRequest constructed, this=0x891f0410 [async3]
2009/11/23 09:15:17.768| AsyncJob of type AccessCheck constructed, this=0x81f7203c [async4]
2009/11/23 09:15:17.768| squid-3.1.0.14/src/adaptation/AccessCheck.cc(49) AccessCheck: AccessCheck constructed for REQMOD PRECACHE
2009/11/23 09:15:17.768| The AsyncCall AsyncJob::noteStart constructed, this=0x7df3fc40 [call94]
2009/11/23 09:15:17.768| squid-3.1.0.14/src/base/AsyncJob.cc(18) will call AsyncJob::noteStart() [call94]
2009/11/23 09:15:17.769| entering AsyncJob::noteStart()
2009/11/23 09:15:17.769| squid-3.1.0.14/src/base/AsyncCall.cc(32) make: make call AsyncJob::noteStart [call94]
2009/11/23 09:15:17.769| AccessCheck status in: [ job4]
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(74) check: start checking
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(188) isCandidate: checking candidacy of 1, group class_1
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/ServiceGroups.cc(134) findService: class_1 checks service at 0
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/ServiceGroups.cc(144) findService: class_1 has matching service at 0
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(198) isCandidate: class_1 wants
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(80) check: check: rule '1' is a candidate
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(96) checkCandidates: has 1 rules
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(119) AccessCheckCallbackWrapper: callback answer=1
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(134) noteAnswer: 1 answer=1
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(171) topGroup: top group for 1 is 0x81485540*2
2009/11/23 09:15:17.769| squid-3.1.0.14/src/adaptation/AccessCheck.cc(155) callBack: 0x81485540*2
2009/11/23 09:15:17.769| squid-3.1.0.14/src/client_side_request.cc(636) adaptationAclCheckDone: 0x7ef0b010 adaptationAclCheckDone called
2009/11/23 09:15:17.769| AsyncJob of type Iterator constructed, this=0x8874b044 [async5]
2009/11/23 09:15:17.769| The AsyncCall AsyncJob::noteStart constructed, this=0x81e26bc0 [call96]
2009/11/23 09:15:17.769| squid-3.1.0.14/src/base/AsyncJob.cc(18) will call AsyncJob::noteStart() [call96]
2009/11/23 09:15:17.769| AccessCheck will stop, reason: done
2009/11/23 09:15:17.769| AsyncJob::noteStart() ends job [Stopped, reason:done job4]
2009/11/23 09:15:17.769| squid-3.1.0.14/s

Re: [squid-users] Squid 3.1.0.14: ICAP REQMOD - Not returning 403 error page to client

[Silamael]

On 11/23/2009 09:41 AM, Silamael wrote:

Hello Amos,

I found out that my test creates an invalid Encapsulated header. After
fixing it, squid dies with an assertion failure in
BodyPipe::undoCheckout().
Attached you find the cache.log of my test.

Greetings,
Matthias


Hello together,

I searched the Squid bugzilla and found this bug: 
http://bugs.squid-cache.org/show_bug.cgi?id=2311

Sounds like our problem so i will try the patch attached to the bug.

Greetings,
Matthias

Re: [squid-users] Squid 3.1.0.16 beta is available

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/02/2010 02:33 AM, The Doctor wrote:
> Squid 3.1.16 is not working on my FreeBSD 7.2 Box.
> 

"not working" is a quite helpfull problem description...

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktn0KEACgkQGgHcOSur6dTqDgCgnt9CsLhRB246344ez+Tb2LNG
To8AoJqGW5/NonFGDUdgmyMx8VO4Qc6y
=SqlT
-END PGP SIGNATURE-

[squid-users] Squid 3.1.0.16: assertion failure in src/peer_select.cc, line 627

[Silamael]

Hello,

I just built the new version of Squid. When starting, Squid dies
instantly with an assertion failure in peer_select.cc, line 627.
Apparently in peer_select.cc "PINNED" is missing in the hier_strings.
PINNED is in enums.h but not in peer_select.cc, so the list of constants
and the string array have not the same size.

Greetings,
Matthias

[squid-users] Error page errors/ca/ERR_CACHE_ACCESS_DENIED empty

[Silamael]

Hello!

In Squid 3.1.0.16 the error file errors/ca/ERR_CACHE_ACCESS_DENIED is
completely empty.

Greetings,
Matthias

Re: [squid-users] Squid 3.1.0.16: assertion failure in src/peer_select.cc, line 627

[Silamael]

On 02/02/2010 11:38 AM, Amos Jeffries wrote:
> Sorry about that. This was caught shortly after the release was
> announced. The bundles have since been updated.
> 
> Please re-download and re-build your copy of 3.1.0.16. If you are using
> a pre-packaged version please contact the package maintainer.
> 
> Amos

Hi Amos,

Thanks for the quick answer! I will redownload the sources then and
rebuild our squid.

-- Matthias

Re: [squid-users] Error page errors/ca/ERR_CACHE_ACCESS_DENIED empty

[Silamael]

On 02/02/2010 11:53 AM, Amos Jeffries wrote:
> Strange. I can't see anything obviously wrong with that languages source
> files.
> 
> For now, copying templates/ERR_CACHE_ACCESS_DENIED to
> ca/ERR_CACHE_ACCESS_DENIED will get around this.
> 
> I'll keep an eye on the snapshots and see if its broken there too.
> 
> Amos

That's what i did. Not a big problem. But even in the recent source file
this error page is still empty.

-- Matthias

[squid-users] Orig. request HTTP/1.0, outgoing request HTTP/1.1

[Silamael]

Hello together,

Just build the new Squid 3.1.0.18 and noticed that now, Squid does an
HTTP/1.1 request to the server even if the client just sent an HTTP/1.0
request. Previous versions of Squid did not do that.
Is this intended or did i stumble over some minor bug?

-- Matthias

Re: [squid-users] Orig. request HTTP/1.0, outgoing request HTTP/1.1

[Silamael]

On 03/15/2010 01:37 PM, Amos Jeffries wrote:
> RFC 2616 compliance has nearly been reached in 3.1.
> Squid can now talk HTTP/1.1 to web servers. Upgrading requests like you
> saw is the final requirement to be met in that area.

Hi Amos,

Thank you for the quick answer :)

-- Matthias

[squid-users] X-Forwarded-For and Squid 3.0

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello!

Are there any plans to implement the X-Forwarded-For feature in Squid3?
We had to use Squid3 due to some ICAP project stuff and we will need the
X-Forwarded-For feature for some other stuff too...

Greetings,
Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJISU6GgHcOSur6dQRAufUAJ9bG2eblPcM3vBCKMGSzQHiODiXVgCghi5S
obPHCxz/GAiHpo8Uzyv7aRY=
=0M1T
-END PGP SIGNATURE-

Re: [squid-users] X-Forwarded-For and Squid 3.0

[Silamael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Amos Jeffries wrote:
> Yes. It is already done and in Squid 3.1.
> 
> We've had a fair number of annoyances found with the 3.1.0.2 packages
> not including everything they needed for the new code. One more in
> todays snapshot. So for testing I'd advise starting with the 20081118
> snapshot.
> 
> Amos

Thank you for the quick reply. So probabely we will upgrade to 3.1 then.

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJIWl8GgHcOSur6dQRAuKHAKDKj3uM7HUnKm2p4yJUJGco65jd1ACfZCVJ
SpPG1GK3rWcIyCD4H17wMow=
=D5p7
-END PGP SIGNATURE-

Re: [squid-users] Re: Problem compiling Squid 3.1.11 or 3.1.12 on OpenBSD 4.8

[Silamael Darkomen]

On 21-Apr-11 16:07, EzyMike wrote:
> Indunil Jayasooriya wrote:
>> On Thu, Apr 21, 2011 at 1:54 PM, EzyMike  wrote:
>>> Hi!
>>>
>>> I have a problem compiling squid 3.1.11 or 3.1.12 on a OpenBSD 4.8 box.
>>> When preparing to replace a OpenBSD 4.6 box with a 4.8, the compilation
>>> of
>>> squid brings this error:
>>>
>>>   Making all in lib
>>>   cc1: warnings being treated as errors
>>>   In file included from ../include/util.h:49,
>>>  from base64.c:6:
>>>   /usr/include/arpa/inet.h:74:warning 'struct in_addr' declared inside
>>> parameter list
>> these may help
>>
>> http://www.mail-archive.com/squid-users@squid-cache.org/msg78443.html
>>
>> -- 
>> Thank you
>> Indunil Jayasooriya
>>
> Thank you, I tried it again, and this time it worked.
> I changed the file util.h after running the configure script, and so the
> changes were not applied the first time.
> Now I changed the file first and then run the configure script and all
> worked as expected.
>
> Best Regards, Mike

Hi,

The more correct patch is the one in this bug report:
http://bugs.squid-cache.org/show_bug.cgi?id=3185

Greetings,
Matthias