Jenkins build is back to normal : 3.HEAD-amd64-CentOS-5.3 #1670

[noc]

See 

Build failed in Jenkins: 3.HEAD-amd64-CentOS-5.3 #1669

[noc]

See 

Changes:

[Automatic source maintenance] SourceFormat Enforcement

--
[...truncated 4013 lines...]
make[4]: Entering directory 
`
if g++ -DHAVE_CONFIG_H  -I../../../.. -I../../../../include -I../../../../lib 
-I../../../../src -I../../../include  -Wall -Wpointer-arith -Wwrite-strings 
-Wcomments -Werror -pipe -D_REENTRANT -g -O2 -MT ext_edirectory_userip_acl.o 
-MD -MP -MF ".deps/ext_edirectory_userip_acl.Tpo" -c -o 
ext_edirectory_userip_acl.o 
../../../../helpers/external_acl/eDirectory_userip/ext_edirectory_userip_acl.cc;
 \
then mv -f ".deps/ext_edirectory_userip_acl.Tpo" 
".deps/ext_edirectory_userip_acl.Po"; else rm -f 
".deps/ext_edirectory_userip_acl.Tpo"; exit 1; fi
/bin/sh ../../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o 
ext_edirectory_userip_acl  ext_edirectory_userip_acl.o -L../../../compat 
-lcompat-squid  -lldap -llber -lm -lnsl -lresolv -lrt -ldl -ldl 
libtool: link: g++ -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror 
-pipe -D_REENTRANT -g -O2 -g -o ext_edirectory_userip_acl 
ext_edirectory_userip_acl.o  
-L
 -lcompat-squid -lldap -llber -lm -lnsl -lresolv -lrt -ldl
make[4]: Leaving directory 
`
Making all in file_userip
make[4]: Entering directory 
`
if g++ -DHAVE_CONFIG_H  -I../../../.. -I../../../../include -I../../../../lib 
-I../../../../src -I../../../include  -Wall -Wpointer-arith -Wwrite-strings 
-Wcomments -Werror -pipe -D_REENTRANT -g -O2 -MT ext_file_userip_acl.o -MD -MP 
-MF ".deps/ext_file_userip_acl.Tpo" -c -o ext_file_userip_acl.o 
../../../../helpers/external_acl/file_userip/ext_file_userip_acl.cc; \
then mv -f ".deps/ext_file_userip_acl.Tpo" 
".deps/ext_file_userip_acl.Po"; else rm -f ".deps/ext_file_userip_acl.Tpo"; 
exit 1; fi
/bin/sh ../../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o 
ext_file_userip_acl  ext_file_userip_acl.o ../../../lib/libmiscencoding.la 
-L../../../compat -lcompat-squid  -lm -lnsl -lresolv -lrt -ldl -ldl 
libtool: link: g++ -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror 
-pipe -D_REENTRANT -g -O2 -g -o ext_file_userip_acl ext_file_userip_acl.o  
../../../lib/.libs/libmiscencoding.a 
-L
 -lcompat-squid -lm -lnsl -lresolv -lrt -ldl
make[4]: Leaving directory 
`
Making all in kerberos_ldap_group
make[4]: Entering directory 
`
make[5]: Entering directory 
`
if g++ -DHAVE_CONFIG_H  -I../../../.. -I../../../../include -I../../../../lib 
-I../../../../src -I../../../include-I../../../.. -I../../../../include 
-I../../../../lib -I../../../../src -I../../../include
-I../../../../helpers/external_acl/kerberos_ldap_group  -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 -MT 
kerberos_ldap_group.o -MD -MP -MF ".deps/kerberos_ldap_group.Tpo" -c -o 
kerberos_ldap_group.o 
../../../../helpers/external_acl/kerberos_ldap_group/kerberos_ldap_group.cc; \
then mv -f ".deps/kerberos_ldap_group.Tpo" 
".deps/kerberos_ldap_group.Po"; else rm -f ".deps/kerberos_ldap_group.Tpo"; 
exit 1; fi
if g++ -DHAVE_CONFIG_H  -I../../../.. -I../../../../include -I../../../../lib 
-I../../../../src -I../../../include-I../../../.. -I../../../../include 
-I../../../../lib -I../../../../src -I../../../include
-I../../../../helpers/external_acl/kerberos_ldap_group  -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 -MT 
support_group.o -MD -MP -MF ".deps/support_group.Tpo" -c -o support_group.o 
../../../../helpers/external_acl/kerberos_ldap_group/support_group.cc; \
then mv -f ".deps/support_group.Tpo" ".deps/support_group.Po"; else rm 
-f ".deps/support_group.Tpo"; exit 1; fi
if g++ -DHAVE_CONFIG_H  -I../../../.

