Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Aug 2001 21:31:32 -0700 (PDT)
From:      ncalvo <ncalvo@es.freebsd.org>
To:        freebsd-gnats-submit@freebsd.org
Subject:   docs/29744: [PATCH] SGML tags and entities in the "Dialup firewalling with FreeBSD" article (minor nit-picking)
Message-ID:  <200108160431.f7G4VWh64514@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         29744
>Category:       docs
>Synopsis:       [PATCH] SGML tags and entities in the "Dialup firewalling with FreeBSD" article (minor nit-picking)
>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:   Wed Aug 15 21:40:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     ncalvo
>Release:        4.3-RELEASE
>Organization:
>Environment:
FreeBSD amnesiac.no.domain 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Tue Aug  7 02:33:38 CEST 2001     root@amnesiac.no.domain:/usr/src/sys/compile/AMNESIAC  i386
>Description:
SGML markup changes to the article "Dialup firewalling with FreeBSD",
which is part of the FreeBSD documentation:

http://www.FreeBSD.org/cgi/cvsweb.cgi/doc/en_US.ISO8859-1/articles/dialup-firewall/article.sgml

Please note that the enclosed patch is relative to the referenced file
(post pr docs/29086), not the one corresponding to 4.3-RELEASE.

Nothing really important, just minor nit-picking.


>How-To-Repeat:
N/A
>Fix:
(patch follows; length==54 lines)

--- article.sgml.orig   Thu Aug 16 06:02:35 2001
+++ article.sgml        Thu Aug 16 06:19:57 2001
@@ -28,7 +28,7 @@
 
     <abstract>
       <para>This article documents how to setup a firewall using a PPP
-       dialup with FreeBSD and IPFW, and specifically with firewalling over
+       dialup with FreeBSD and &man.ipfw.8;, and specifically with firewalling over
        a dialup with a dynamically assigned IP address.  This document does
        not cover setting up your PPP connection in the first place.</para>
     </abstract>
@@ -175,7 +175,7 @@
       order of allow first and  then deny. The premise is that you add the
       rules for your allows, and  then everything else is denied. :)</para>
 
-    <para>Now, let's make the dir /etc/firewall. Change into the directory and
+    <para>Now, let's make the dir <filename>/etc/firewall</filename>. Change into the directory and
       edit the file <filename>fwrules</filename> as we specified in
       <filename>rc.conf</filename>. Please note that you can change this
       filename to be anything you wish. This guide just gives an example of a
@@ -247,16 +247,16 @@
     <qandaset>
       <qandaentry>
        <question>
-         <para>Why are you using natd and ipfw when you could be using
-           the built in ppp-filters?</para>
+         <para>Why are you using &man.natd.8; and &man.ipfw.8; when you could be using
+           the built in &man.ppp.8; filters?</para>
        </question>
 
        <answer>
          <para>I'll have to be honest and say there's no definitive reason
-           why I use ipfw and natd instead of the built in ppp filters.  From
+           why I use &man.ipfw.8; and &man.natd.8; instead of the built in &man.ppp.8; filters.  From
            the discussions I've had with people the consensus seems to be
-           that while ipfw is certainly more powerful and more configurable
-           than the ppp filters, what it makes up for in functionality it
+           that while &man.ipfw.8; is certainly more powerful and more configurable
+           than the &man.ppp.8; filters, what it makes up for in functionality it
            loses in being easy to customise.  One of the reasons I use it is
            because I prefer firewalling to be done at a kernel level rather
            than by a userland program.</para>
@@ -289,9 +289,9 @@
        </question>
 
        <answer>
-         <para>The simple answer is no. The reason for this is that natd is
+         <para>The simple answer is no. The reason for this is that &man.natd.8; is
            doing address translation for <emphasis>anything</emphasis> being
-           diverted through the tun0 device. As far as it's concerned
+           diverted through the <devicename>tun0</devicename> device. As far as it's concerned
            incoming packets will speak only to the dynamically assigned IP
            address and NOT to the internal network. Note though that you can
            add a rule like <literal>$fwcmd add deny all from


>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108160431.f7G4VWh64514>