Merge pull request #1251 from vyos/mergify/bp/sagitta/pr-1247

Fix some spell mistakes (backport #1247)

12 files changed, 50 insertions, 29 deletions

diff --git a/docs/_ext/vyos.py b/docs/_ext/vyos.py
index fe0a258b..c1a96cd9 100644
--- a/docs/_ext/vyos.py
+++ b/docs/_ext/vyos.py
@@ -530,7 +530,7 @@ def strip_cmd(cmd, debug=False):
         if c == "]":
             appearance = appearance - 1
 
-    # only if all [..] will be delete if appearance > 0 there is a syntax errror
+    # only if all [..] will be delete if appearance > 0 there is a syntax error
     if appearance == 0:
         cmd = cmd_new
     
@@ -545,7 +545,7 @@ def strip_cmd(cmd, debug=False):
         if c == ">":
             appearance = appearance - 1
 
-    # only if all <..> will be delete if appearance > 0 there is a syntax errror
+    # only if all <..> will be delete if appearance > 0 there is a syntax error
     if appearance == 0:
         cmd = cmd_new
 
diff --git a/docs/automation/cloud-init.rst b/docs/automation/cloud-init.rst
index b396fee0..bbc8967c 100644
--- a/docs/automation/cloud-init.rst
+++ b/docs/automation/cloud-init.rst
@@ -268,7 +268,7 @@ Generate qcow image
 -------------------
 
 A VyOS qcow image with cloud-init options is needed. This can be obtained
-using `vyos-vm-images`_ repo. After clonning the repo, edit the file
+using `vyos-vm-images`_ repo. After cloning the repo, edit the file
 **qemu.yml** and comment the **download-iso** role.
 
 In this lab, we are using 1.3.0 VyOS version and setting a disk of 10G.
@@ -344,7 +344,7 @@ Content of network-config file:
        dhcp4: false
        dhcp6: false
 
-Finaly, file **meta-data** has no content, but it's required.
+Finally, file **meta-data** has no content, but it's required.
 
 ---------------
 Create seed.iso
@@ -360,7 +360,7 @@ Command for generating ``seed.iso``
   mkisofs -joliet -rock -volid "cidata" -output seed.iso meta-data \
   user-data network-config
 
-**NOTE**: be carefull while copying and pasting previous commands. Doble
+**NOTE**: be careful while copying and pasting previous commands. Double
 quotes may need to be corrected. 
 
 ---------------
diff --git a/docs/automation/command-scripting.rst b/docs/automation/command-scripting.rst
index 64564e5a..aaa60957 100644
--- a/docs/automation/command-scripting.rst
+++ b/docs/automation/command-scripting.rst
@@ -49,7 +49,7 @@ prepended with ``run``, even if you haven't created a session with configure.
 Run commands remotely
 ---------------------
 
-Sometimes you simply wan't to execute a bunch of op-mode commands via SSH on
+Sometimes you simply want to execute a bunch of op-mode commands via SSH on
 a remote VyOS system.
 
 .. code-block:: none
diff --git a/docs/automation/vyos-netmiko.rst b/docs/automation/vyos-netmiko.rst
index e57e0c78..075b0f34 100644
--- a/docs/automation/vyos-netmiko.rst
+++ b/docs/automation/vyos-netmiko.rst
@@ -32,7 +32,7 @@ Example
                      'set interfaces ethernet eth1 description LAN',
                     ]
 
-  # set congiguration
+  # set configuration
   output = net_connect.send_config_set(config_commands, exit_config_mode=False)
   print(output)
 
@@ -69,4 +69,4 @@ Output
   vtun10           10.10.0.1/24                      u/u  
   [edit]
 