Re: Override FD on windows

[Henrik Nordström]

ons 2011-11-09 klockan 01:02 +0200 skrev Ghassan Gharabli:

> You also said that the source of Visual Studio CRT is available . Any Link ?

from what I am told it's included in Visual Studio in crt\src\

Regards
Henrik

Re: Override FD on windows

[Ghassan Gharabli]

Hello Henrik,

I have also tried to rebuild msvcrt.dll but we cant find its source
and I know we can override the maximum file descriptors in this file
since MinGW is linking with it and Squid is fully built POSIX while
Windows is not yet fully compatible POSIX!.

You also said that the source of Visual Studio CRT is available . Any Link ?

Is squid using NATIVE API CALLS on retreiving Files from Cache (
Sockets) which means If it is using Unlimted File Socket as No
Restrictions ?

Ghassan


2011/11/8 Henrik Nordström :
> lör 2011-11-05 klockan 12:02 +0200 skrev Ghassan Gharabli:
>
>> I am working on a project with a friend to try exceeding the
>> limitation of File Descriptors on  Windows..
>
> From what I remember the limit comes from a Visual Studio crt
> limitation. But I only have vague memory of what Guido have said many
> years ago.
>
> the source for the Visual Studio crt is available I think and can be
> rebuilt.
>
>> Whats the difference between compiling Squid as : ( Cygwin , MinGW ,
>> MS VISUAL STUDIO)?
>
> MinGW is a native build using GNU toolchain.
>
> Visual Studio is a native build ising Microsoft toolchain.
>
> The result of both is similar native Windows appliacations.
>
>
> Cygwin is POSIX emulated build using a GNU toolchain, heavily relying on
> the cygwin dll för providing POSIX like functionality. Not needed for
> Squid as it has native Windows support.
>
>> I would like to hear suggestions from you concerning Squid2.7 STABLE9.
>
> Upgrade. Squid-2 is very near end of life.
>
> Squid-3 needs more windows knowing people looking at it, and anything
> you can contribute there will be of help.
>
> Regards
> Henrik
>
>

Re: Reading ACL configuration files every request

[Andrew Beverley]

On Mon, 2011-11-07 at 11:59 +1300, Amos Jeffries wrote:
>  Well, in light of the facts that new helpers are only being added to 
>  3.3 now

That's fair enough. I've attached my (fairly raw) helper to this email
anyway, just for the list archives, in case anyone else has use for it.

>  and that live re-configuration via POST to the manager is very 
>  close now I'm not sure how much use this would be.

Sounds good. Look forward to it!

> > On a similar subject, is there any mileage in making the FORMAT 
> > optional
> > for external_acl_type? There is obviously no need for it in this 
> > case,
> > although as you have shown it is easy to workaround with a fairly 
> > static
> > parameter.
> 
>  The long term plans are to make the external ACL format merge with log 
>  line format codes and add a format= option. Allowing far more 
>  flexibility in the format syntax.

Great news.

>  I've just added support for the '%%' token which can be used for a 
>  completely static placeholder.

Thanks.

Andy



datetime_acl.pl
Description: Perl program

Re: [PATCH] Logging of honored certificate validation error names

[Tsantilas Christos]

On 11/08/2011 01:27 AM, Alex Rousskov wrote:

On 11/07/2011 03:58 PM, Amos Jeffries wrote:

On Mon, 07 Nov 2011 13:48:46 -0700, Alex Rousskov wrote:

On 11/05/2011 04:15 PM, Amos Jeffries wrote:

On 2/11/2011 11:13 p.m., Tsantilas Christos wrote:

Currently the %err_detail access_log formating code does not display
something useful for the system admin in the case of the certificate
validation errors.

This patch in the case of an ERR_SECURE_CONNECT_FAIL error displays
the certificate validation error name.



+1. Looks okay.

I'm  a little dubious about passing request->detailError() the SSL error
code instead of the errno. But have no strong objections.


Error detailing code was specifically designed to record
context-specific details beyond errno (which was already available in
most cases) and the request->detailError() method itself is usually used
to store non-errno details:


