> > Since it just does what a good system should do, what is there to go > > into "at length" about? > > What it does. How it does it. If that were documented, it'd sure be > easier to use the tools more effectively.
It does what it does, how it does it, in the source code. Manual pages do not serve those purposes. pf(4) describes what pf is capable of. pf.conf(5) describes the grammer used to communicate with pf. pfctl(8) describes the flags and features of the front-end parser that converts text rules to requests against pf(4)'s capabilities. None of the manual pages can exhaustively describe the workings of pf without losing their purpose. Each of those manual pages are already far too long as it is. > > Yes, other systems taught you to hand-optimise. How do we go into > > "don't do hand optimization" at length? > > http://undeadly.org/cgi?action=article&sid=20060927091645 > > > It is a manual page, not a howto. > > I was responding here to the remark about the man pages, and making > the point that, IMHO, the statement was not correct. That posting was written more than 3 years ago. Then, as now, it was written _in that forum_ because it does not belong in the manual pages. > The FAQ at the > website and the books I'd been able to find don't explain this area > either, although they do go into other areas in detail. Perhaps the way that pf works is not a FAQ. And perhaps the book authors did not research deeply enough into how pf works, to be able to write the best book. Perhaps their books simply regurgitate the "best most common" ways to use pf. I'd say that is fine for most. You want to dig in deeper? Well, the source code is available. And yes, if lots of people are using pf wrong? So what. It meets their purposes. > The earlier posts told me where to go to fill in a lot of holes; the > info's out there. It's just hard to find for someone new to the > 'culture' (who didn't know about undead yet). > > And it strikes me as odd that what looks like a significant advantage > over other ways of doing things is so kept under wraps. You've been told twice now that it is not under wraps. Stop it: set ruleset-optimization basic Enable basic ruleset optimization. This is the default behaviour. Basic ruleset optimization does four things to improve the performance of ruleset evaluations: 1. remove duplicate rules 2. remove rules that are a subset of another rule 3. combine multiple rules into a table when advanta- geous 4. re-order the rules to improve evaluation perfor- mance none Disable the ruleset optimizer. profile Uses the currently loaded ruleset as a feedback profile to tailor the ordering of quick rules to actual network traffic. It is important to note that the ruleset optimizer will modify the ruleset to improve performance. A side effect of the ruleset modification is that per-rule accounting statistics will have different meanings than before. If per-rule accounting is impor- tant for billing purposes or whatnot, either the ruleset optimiz- er should not be used or a label field should be added to all of the accounting rules to act as optimization barriers. Optimization can also be set as a command-line argument to pfctl(8), overriding the settings in pf.conf. > I've been > running OpenBSD for only a few days, and I'm just beginning to take a > few baby steps -- I'm sorry if I stepped on some toes. I certainly > didn't intend to. > > FWIW, I'm willing to put my time where my mouth is and see if I could > fix what I claim is bent. I'm way not qualified to do that on my own > yet, but I might be able to help... We always accept diffs. If the manual pages are not super clear, try to write small diffs to help improve them. First of all that means you must understand the "central purpose" to each manual page. Whatever gets added to it must follow in the main direction of the page.
