Date: Thu, 6 Jun 2002 18:58:18 +0200 (CEST) From: Marc Fonvieille <marc@blackend.org> To: FreeBSD-gnats-submit@FreeBSD.org Subject: docs/38951: Quotation marks in filtering-bridges article should be replaced by appropriate tags Message-ID: <200206061658.g56GwI04013187@abigail.blackend.org>
next in thread | raw e-mail | index | archive | help
>Number: 38951
>Category: docs
>Synopsis: Quotation marks in filtering-bridges article should be replaced by appropriate tags
>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: Thu Jun 06 10:10:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Marc Fonvieille
>Release: FreeBSD 4.6-PRERELEASE i386
>Organization:
>Environment:
System: FreeBSD abigail.blackend.org 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #5: Sun May 12 00:30:43 CEST 2002 marc@abigail.blackend.org:/usr/src/sys/compile/ABIGAIL i386
>Description:
Quotation marks in filtering-bridges article should be replaced by
appropriate tags. Read the patch below for more details.
>How-To-Repeat:
>Fix:
Apply the patch to articles/filtering-bridges/article.sgml
--- article.sgml.diff begins here ---
--- article.sgml.org Thu Jun 6 18:42:04 2002
+++ article.sgml Thu Jun 6 18:50:04 2002
@@ -128,7 +128,7 @@
modules (according to the previously choosen installation method), you
have to make some changes to the <filename>/etc/rc.conf</filename>
configuration file. The default rule of the firewall is to reject all IP
- packets. Initially we'll set up an 'open' firewall, in order to verify
+ packets. Initially we'll set up an <option>open</option> firewall, in order to verify
its operation without any issue related to packet filtering (in case you
are going to execute this procedure remotely, such configuration will
avoid you to remain isolated from the network). Put these lines in
@@ -141,7 +141,7 @@
<para>The first row will enable the firewall (and will load the module
<filename>ipfw.ko</filename> if it is not compiled in the kernel), the
- second one to set up it in 'open' mode (as explained in
+ second one to set up it in <option>open</option> mode (as explained in
<filename>/etc/rc.firewall</filename>), the third one to not show rules
loading and the fourth one to enable logging support.</para>
@@ -178,7 +178,7 @@
<para>Now it's time to reboot the system and use it as before: there will
be some new messages about the bridge and the firewall, but the bridge
- will not be activated and the firewall, being in 'open' mode, will not
+ will not be activated and the firewall, being in <option>open</option> mode, will not
avoid any operations.</para>
<para>If there are any problems, you should sort them out now
@@ -220,11 +220,11 @@
are being received by the local machine. In general, incoming packets
are run through the firewall only once, not twice as is normally the
case; in fact they are filtered only upon receipt, so rules that use
- 'out' or 'xmit' will never match. Personally, I use 'in via' which is an
+ <option>out</option> or <option>xmit</option> will never match. Personally, I use <option>in via</option> which is an
older syntax, but one that has a sense when you read it. Another
- limitation is that you are restricted to use only 'pass' or 'drop'
+ limitation is that you are restricted to use only <option>pass</option> or <option>drop</option>
commands for packets filtered by a bridge. Sophisticated things like
- 'divert', 'forward' or 'reject' are not available. Such options can
+ <option>divert</option>, <option>forward</option> or <option>reject</option> are not available. Such options can
still be used, but only on traffic to or from the bridge machine itself
(if it has an IP address).</para>
@@ -234,7 +234,7 @@
exact same set of IP addresses and port numbers (but with source and
destination reversed, of course). For firewalls that have no
statekeeping, there is almost no way to deal with this sort of traffic
- as a single session. But with a firewall that can "remember" an outgoing
+ as a single session. But with a firewall that can <quote>remember</quote> an outgoing
<acronym>UDP</acronym> packet and, for the next few minutes, allow a
response, handling <acronym>UDP</acronym> services is trivial. The
following example shows how to do it. It's possible to do the same thing
@@ -248,7 +248,7 @@
have to care for them anymore. Custom rules should be put in a separate
file (say <filename>/etc/rc.firewall.local</filename>) and loaded at
system startup, by modifying the row of
- <filename>/etc/rc.conf</filename> where we defined the 'open'
+ <filename>/etc/rc.conf</filename> where we defined the <option>open</option>
firewall:</para>
<programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
@@ -338,14 +338,14 @@
server, if you have them. Obviously the whole rule set should be
flavored to personal taste, this is only a specific example (rule format
is described accurately in the &man.ipfw.8; man page). Note that in
- order for 'relay' and 'ns' to work, name service lookups must work
+ order for <quote>relay</quote> and <quote>ns</quote> to work, name service lookups must work
<emphasis>before</emphasis> the bridge is enabled. This is an example of
making sure that you set the IP on the correct network card.
Alternatively it is possible to specify the IP address instead of the
host name (required if the machine is IP-less).</para>
<para>People that are used to setting up firewalls are probably also used
- to either having a 'reset' or a 'forward' rule for ident packets
+ to either having a <option>reset</option> or a <option>forward</option> rule for ident packets
(<acronym>TCP</acronym> port 113). Unfortunately, this is not an
applicable option with the bridge, so the best thing is to simply pass
them to their destination. As long as that destination machine is not
@@ -360,9 +360,9 @@
of traffic will take different paths through the kernel and into the
packet filter. The inside net will go through the bridge, while the
local machine will use the normal IP stack to speak. Thus the two rules
- to handle the different cases. The 'in via
- <devicename>fxp0</devicename>' rules work for both paths. In general, if
- you use 'in via' rules throughout the filter, you will need to make an
+ to handle the different cases. The <option>in via
+ <devicename>fxp0</devicename></option> rules work for both paths. In general, if
+ you use <option>in via</option> rules throughout the filter, you will need to make an
exception for locally generated packets, because they did not come in
via any of our interfaces.</para>
</sect1>
--- article.sgml.diff ends here ---
>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?200206061658.g56GwI04013187>