./src/Server.cc:request->detailError(ERR_ICAP_FAILURE,
ERR_DETAIL_RESPMOD_BLOCK_LATE);
./src/client_side_request.cc:
request->detailError(ERR_ACCESS_DENIED, ERR_DETAIL_REQMOD_BLOCK);
./src/client_side_request.cc:
request->detailError(ERR_ICAP_FAILURE, ERR_DETAIL_CLT_REQMOD_RESP_BODY);
./src/client_side_request.cc:
request->detailError(ERR_ICAP_FAILURE, errDetail);



We even document HttpRequest::errDetail to be errType-specific:


 err_type errType;
 int errDetail; ///<  errType-specific detail about the transaction
error



Why are you dubious about passing request->detailError() the SSL error
code?



That in this case we seem to have both an errno and an extended error
with values. Its not clear to me whether this change is keeping the
system errno around for the report tokens which display pure errno (or
'-') rather than our extended err_type.


Amos, we have not always system errno  in the case of 
ERR_SECURE_CONNECT_FAIL. We may have in the case of 
SQUID_ERR_SSL_HANDSHAKE ssl error which added today to trunk.


What are you suggesting? If I am understanding well, you are suggesting 
to try log the system errno when exist?


The "%err_detail" formating code prints the errno (SYSERR=errno) only 
when there is not any other useful info (eg a 
"ERR_DETAIL_ICAP_XACT_START" detail or a "EXCEPTION=0x53" info)





Not a major issue since I think our err_type is a clearer message anyway.


Christos,

 I think your patch does not change pure errno rendering for error
pages where we have separate macros for displaying errno and error
detail, right?


Right.




For access logs, we do not have separate macros so we have to log what
is most relevant. In case of a certificate validation errors, the SSL
validation error is more relevant than system errno, which is often not
set for those errors, correct?


Correct.
In this patch, we are fixing the "%err_detail" formating code to display 
more useful error details in the case of ERR_SECURE_CONNECT_FAIL. In 
this case we may have a system errno but we may have not (in most cases).





When/if access log gains all the error page macros, the admin would be
able to log the system errno separately from the SSL error name.


We need a new log access formating code, lets say "%errno", or add 
parameters to the "%err_detail" formating code to manage its behavior.





Thank you,

Alex.

Jenkins build is back to normal : 3.HEAD-amd64-CentOS-5.3 #1666

[noc]

See 

Re: /bzr/squid3/trunk/ r11851: Document and alter the pconn idle timeout directives.

[Amos Jeffries]

On 8/11/2011 11:25 p.m., Tsantilas Christos wrote:

Hi,
  unfortunately something missing from the patch,  the required 
changes in structs.h
The  Config.Timeout.clientIdlePconn and Config.Timeout.serverIdlePconn 
members does not exist...


Thank you. Repaired.

Amos

Re: /bzr/squid3/trunk/ r11851: Document and alter the pconn idle timeout directives.

[Tsantilas Christos]

Hi,
  unfortunately something missing from the patch,  the required changes 
in structs.h
The  Config.Timeout.clientIdlePconn and Config.Timeout.serverIdlePconn 
members does not exist...




On 11/08/2011 11:24 AM, Amos Jeffries wrote:


revno: 11851
committer: Amos Jeffries
branch nick: trunk
timestamp: Tue 2011-11-08 22:24:08 +1300
message:
   Document and alter the pconn idle timeout directives.

   Alters the directive names to clarify what they do and adds some more
   description to the config file documentation.

   Alters the internal config variables to match the new directive names.

   Also alters the well known messages in mgr:filedescriptors report a little
   to indicate client/server type and adds a standard "Idle " prefix for
   easy automated scanning.
modified:
   doc/release-notes/release-3.2.sgml
   src/cf.data.pre
   src/client_side.cc
   src/pconn.cc

Re: [PATCH] [RFC] pconn directive cleanup

[Amos Jeffries]

On 8/11/2011 10:04 a.m., Alex Rousskov wrote:

On 11/06/2011 11:12 PM, Amos Jeffries wrote:


+   This is only relevant when persistent client connections
+   are enabled. Non-persistent connections will close
+   immediately after each request is completed.

I would remove the above addition as obvious and slightly awkward OR
rephrase it to just say something like "This option does not affect
non-persistent client connections which are closed immediately after
last use".

The patch looks good to me.

It would be useful to document whether setting the timeout to zero is
meaningful as a way to optimize one-after-another requests without
creating a lot of idle persistent connections.


Thank you,

Alex.


Done. And committed.

Amos