Attachment 22456 Details for Bug 38951 – article.sgml.diff

[patch] article.sgml.diff

article.sgml.diff (text/plain), 5.77 KB, created by Marc Fonvieille on 2002-06-06 18:10:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Marc Fonvieille

Created: 2002-06-06 18:10:01 UTC

Size: 5.77 KB

patch

obsolete

>--- 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>

Actions: View | Diff

Attachments on bug 38951: 22456