Re: [RFC] Squid process model and service name impact

On 01/29/2014 09:27 PM, Amos Jeffries wrote:
> On 30/01/2014 2:29 p.m., Alex Rousskov wrote:
>> > Ability to run two concurrent instances using the same configuration
>> > file does not sound like a reasonable goal/requirement to me. Has
>> > anybody even asked for that? What was their motivation?? I know folks
>> > want to run concurrent instances from the same Squid build, but using
>> > the same squid.conf seems like a very very strange use case to me.

> A handful of times IIRC. Its is mostly centered around testing the final
> config on a production server with original running at the time IIRC.

Thank you. Now I know what to blame for this (-a). I am glad it is not a
common request. I suspect at least some of these folks will stop using
this feature when they realize that "identical squid.confs with
different service names" is not "identically configured Squid" worth
testing on a production server.

> One of the clients I had a few years back wanted a pretty much
> default squid.conf with some external ACL helpers to do per-client
> security controls and the -a command line option to specify which
> http_port to be opened for that instance. In SMP mode if at all possible.

I am glad they will get their wish soon. I do not think we need to do
more to support the above setup after you make UDS and shared memory
paths configurable (since -n and ${service_name} are already supported).

> When you boil it down to the very minima basics it can be reduced to a
> single unique ID value to be embeded in the config options and
> background pieces ... such as -n takes.

If you boil it down to the very minimal basics from Squid point of view,
you get a sed script that generates a per-customer squid.conf from a
template, with no -n or even -a needed. It is difficult to draw a line
and design/defend "ideal" interfaces, so now we have both -a and -n (not
to mention many other command line options that should not be there).

Cheers,

Alex.
Received on Thu Jan 30 2014 - 22:39:15 MST