Fixed typos.

Fork: 0

tundra / tperimeter

Browse code Fixed typos. master
1 parent b8497d1 commit d3997883dec9ad9d2c44352a62d7aaf8b21d9e09 tundra authored on 25 Sep 2006

Patch

Unified Split

Showing 1 changed file

                Ignore Space
               Show notes
              View
            
          
          10 ■■■■■
          tperimeter.txt
               .. footer:: $Id: tperimeter.txt,v 1.111 2006/09/25 18:50:18 tundra Exp $
.. footer:: $Id: tperimeter.txt,v 1.112 2006/09/25 18:56:13 tundra Exp $
 
 
=====================================================
``tperimeter`` - A Dynamic TCP Wrapper Control System
      dynamically rewriting the ``hosts.allow`` file.
 
  3) The ``cron`` job then *deletes* the request from the
     ``tperimeter`` queue.  This means that the next time
     ``hosts.allow`` is rebuilt by the ``cron``job, the "hole"
     ``hosts.allow`` is rebuilt by the ``cron`` job, the "hole"
     ``tperimeter`` opened in the tcp wrappers will be *removed*.
     This ensures that someone doesn't open a hole in the system that
     then stays there permanently.  This works fine in practice,
     because the tcp wrapper security model operates only at the time
parses the user's input and actually places it on the disk queue for
subsequent processing.
 
``rebuild-hosts.allow.sh`` is the tcp wrapper rewrite mechanism.
It is intended to be run periodically as a root ``cron``job.  Remember
It is intended to be run periodically as a root ``cron`` job.  Remember
that the "hole" ``tperimeter`` opens in your wrappers stays in
place until the *next time* the ``cron``job runs.  We thus recommend
place until the *next time* the ``cron`` job runs.  We thus recommend
running this script every 5 to 10 minutes to keep the window of
exposure small.
 
The queue where ``tperimeter`` requests are initially deposited and
wrapper configuration.  ``tperimeter`` has to know how to build your
"standard" tcp wrapper file - i.e., The ``hosts.allow`` entries you
*always* want in place regardless whether or not there is pending
requests for temporary access via the web interface.  That's because
``rebuild-hosts.allow.sh`` runs periodically under ``cron``control and
``rebuild-hosts.allow.sh`` runs periodically under ``cron`` control and
rebuilds the *entire* ``hosts.allow`` file.  
 
To make this simple, the list of things you always want in your
``hosts.allow`` file is represented by a directory tree with
+.. footer:: $Id: tperimeter.txt,v 1.111 2006/09/25 18:50:18 tundra Exp $
+.. footer:: $Id: tperimeter.txt,v 1.112 2006/09/25 18:56:13 tundra Exp $
 =====================================================
 ``tperimeter`` - A Dynamic TCP Wrapper Control System
       dynamically rewriting the ``hosts.allow`` file.
 ) The ``cron`` job then *deletes* the request from the
      ``tperimeter`` queue.  This means that the next time
+     ``hosts.allow`` is rebuilt by the ``cron``job, the "hole"
+     ``hosts.allow`` is rebuilt by the ``cron`` job, the "hole"
      ``tperimeter`` opened in the tcp wrappers will be *removed*.
      This ensures that someone doesn't open a hole in the system that
      then stays there permanently.  This works fine in practice,
      because the tcp wrapper security model operates only at the time
 parses the user's input and actually places it on the disk queue for
 subsequent processing.
 ``rebuild-hosts.allow.sh`` is the tcp wrapper rewrite mechanism.
+It is intended to be run periodically as a root ``cron``job.  Remember
+It is intended to be run periodically as a root ``cron`` job.  Remember
 that the "hole" ``tperimeter`` opens in your wrappers stays in
+place until the *next time* the ``cron``job runs.  We thus recommend
+place until the *next time* the ``cron`` job runs.  We thus recommend
 running this script every 5 to 10 minutes to keep the window of
 exposure small.
 The queue where ``tperimeter`` requests are initially deposited and
 wrapper configuration.  ``tperimeter`` has to know how to build your
 "standard" tcp wrapper file - i.e., The ``hosts.allow`` entries you
 *always* want in place regardless whether or not there is pending
 requests for temporary access via the web interface.  That's because
+``rebuild-hosts.allow.sh`` runs periodically under ``cron``control and
+``rebuild-hosts.allow.sh`` runs periodically under ``cron`` control and
 rebuilds the *entire* ``hosts.allow`` file.
 To make this simple, the list of things you always want in your
 ``hosts.allow`` file is represented by a directory tree with

Show line notes below