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

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
Received on Thu Jan 30 2014 - 22:58:54 MST