On 2014-01-31 11:38, Alex Rousskov wrote:
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).
Worse than that. Compatibility with systemd specifically as the driver
behind -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).
Yes.
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).
'cept even more basic -n needs no sed read/write magics.
Anyhow, I'm glad we are nearly at an endpoint for all this. I can get
back to testing the Comm and parser changes.
Amos