-.. _netmiko: https://github.com/ktbyers/netmiko
\ No newline at end of file
+.. _netmiko: https://github.com/ktbyers/netmiko
diff --git a/docs/cli.rst b/docs/cli.rst
index 0a5fddf9..55ec2be0 100644
--- a/docs/cli.rst
+++ b/docs/cli.rst
@@ -558,7 +558,7 @@ different levels in the hierarchy.
    What if you are doing something dangerous? Suppose you want to setup
    a firewall, and you are not sure there are no mistakes that will lock
    you out of your system. You can use confirmed commit. If you issue
-   the ``commit-confirm`` command, your changes will be commited, and if
+   the ``commit-confirm`` command, your changes will be committed, and if
    you don't issue  the ``confirm`` command in 10 minutes, your
    system will reboot into previous config revision.
 
@@ -653,7 +653,7 @@ different levels in the hierarchy.
    The ``comment`` command allows you to insert a comment above the
    ``<config node>`` configuration section. When shown, comments are
    enclosed with ``/*`` and ``*/`` as open/close delimiters. Comments
-   need to be commited, just like other config changes.
+   need to be committed, just like other config changes.
 
    To remove an existing comment from your current configuration,
    specify an empty string enclosed in double quote marks (``""``) as
@@ -852,7 +852,7 @@ Remote Archive
 VyOS can upload the configuration to a remote location after each call
 to :cfgcmd:`commit`. You will have to set the commit-archive location.
 TFTP, FTP, SCP and SFTP servers are supported. Every time a
-:cfgcmd:`commit` is successfull the ``config.boot`` file will be copied
+:cfgcmd:`commit` is successful the ``config.boot`` file will be copied
 to the defined destination(s). The filename used on the remote host will
 be ``config.boot-hostname.YYYYMMDD_HHMMSS``. 
 
diff --git a/docs/contributing/build-vyos.rst b/docs/contributing/build-vyos.rst
index 6718940c..a9dacda4 100644
--- a/docs/contributing/build-vyos.rst
+++ b/docs/contributing/build-vyos.rst
@@ -349,7 +349,7 @@ more or less similar looking error message:
   (10:13) vyos_bld ece068908a5b:/vyos [current] #
 
 To debug the build process and gain additional information of what could be the
-root cause, you need to use `chroot` to change into the build directry. This is
+root cause, you need to use `chroot` to change into the build directory. This is
 explained in the following step by step procedure:
 
 .. code-block:: none
diff --git a/docs/contributing/debugging.rst b/docs/contributing/debugging.rst
index fec73257..e03f3f81 100644
--- a/docs/contributing/debugging.rst
+++ b/docs/contributing/debugging.rst
@@ -125,7 +125,7 @@ You can type ``help`` to get an overview of the available commands, and
 Useful commands are:
 
 * examine variables using ``pp(var)``
-* contine execution using ``cont``
+* continue execution using ``cont``
 * get a backtrace using ``bt``
 
 Config Migration Scripts
@@ -147,7 +147,7 @@ look like:
 
 The reason is that the configuration migration backend is rewritten and uses
 a new form of "magic string" which is applied on demand when real config
-migration is run on boot. When runnint individual migrators for testing,
+migration is run on boot. When running individual migrators for testing,
 you need to convert the "magic string" on your own by:
 
 .. code-block:: none
@@ -157,13 +157,13 @@ you need to convert the "magic string" on your own by:
 Configuration Error on System Boot
 ----------------------------------
 
-Beeing brave and running the latest rolling releases will sometimes trigger
+Being brave and running the latest rolling releases will sometimes trigger
 bugs due to corner cases we missed in our design. Those bugs should be filed
-via Phabricator_ but you can help us to narrow doen the issue. Login to your
+via Phabricator_ but you can help us to narrow down the issue. Login to your
 VyOS system and change into configuration mode by typing ``configure``. Now
 re-load your boot configuration by simply typing ``load`` followed by return.
 
-You shoudl now see a Python backtrace which will help us to handle the issue,
+You should now see a Python backtrace which will help us to handle the issue,
 please attach it to the Phabricator_ task.
 
 Boot Timing
