Re: (Fwd) Re: includes inside squid.conf

The main reason to this message is to announce that there is now a
patch showing how to hook a preprocessor into Squid config file
reading to allow the use of a preprocessor without having to script
things or generate a temporary config file.

http://devel.squid-cache.org/projects.html#cf_preprocess

The downside of using a "inline" preprocessor is that Squid can't
show correct file names or line numbers when finding an error in the
configuration.

On Tuesday 02 April 2002 19:48, Andres Kroonmaa wrote:

> 1) extremes are, ... abit extreme. (does that answer your 1st Q?)
> ;-)

Not really.

I find extremes quite enlighting, in that being extremes they often
forces one to look at the problem from a different angle. Especially
for seemingly simple problems like the subject of this thread.

> 2) all I want is to include common options to all squids I'm
> running. I want to sync these changes between boxes so that unique
> settings don't get wiped away. I do that occasionally. Its very
> simple thing. I don't like the need to run some pre-proc on every
> box and needing to preinstall it first. Maximum effect with minimal
> effort.

And I am not denying you this, only objecting on the approach as it
does not really address the problem.

> When we need much more fancy scripting functionality, I agree, its
> better done outside squid for now.

And a person needing includes is also very likely to quite soon need
more advanced capabilities.

For example, once you get the includes, you will very likely find
that the configuration should be identical except for some small
details that is server dependent, etc.. and find that it cannot
easily be solved with includes.

> > A bit extreme I would say.. but why not ;-) Naa. Recompiling is a
> > bit of too time consuming task, and cannot easily be done "on the
> > fly" for non-intrusive reconfiguration.
>
> Well, we can think of recompiling only globals.o and link, or even
> make it dynamic library..., or use debugger to patch squid binary,
> or even running memory image... and perhaps write some guidelines
> how to do that yourself ;-)

recompiling do not allow "reconfigure", as the binary needs to be
reloaded after beeing rebuilt.

Using a debugger could be made to work, if it wasn't for the
portability nightmare..

B-)

> And I don't want to add any complex parsing to squid.
> Simple include is not complex addition. Inode checks seemed
> simple to me, but without them its even more trivial if we limit
> the depth low. Expanding relative paths into absolute seemed to
> me on the complex side of things. But thats only me.

As pointed out, if you want to use relative paths then one must first
define a point of origin. Without such definition relative path
cannot be used.

If you have a point of origin then translating relative to absolute
paths is trivial.

> > m4 is considerably more portable than Squid. I don't see the
> > problem really..
>
> Windows too?

Even DOS. And the support needed to hook a pre-processor into a
program without needing to use scripting is defined by the ANSI-C
library specificaton (and K&R C before that).

> Yes, most user friendly way is: "do it as you please, ;-) ".
> We don't have universal pre-processor, so all we can do is to
> give some guidelines how people could implement the feature.

We can easily recommend a suitable preprocessor for the job, and
provide examples how to use such preprocessor to solve common
problems in Squid configuration.

Regards
Henrik
Received on Tue Apr 02 2002 - 14:48:09 MST