Shorewall devel - Jun 2002 - Docs - QSG & Samples Issues

Attached is file "QSG-issues-1.0.txt" containing a numbered and
commented list of issues collected from contributors and recent lists
activity. It might be cool to have these issues in some spiffy issue
tracking system like RT or something, but for a low tech start it''ll
probably suffice.

COMMENTS - IMHO (no particular order):
	I have searched the archives for additional issues/concerns at
some length (read over 200 messages). Most of the search returns
concerned advanced topics probably outside the scope of the QSG and
samples, or were issues that are adequately represented in the attached
list already.
	I created my list (end of the attached) before really reading
through the other contributions. After putting them all together, I was
surprised how much congruence there was in the issues raised by
different people, and agreement as to suggested remedies. In short, most
of the cognitive bumps in the road for one were bumps for many.
	There will always be questions of scope and balance. What
subjects belong in a beginner''s QSG as opposed to file comments or
advanced topics docs, and in what detail? Many issues and comments dance
around those questions.
	The basic docs we''re focusing on now (QSG & samples) are
actually very good. They need maintenance (for currency), some
rearrangement and editing (for clarity), and perhaps some expansion (for
education) -- but they''re pretty darn good. Thanks to Tom''s
very
dedicated work, this doc project starts from a very solid base.

NEXT STAGE SUGGESTIONS:
	Please review the attached file and send any additional issues
you may think of, however small, along with any comments to this list:
mailto:shorewall-devel@shorewall.net. If you were an issue contributor,
please read at least "your" section, as I''ve included
occasional
questions or comments that you might like to address. I''ll try to
continue as maintainer of this issues list, adding things from your
feedback. Perhaps this issues list will go through at least one more
(fairly quick) iteration before a first attempt at rewriting the QSG
begins.
	Next, within the next week or two, those who are interested
could have a chat session and to go over these and any other issues that
come up. After that, one or more people are going to have to blaze ahead
and take a crack at re-writing the QSG itself, incorporating fixes for
the content/presentation/explanation issues. If I''m still standing (new
job project is starting soon) I could make a first attempt at that,
though it would be fine with me if someone else is eager/willing to do
it. Or we could divide up the writing tasks by doc sections, if there''s
a consensus to do that. Concurrently, as Tom had suggested, someone else
should focus on getting the samples up-to-date, clarified, and perhaps
expanded. (Awhile back, Tom volunteered Steve H. for that. Yea!) Any
other suggestions on procedure are welcome, of course.

I''m looking forward to working with everyone as we progress. Thanks a
bunch to all contributors for their thoughtful input so far.

Regards,
Ron

Thanks for this. Very interesting.

In the policy file the comment says DENY but the example line says DROP.
Are both allowed?
Maybe some consistency required here.

Traffic accounting should be mentioned so people new to shorewall know
it''s
not present (IMO).
(For those who want it, I used some code Tom posted to set up some accounting 
rules and it works well if that could be added to the documentation 
somewhere).

Rgds
John Leach


Scanned for viruses at osware.net

Thanks, Ron

On Wed, 5 Jun 2002, Ron Shannon wrote:
> Attached is file "QSG-issues-1.0.txt" containing a numbered and
> commented list of issues collected from contributors and recent lists
> activity. It might be cool to have these issues in some spiffy issue
> tracking system like RT or something, but for a low tech start
it''ll
> probably suffice.
> 
I resist the notion that the default MASQ file should have any entry in
it. While most people that use the QSG will be doing masquerading, many
fireall/gateway applications don''t need (or want) masquerading at all.
So
in my view, it is completely proper to include masq entries in the samples
but I don''t think the same applies for the default file.

One other point that needs expanding on. As Ron mentioned, when the RPM is 
installed, it sets up the firewall to start automatically at cold load. 
But so does the install script (and it tells you if it was unable to make 
that happen).

So the only case where the firewall doesn''t automatically start and no
indication is given is if the user decided to truely install Shorewall
"manually". In that case, no amount of documentation is going to help
because it''s 99% certain that the guy isn''t reading what we
write anyway.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net

> I resist the notion that the default MASQ file should have=20
> any entry in
> it. While most people that use the QSG will be doing=20
> masquerading, many
> fireall/gateway applications don''t need (or want)=20
> masquerading at all. So
> in my view, it is completely proper to include masq entries=20
> in the samples
> but I don''t think the same applies for the default file.
>=20
> -Tom
Either way works for me as long as it''s clear. As John suggests,
commented defaults might be appropriate. My pondering was in context of the
scope & purpose of the QSG. One contributor had suggested the QSG''s
role should be explicitly limited to deploying the samples only (in addition to
reference links to advanced topics.)  The important thing is clarity and, to the
extent more of this is clear, it also helps delineate the QSG''s scope
in general.