Re: includes inside squid.conf

On Monday 01 April 2002 19:43, Andres Kroonmaa wrote:

> No-no, why? You never tell user about inode, you just tell him
> that this filename has already been included once. Thats it. When
> bailing out, you can show every file being currently open while
> exiting recursion. Inodes just simplifies it for a coder, skipping
> the need to expand any filename into absolute path. Thats left to
> the OS. How would you do that yourself, portably?

If you want to support relative path names then you better define how
these are to be translated into absolute path names, and make this
translation when processing the files.

Currently in Squid you cannot use relative path names, as the base
directory is different between when you start Squid and on
reconfigure.

> If user has ability to create multiple links to the same file,
> then he already must understand the matter.

Exacly.

But we are not interested to detect if the same file has multiple
names. What we are interested in is to detect if there is a loop.

The same file included more than once using different names is not
really a loop.

> > Besides, I bet that not every OS has a notion of inodes and that
> > some inode declarations are not very portable.
>
> Thats true.

And I'll even dare to bet that your loop detection based on inodes is
incorrect even for UNIX.

> > I think detecting a loop is useful and is better than arbitrary
> > (and not technically necessary) depth limits alone. I only argue
> > that universal and stupid filename-based detection is better than
> > custom and smart inode-based detection.
>
> Better? I doubt. More portable, perhaps.
> But ok, due to understandable resistence to inodes, lets first
> make simple string compare with limited depth safeguard, later
> we'll see.

There won't be a need for inode based complex junk in this simple
thing.

> If your opinion comes from wish to keep it similar to C
> processing, then I agree. But it would be really lovely to be able
> to keep all swap disk related config on that disk itself and
> include it as optional when found suitable.

I have a very strong opinion on this:

If you want conditional configuration dependent on external resources
then use a conditional pre-processor, or, if you for some unknown
reason dislike pre-processors, use a configuration file language with
simple "if-else" constructs giving you the needed conditions..

But then all our products are all built around a configuration engine
with a very suitable for writing configuration file templates and web
interfaces, having all of the needed include, if-else, loops,
variables etc.. so my bias is perhaps slightly differen than most
Squid administrators..

> I for one would like that squid comes up after a nasty crash and
> disk needing manual recovery instead of bailing out on either
> nonexisting swap dir or related include config.

Easily solved from your startup script and a configuration
pre-prosessor such as M4.

What I dislike a lot is that Squid comes up even if the administrator
makes a dangerous error in his squid.conf possibly seriously
compromising security policy or functionality. This is what we have
today.

Example of such error that Squid will currently happily ignore with
only a small notice:

  acl my_network src 192.168.0.0/16
  http_access deny !my_networks

Regards
Henrik
Received on Mon Apr 01 2002 - 13:28:25 MST