On 01/24/2014 01:11 PM, Henrik Nordström wrote:
> fre 2014-01-24 klockan 08:57 -0700 skrev Alex Rousskov:
>
>> Please note that since Windows admins want a service name even if they
>> do not run multiple single-build instances on the same box, setting that
>> service name should not suddenly make their life more difficult by
>> altering squid.conf location and such. You can make exceptions for
>> "default" service name such as "squid", but it may get pretty messy
>> pretty quickly.
> Do they really want the service name to have any other implications?
Unknown [to me]. On the Unix side, Amos wants to use the recently added
[for Windows] service name to support multiple concurrent instances
using the same Squid build (bug 3608). That bug report contains a
suggestion to make the currently ./configure-set IPC paths explicitly
configurable in squid.conf, but using service name side-effects also
works. I am not sure which approach offers the best overall solution.
>> As an alternative, you can restrict the scope to something like this:
>>
>> "All --prefix dependent names not already configurable via squid.conf or
>> command line that may lead to a conflict between multiple concurrent
>> instances of a single Squid build."
>
> Do we have any?
I know of IPC (UDS) socket names and shared memory segment names.
>> BTW, you may want to add a ${service_name} macro support to squid.conf
>> parser to make multi-service configuration easier.
>
> Right, that is an excellent idea. And if that also applies to include
> then the first part mentioned above is solved nicely by having the main
> squid.conf include service dependent parts which might in fact be the
> entire squid.conf for that service if so desired.
Yes, all squid.conf macros are processed by the preprocessor so the
includes should be covered (if not, it is a different bug).
Cheers,
Alex.
Received on Fri Jan 24 2014 - 21:28:00 MST
This archive was generated by hypermail 2.2.0 : Sat Jan 25 2014 - 12:00:13 MST