[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.

define proxyauth 1

if ${proxyauth} = 1
    # external acl with %ul
    # external acl without %ul

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 ...
    http_port ...

This way newbie administrator does not need to know fine details about 

> 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.



More information about the squid-users mailing list