diff options
| -rw-r--r-- | docs/_ext/vyos.py | 4 | ||||
| -rw-r--r-- | docs/automation/cloud-init.rst | 6 | ||||
| -rw-r--r-- | docs/automation/command-scripting.rst | 2 | ||||
| -rw-r--r-- | docs/automation/vyos-netmiko.rst | 4 | ||||
| -rw-r--r-- | docs/cli.rst | 6 | ||||
| -rw-r--r-- | docs/contributing/build-vyos.rst | 2 | ||||
| -rw-r--r-- | docs/contributing/debugging.rst | 14 | ||||
| -rw-r--r-- | docs/contributing/development.rst | 2 | ||||
| -rw-r--r-- | docs/contributing/testing.rst | 6 | ||||
| -rw-r--r-- | docs/documentation.rst | 2 | ||||
| -rw-r--r-- | docs/installation/cloud/aws.rst | 8 | ||||
| -rw-r--r-- | docs/quick-start.rst | 4 | ||||
| -rw-r--r-- | docs/troubleshooting/index.rst | 2 |
13 files changed, 31 insertions, 31 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 c8a72a36..cc67132c 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 ee9c49ed..41b4b9e0 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 919f30bf..16eb8ac7 100644 --- a/docs/contributing/build-vyos.rst +++ b/docs/contributing/build-vyos.rst @@ -371,7 +371,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 cf930bdd..49f5aeb6 100644 --- a/docs/quick-start.rst +++ b/docs/quick-start.rst @@ -165,7 +165,7 @@ 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 avaluated before any other rule defined in the firewall. +will be evaluated before any other rule defined in the firewall. Most installations would choose this option, and will contain: @@ -241,7 +241,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. diff --git a/docs/troubleshooting/index.rst b/docs/troubleshooting/index.rst index 902acf3a..8a34edd9 100644 --- a/docs/troubleshooting/index.rst +++ b/docs/troubleshooting/index.rst @@ -378,7 +378,7 @@ to clear interface counters # clear all interfaces vyos@vyos:~$ clear interface ethernet counters # clear specific interface - vyos@vyos:~$ clear interface ehternet eth0 counters + vyos@vyos:~$ clear interface ethernet eth0 counters The command follow the same logic as the ``set`` command in configuration mode. |