vyos/vyos-documentation
1
0
Fork 0
mirror of https://github.com/vyos/vyos-documentation.git synced 2025-11-03 04:12:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
Fix some spell mistakes (backport #1247)
This commit is contained in:
Daniil Baturin 2024-02-09 09:30:53 +00:00 committed by GitHub
commit 9e9216768f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
12 changed files with 50 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/_ext/vyos.py
View File

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

6
docs/automation/cloud-init.rst
View File

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

2
docs/automation/command-scripting.rst
View File

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

2
docs/automation/vyos-netmiko.rst
View File

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

6
docs/cli.rst
View File

@ -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``.

2
docs/contributing/build-vyos.rst
View File

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

14
docs/contributing/debugging.rst
View File

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

2
docs/contributing/development.rst
View File

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

6
docs/contributing/testing.rst
View File

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

2
docs/documentation.rst
View File

@ -146,7 +146,7 @@ access to the official codebase.
Style Guide
===========
Formating and Sphinxmarkup
Formatting and Sphinxmarkup
--------------------------
TOC Level

6
docs/installation/cloud/aws.rst
View File

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

23
docs/quick-start.rst
View File

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