Anchor foo vs. anchor foo/*
Sorry this is such a basic question ... I'm having difficulty understanding just what the difference is between saying anchor foo and anchor foo/* What exactly goes wrong if you leave off the /*? The implication is that without the /*, rules inside the anchor aren't evaluated -- ??? But then, if they aren't evaluated then what does anchor foo accomplish? How do the filter rules in anchor foo get evaluated if all you say is anchor foo with no /*? If the anchor rules in anchor foo *are* evaluated when you say anchor foo, then why bother with /* -- it just makes the rules harder to read. Does this have to do with what may already be there in the anchor before an anchor rule for foo is seen for the first time? This is all very confusing. The documentation and FAQ make it seem as though anchor foo and anchor foo/* should be synonymous.
Re: Anchor foo vs. anchor foo/*
On 2009/04/16 09:19, Jim Rosenberg wrote: Sorry this is such a basic question ... I'm having difficulty understanding just what the difference is between saying anchor foo and anchor foo/* What exactly goes wrong if you leave off the /*? The implication is that without the /*, rules inside the anchor aren't evaluated -- ??? But then, if they aren't evaluated then what does anchor foo accomplish? How do the filter rules in anchor foo get evaluated if all you say is anchor foo with no /*? If the anchor rules in anchor foo *are* evaluated when you say anchor foo, then why bother with /* -- it just makes the rules harder to read. Does this have to do with what may already be there in the anchor before an anchor rule for foo is seen for the first time? This is all very confusing. The documentation and FAQ make it seem as though anchor foo and anchor foo/* should be synonymous. pf.conf(5) is reasonably clear about this, I think... ANCHORS Besides the main ruleset, pfctl(8) can load rulesets into anchor attach- ment points. An anchor is a container that can hold rules, address ta- bles, and other anchors. ... Anchors may end with the asterisk (`*') character, which signifies that all anchors attached at that point should be evaluated in the alphabeti- cal ordering of their anchor name. For example, anchor spam/* will evaluate each rule in each anchor attached to the spam anchor. did you find this confusing, and if so, can you suggest any changes we could make that might help make it more clear? or did you just not find that part of the documentation?
Re: Anchor foo vs. anchor foo/*
pf.conf(5) is reasonably clear about this, I think... ANCHORS Besides the main ruleset, pfctl(8) can load rulesets into anchor attach- ment points. An anchor is a container that can hold rules, address ta- bles, and other anchors. ... Anchors may end with the asterisk (`*') character, which signifies that all anchors attached at that point should be evaluated in the alphabeti- cal ordering of their anchor name. For example, anchor spam/* will evaluate each rule in each anchor attached to the spam anchor. did you find this confusing, and if so, can you suggest any changes we could make that might help make it more clear? Yes, I found it confusing, and I still do. So, is the answer to my question this?: If you say anchor spam (to use the example above) then all rules immediately contained in the anchor spam are evaluated, but rules in sub-anchors within spam are not. If this is the right idea, then it would be helpful to say this explicitly in the FAQ. Of course, as I understand it, if you say anchor spam/* then a rule in anchor spam/foo will be evaluated, but a rule in anchor spam/foo/bar won't be. This all seems very strange. What goes wrong if you leave off /* is that sub-anchors don't work? But if you do put /*, then sub-anchors *STILL* don't work if they're nested more than one level deep? So, if you leave off /* you're assuming your anchor has no sub-anchors -- but if you put /* then you are assuming there are no sub-sub-anchors ... What happens if you say anchor spam/*/* ?? Will this pick up everything immediately contained in anchor spam as well as everything down to two levels? From the FAQ: The child anchors will be evaluated in alphabetical order but are not descended into recursively Sigh. I'm having difficulty understanding why you wouldn't *want* recursive descent just by saying anchor foo.
Re: Anchor foo vs. anchor foo/*
On 04/16/2009 10:03:59 AM, Jim Rosenberg wrote:
pf.conf(5) is reasonably clear about this, I think...
Anchors may end with the asterisk (`*') character, which
signifies
that all anchors attached at that point should be evaluated in
the
alphabeti- cal ordering of their anchor name. For example,
anchor spam/*
will evaluate each rule in each anchor attached to the spam
anchor.
Maybe:
Evaluate all anchors, in alphabetical order, contained within an
anchor using the asterisk ('*') character. For example,
anchor spam/*
evaluates each rule in each anchor attached to the spam anchor.
This may not address Jim Rosenberg's concerns, but it's shorter
and punchier and so should be easier to understand.
Karl k...@meme.com
Free Software: You don't pay back, you pay forward.
-- Robert A. Heinlein
Re: Anchor foo vs. anchor foo/*
--On Thursday, April 16, 2009 03:08:49 PM +0100 Stuart Henderson s...@spacehopper.org wrote: pf.conf(5) is reasonably clear about this, I think... ANCHORS Besides the main ruleset, pfctl(8) can load rulesets into anchor attach- ment points. An anchor is a container that can hold rules, address ta- bles, and other anchors. ... Anchors may end with the asterisk (`*') character, which signifies that all anchors attached at that point should be evaluated in the alphabeti- cal ordering of their anchor name. For example, anchor spam/* will evaluate each rule in each anchor attached to the spam anchor. did you find this confusing, and if so, can you suggest any changes we could make that might help make it more clear? Yes, I found it confusing, and I still do. So, is the answer to my question this?: If you say anchor spam (to use the example above) then all rules immediately contained in the anchor spam are evaluated, but rules in sub-anchors within spam are not. If this is the right idea, then it would be helpful to say this explicitly in the FAQ. Of course, as I understand it, if you say anchor spam/* then a rule in anchor spam/foo will be evaluated, but a rule in anchor spam/foo/bar won't be. This all seems very strange. What goes wrong if you leave off /* is that sub-anchors don't work? But if you do put /*, then sub-anchors *STILL* don't work if they're nested more than one level deep? So, if you leave off /* you're assuming your anchor has no sub-anchors -- but if you put /* then you are assuming there are no sub-sub-anchors ... What happens if you say anchor spam/*/* ?? Will this pick up everything immediately contained in anchor spam as well as everything down to two levels? From the FAQ: The child anchors will be evaluated in alphabetical order but are not descended into recursively Sigh. I'm having difficulty understanding why you wouldn't *want* recursive descent just by saying anchor foo.