@@ -179,7 +179,7 @@ installed by default on the VyOS 1.3 (equuleus) branch. The configuration is
 also versioned so we get comparable results. ``systemd-bootchart`` is configured
 using this file: bootchart.conf_
 
-To enable boot time graphing change the Kernel commandline and add the folowing
+To enable boot time graphing change the Kernel commandline and add the following
 string: ``init=/usr/lib/systemd/systemd-bootchart``
 
 This can also be done permanently by changing ``/boot/grub/grub.cfg``.
@@ -190,7 +190,7 @@ Priorities
 VyOS CLI is all about priorities. Every CLI node has a corresponding
 ``node.def`` file and possibly an attached script that is executed when the
 node is present. Nodes can have a priority, and on system bootup - or any
-other ``commit`` to the config all scripts are executed from lowest to higest
+other ``commit`` to the config all scripts are executed from lowest to highest
 priority. This is good as this gives a deterministic behavior.
 
 To debug issues in priorities or to see what's going on in the background
diff --git a/docs/contributing/development.rst b/docs/contributing/development.rst
index 1f296144..e39af3a5 100644
--- a/docs/contributing/development.rst
+++ b/docs/contributing/development.rst
@@ -252,7 +252,7 @@ contributors to navigate through the sources and all the implied logic of
 the spaghetti code.
 
 Please use the following template as good starting point when developing new
-modules or even rewrite a whole bunch of code in the new style XML/Pyhon
+modules or even rewrite a whole bunch of code in the new style XML/Python
 interface.
 
 
diff --git a/docs/contributing/testing.rst b/docs/contributing/testing.rst
index 772ff04a..78860c06 100644
--- a/docs/contributing/testing.rst
+++ b/docs/contributing/testing.rst
@@ -20,7 +20,7 @@ Jenkins CI
 Our `VyOS CI`_ system is based on Jenkins and builds all our required packages
 for VyOS 1.2 to 1.4. In addition to the package build, there is the vyos-build
 Job which builds and tests the VyOS ISO image which is published after a
-successfull test drive.
+successful test drive.
 
 We differentiate in two independent tests, which are both run in parallel by
 two separate QEmu instances which are launched via ``make test`` and ``make
@@ -42,7 +42,7 @@ with the following packages:
     if (params.BUILD_SMOKETESTS)
       CUSTOM_PACKAGES = '--custom-package vyos-1x-smoketest'
 
-So if you plan to build your own custom ISO image and wan't to make use of our
+So if you plan to build your own custom ISO image and want to make use of our
 smoketests, ensure that you have the `vyos-1x-smoketest` package installed.
 
 The ``make test`` command from the vyos-build_ repository will launch a new
@@ -106,7 +106,7 @@ Those common tests consists out of:
 * VLANs (QinQ and regular 802.1q)
 * ...
 
-.. note:: When you are working on interface configuration and you also wan't to
+.. note:: When you are working on interface configuration and you also want to
    test if the Smoketests pass you would normally loose the remote SSH connection
    to your :abbr:`DUT (Device Under Test)`. To handle this issue, some of the
    interface based tests can be called with an environment variable beforehand
diff --git a/docs/documentation.rst b/docs/documentation.rst
index 1d7e3402..91f0e42b 100644
--- a/docs/documentation.rst
+++ b/docs/documentation.rst
@@ -146,7 +146,7 @@ access to the official codebase.
 Style Guide
 ===========
 
-Formating and Sphinxmarkup
+Formatting and Sphinxmarkup
 --------------------------
 
 TOC Level
diff --git a/docs/installation/cloud/aws.rst b/docs/installation/cloud/aws.rst
index da0c46d3..992e2609 100644
--- a/docs/installation/cloud/aws.rst
+++ b/docs/installation/cloud/aws.rst
@@ -25,7 +25,7 @@ Deploy VyOS on Amazon :abbr:`AWS (Amazon Web Services)`
 .. figure:: /_static/images/cloud-aws-04.png
 
 5. Additional storage. You can remove additional storage ``/dev/sdb``. First
