It seems the option http_port cannot be put under each process ID. If using workers, http_port cannot bind to ports specified from http_port.
Alex > Date: Wed, 1 Jul 2015 14:56:46 +1200 > From: squid3@treenet.co.nz > To: alex_wu2012@hotmail.com; squid-users@lists.squid-cache.org > Subject: Re: [squid-users] sslbump and caching of generated cert > > On 1/07/2015 5:08 a.m., Alex Wu wrote: > > /* > > You could assign two workers, each with a different http_port and > > ssl_crtd helper using different cert databases. > > > > */ > > > > How to do this? It sounds it might meet our need. > > > > at the top of squid.conf place: > > workers 2 > > if ${process_number} = 1 > http_port 10045 ... > sslcrtd_program ... > > else > http_port 10046 ... > sslcrtd_program ... > > endif > > The list of other directives which also need separate per-worker > configuration can be found at > <http://wiki.squid-cache.org/MultipleInstances#Relevant_squid.conf_directives>. > > > > The reason is that we assign a port for internal, > > so we can use cheap CA (self-generated CA), for the collaboration, we use a diffrent port, > > may need to set up a different CA. > > That dont make sense to me. There should be no need for internal traffic > to use a different CA from what external has. Costs are already paid to > get the public CA, there is no incremental increase for internal traffic > to use it as well. > > You can do simpler things like using a private LAN-specific IP on the > listening http_port for internal traffic and myportname ACL for internal > vs external access controls (that work regardless of whether the request > has been bumped or not). > > Amos > |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users