Bug 74720

On Sunday 05 December 2004 02:31 pm, Joel Dahl wrote:
> >Number:         74720
> >Category:       docs
> >Synopsis:       [patch] Handbook: More corrections to the firewall chapter
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       low
> >Responsible:    freebsd-doc
> >State:          open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:          doc-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Sun Dec 05 14:40:22 GMT 2004
> >Closed-Date:
> >Last-Modified:
> >Originator:     Joel Dahl
> >Release:        FreeBSD 5.3-STABLE i386
> >Organization:
> >Environment:
>
> System: FreeBSD dude.automatvapen.se 5.3-STABLE FreeBSD 5.3-STABLE #1: Sat
> Nov 13 19:50:36 CET 2004 joel@dude.automatvapen.se:/usr/obj/usr/src/sys/WRK
> i386
>
> >Description:
>
> - Remove contractions.
> - Use the serial comma.
> - Correct spelling.
>
> This chapter still requires a lot of work.
>
> >How-To-Repeat:
> >
> >Fix:
>
> --- firewall2.diff begins here ---
> Index: chapter.sgml
> ===================================================================
So while you were at it, why not go a little further----

> RCS file:
> /home/ncvs/doc/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml,v
> retrieving revision 1.1
> diff -u -r1.1 chapter.sgml
> --- chapter.sgml	5 Dec 2004 00:14:21 -0000	1.1
> +++ chapter.sgml	5 Dec 2004 13:46:13 -0000
> @@ -39,11 +39,11 @@
>        network connections and either allows the traffic through or
>        blocks it. The rules of the firewall can inspect one or more
>        characteristics of the packets, including but not limited to the
> -      protocol type, the source or destination host address and the
> +      protocol type, the source or destination host address, and the
>        source or destination port.</para>
>
>      <para>Firewalls greatly enhance the security of your network, your
> -      applications and services. They can be used to do one of more of
> +      applications and services. They can be used to do one or more of
>        the following things:</para>
          the following:
>
>      <itemizedlist>
> @@ -197,7 +197,7 @@
>      <para>The author prefers IPFILTER because its stateful rules are
>        much less complicated to use in a <acronym>NAT</acronym>
>        environment and it has a built in ftp proxy that simplifies the
          environment and its built in ftp proxy simplifies the
> -      rules to allow secure outbound FTP usage. If is also more
 +      rules necessary for secure outbound FTP usage. It is also more
>        appropriate to the knowledge level of the inexperienced firewall
        attuned to the knowledge level of the inexperienced firewall
>        user.</para>
>
> @@ -566,7 +566,7 @@
>           log and adds the log keyword to those rules. Normally only
>           deny rules are logged.</para>
>
> -       <para>Its very customary to include a default deny everything
> +       <para>It is very customary to include a default deny everything
  +       <para>It is customary to include a default "deny everything"
>           rule with the log keyword included as your last rule in the
            rule containing the log keyword as your last rule in the
>           rule set. This way you get to see all the packets that did not
             rule set. You can then see all the packets that did not
>           match any of the rules in the rule set.</para>
> @@ -749,8 +749,8 @@
>         <para>That is all there is to it. The rules are not important in
>           this example, how the Symbolic substitution field are populated
             this example; how the Symbolic substitution fields are populated
>           and used are. If the above example was in /etc/ipf.rules.script
            and used is. If the above example were in /etc/ipf.rules.script
> -         file, you could reload these rules by entering on the command
> -         line.</para>
> +         file, you could reload these rules by entering this on the
> command +         line:</para>
>
>         <programlisting><command>sh /etc/ipf.rules.script</command>
>           </programlisting>
> @@ -948,7 +948,7 @@
>             <title>SELECTION</title>
>             <para>The keywords described in this section are used to
>               describe attributes of the packet to be interrogated when
> -             determining whether rules match or don't match. There is a
> +             determining whether rules match or not. There is a
  +             determining whether rules match. There is a
>               keyword subject, and it has sub-option keywords, one of
>               which has to be selected. The following general-purpose
                 which must be selected. The following general-purpose
>               attributes are provided for matching, and must be used in
> @@ -1842,7 +1842,7 @@
>  options    IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
>
>        <para>These options are exactly the same as the IPv4 options but
> -        they are for IPv6. If you don't use IPv6 you might want to use
> +        they are for IPv6. If you do not use IPv6 you might want to use
>          IPV6FIREWALL without any rules to block all IPv6</para>
>
>        <programlisting>options    IPDIVERT</programlisting>
> @@ -1851,7 +1851,7 @@
>          functionality.</para>
>
>        <note>
> -        <para>If you don't include IPFIREWALL_DEFAULT_TO_ACCEPT or set
> +        <para>If you do not include IPFIREWALL_DEFAULT_TO_ACCEPT or set
>            your rules to allow incoming packets you will block all
>            packets going to and from this machine.</para>
>        </note>
> @@ -2066,7 +2066,7 @@
>
>            <para>The keywords described in this section are used to
>              describe attributes of the packet to be interrogated when
> -            determining whether rules match or don't match the packet.
> +            determining whether rules match the packet or not.
  +            determining whether rules match the packet.
>              The following general-purpose attributes are provided for
>              matching, and must be used in this order:</para>
>
> @@ -2276,7 +2276,7 @@
>              </programlisting>
>
>            <para>The <filename>/etc/ipfw.rules</filename> file could be
> -            located any where you want and the file could be named any
> +            located anywhere you want and the file could be named any
>              thing you would like.</para>
               in a name and location of your choice.
>
>            <para>The same thing could also be accomplished by running
> --- firewall2.diff ends here ---
>
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
>
> _______________________________________________
> freebsd-doc@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-doc
> To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org"

On Sun, 2004-12-05 at 21:43 +0000, Len Zettel wrote:
> So while you were at it, why not go a little further----

Are you volunteering to help clean up this chapter? :-)

I've focused on correcting obvious things like bad grammar and
misspellings, but I've left out style changes, like rewordings and such.

Yes, I could probably correct everything in one big megapatch and wait
for it to get committed, if I had more time to carefully read the hole
chapter (it's long and it's easy to miss errors, just ask the author),
but I'm not paid to do this you know, I'm merely doing this because I've
been using FreeBSD for a long time, and I think that it's about time
that I give something back to the Project.

Comment 3 Simon L. B. Nielsen 2004-12-12 23:23:11 UTC

State Changed
From-To: open->closed

Committed, thanks!

Comment 4 Simon L. B. Nielsen 2004-12-12 23:33:09 UTC

On 2004.12.05 21:43:07 +0000, Len Zettel wrote:
> On Sunday 05 December 2004 02:31 pm, Joel Dahl wrote:
>
> So while you were at it, why not go a little further----


I just committed the (almost) original version of Joel's patch.  I
didn't include your suggestions since I'm not a native English speaker
and therefor I prefer not to do more non-obvious English fixes.

It is also rather harder to read the differences as comments to a
diff, so it would be much better if you could send your comments /
suggestions as a patch in a seperate PR.

-- 
Simon L. Nielsen