[squid-users] Define and use a variable in squid.conf (Was: What happens when duplicate external_acl_type are mentioned)
Amish
anon.amish at gmail.com
Mon Dec 3 03:59:27 UTC 2018
On 02/12/18 11:14 pm, Alex Rousskov wrote:
> On 12/1/18 9:31 PM, Amish wrote:
>
>> Now I am looking for alternate ways I can resolve my issue.
> There are probably many ways to do this. There are ready-to-use
> templating tools that may be a better solution (more on that further
> below). However, I can offer a simple template-free approach that should
> work:
>
> # main.conf
> ...
> include authentication.conf
> ...
>
> and then do either
>
> cp -p foo.conf authentication.conf
>
> or
>
> cp -p bar.conf authentication.conf
>
> depending on which authentication mechanism you want to use with a
> particular Squid instance.
This is what I decided on eventually.
Slightly different way but more or less on the same lines.
# main.conf
...
include authentication.conf
...
# authentication.conf
#auth_param ...
#external_acl_type ... %ul
external_acl_type ...
And comment / uncomment whichever method I want to use.
>
>
>> Does squid allow defining a variable
> No, Squid does not. However, there must be ready-to-use templating tools
> that can substitute a "variable" in squid.conf.template to generate
> squid.conf without variables.
>
>
>> and using it as argument or macro?
> Squid has native support for simple preprocessor conditionals. Combined
> with template variables (as discussed above), that support gives you
> another way to accomplish the same outcome. The following sketch uses
> ${Amish::var} as a custom squid.conf.template variable:
>
> if ${Amish::ForceFoo} = 1
> ... configuration using approach foo ...
> else
> ... configuration using approach bar ...
> endif
>
>
>> The reason I cant change main.conf directly is because its a
>> standardized packaged file and gets overwritten every time package is
>> updated.
>
> That is not a valid argument IMO. You do not need to modify main.conf to
> generate a configuration file that is actually used. My earlier
> authentication.conf sketch is one example. And even something as simple
> as the following sed-based script may work in many cases:
>
> sed s/AmishForceFoo/true/ main.conf > squid.conf
Actual squid.conf is:
include pre.conf
include main.conf
So above would not not work. And I do not want to modify main.conf
>
>> This "define" feature can also have several other use in future.
> True. I had considered adding it in the past. The primary reasons it has
> not been added yet are:
>
> 1. squid.conf terrible syntax makes it difficult to introduce new
> syntax-related changes/features safely. For variables to be useful, they
> should be usable in many contexts while not being expanded in some other
> contexts. As we learned the hard way when general quoted strings were
> introduced, getting this right is tricky and sometimes nearly impossible.
May be atleast 'if' statement can have define variable support. Because
it already has similar support for ${process_number} etc.
So template variable substitution above is not required.
pre.conf
-----------
define proxyauth 1
main.conf
-------------
if ${proxyauth} = 1
# external acl with %ul
else
# external acl without %ul
endif
This will also allow squid packagers to allow administrators to activate
/ deactive a feature just by simple define variable.
Sample squid.conf
# on top of squid.conf
define transparent 1
# somewhere inside
if ${transparent} = 1
http_port ... intercept ...
else
http_port ...
endif
This way newbie administrator does not need to know fine details about
http_port.
> 2. Templates and such offer a ready-to-use variable support that can
> avoid the general problems of #1 in specific deployment environments.
> See examples above.
>
> 3. Nobody has guided the required changes from an RFC to implementation.
>
>
Thank you for spending your time for a detailed reply.
Regards
Amish
More information about the squid-users
mailing list