[squid-users] Define and use a variable in squid.conf (Was: What happens when duplicate external_acl_type are mentioned)

[Alex Rousskov]

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.


> 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


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

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.


HTH,

Alex.