-   root device will be ``/dev/xvda``. You can skeep this step.
+   root device will be ``/dev/xvda``. You can skip this step.
 
 .. figure:: /_static/images/cloud-aws-05.png
 
@@ -66,7 +66,7 @@ To use Amazon CloudWatch Agent, configure it within the Amazon SSM Parameter Sto
 
   .. note:: The amazon-cloudwatch-agent package is normally included in VyOS 1.3.3+ and 1.4+
 
-3. Retreive an existing CloudWatch Agent configuration from the :abbr:`SSM (Systems Manager)` Parameter Store.
+3. Retrieve an existing CloudWatch Agent configuration from the :abbr:`SSM (Systems Manager)` Parameter Store.
 
   .. code-block:: none
 
@@ -85,7 +85,7 @@ Creating the Amazon Cloudwatch Agent Configuration in Amazon :abbr:`SSM (Systems
 
 1. Create an :abbr:`IAM (Identity and Access Management)` role for your :abbr:`EC2 (Elastic Compute Cloud)` instance to access the CloudWatch service. Name it CloudWatchAgentAdminRole. The role should contain at two default policies: CloudWatchAgentAdminPolicy and AmazonSSMManagedInstanceCore.  
 
-  .. note:: CloudWatchAgentServerRole is too permisive and should be used for single configuration creation and deployment. That's why after completion of step #3 higly recommended to replace instance CloudWatchAgentAdminRole role with CloudWatchAgentServerRole.
+  .. note:: CloudWatchAgentServerRole is too permissive and should be used for single configuration creation and deployment. That's why after completion of step #3 highly recommended to replace instance CloudWatchAgentAdminRole role with CloudWatchAgentServerRole.
 
 2. Run Cloudwatch configuration wizard.
 
@@ -99,4 +99,4 @@ References
 ----------
 - https://console.aws.amazon.com/
 - https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent.html
-- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance-fleet.html
\ No newline at end of file
+- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance-fleet.html
diff --git a/docs/quick-start.rst b/docs/quick-start.rst
index c8bb3f04..f0a3c828 100644
--- a/docs/quick-start.rst
+++ b/docs/quick-start.rst
@@ -158,8 +158,29 @@ Configure Stateful Packet Filtering
 With the new firewall structure, we have have a lot of flexibility in how we
 group and order our rules, as shown by the two alternative approaches below.
 
+<<<<<<< HEAD
 Option 1: Common Chain
 ^^^^^^^^^^^^^^^^^^^^^^
+=======
+Option 1: Global State Policies
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Using options defined in ``set firewall global-options state-policy``, state
+policy rules that applies for both IPv4 and IPv6 are created. These global
+state policies also applies for all traffic that passes through the router
+(transit) and for traffic originated/destinated to/from the router itself, and
+will be evaluated before any other rule defined in the firewall.
+
+Most installations would choose this option, and will contain:
+
+.. code-block:: none
+
+  set firewall global-options state-policy established action accept
+  set firewall global-options state-policy related action accept
+  set firewall global-options state-policy invalid action drop
+
+Option 2: Common/Custom Chain
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+>>>>>>> 32460e70 (Fix typos in quick-start)
 
 We can create a common chain for stateful connection filtering of multiple
 interfaces (or multiple netfilter hooks on one interface). Those individual
@@ -225,7 +246,7 @@ established and related connections, we can block all other incoming traffic
 addressed to our local network.
 
 Create a new chain (``OUTSIDE-IN``) which will drop all traffic that is not
-explicity allowed at some point in the chain. Then, we can jump to that chain
+explicitly allowed at some point in the chain. Then, we can jump to that chain
 from the ``forward`` hook when traffic is coming from the ``WAN`` interface
 group and is addressed to our local network.