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.
