RE: includes inside squid.conf

On 26 Mar 2002, at 11:47, Alex Rousskov <rousskov@measurement-factory.com> wrote:

> > > Would be nice to have in 2.6. I have one implementation
> > > for that, based on recursive configfile parser. recursion
> > > loops are detected by remembering inodes of seen configs.
>
> Inodes?! Would not file name be sufficient?

 When I wrote it, I thought that people would start using symbolic
 links left and right, so there is a need to identify unique files,
 not links. Inodes provide this. They make it possible to trap
 exact file that is creating a loop even if many links point to it.
 I wanted to detect exact moment when loop is created. Besides
 inodes are alot easier to "remember" and compare ;). For names,
 you'd need to deal with typical cases like "../squid/etc/file.cfg"
 and later "etc/file.cfg". Comparing these equal is alot of bother.

 Probably it would be initially simpler to just count recursion
 depth and limit it to something as Henrik suggested. It would
 only provide very little help when nonobvious loop is created,
 we can't pinpoint the faulty #include, but this might be a
 nonissue. Probably portability outweights that too.

 But with recursion limit, you are immediately to ask what is
 the good depth limit? 2-4,16? Or number of #include directives?

 Limit would not detect multiple includes of the same file which
 might cause headache for some fancy people. Not our problem
 strictly, but depending on case this might cause very difficult
 to diagnose situations which may lead to blaming bugs in squid.

 Also, another issue arrives when adding notion of #includes: what
 is a correct action when #include file is not accessible? Some
 includes are critical for correct operation, some are not, should
 we bail out or continue? Perhaps create #include and #required?
 I tend to wish that we could ignore #include errors, this would
 make it possible to include configs from files on swap disks if
 they are mounted, thinking of hotswap disks or netmounts.

> > > I don't consider recursion here as evil, besides it makes
> > > for pretty simple patch.
>
> I agree that it is not evil, but using up all RAM at start-up for no
> obvious reason can be annoying, especially if it is a result of a
> minor typo made in a perfectly fine and used-to-work file. In my
> experience, once you let people use #includes, some will create very
> complicated cfg file hierarchies.

 Right, so some sort of loop detection must be in place.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Mon Apr 01 2002 - 00:25:33 MST