summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/build-vyos.rst2
-rw-r--r--docs/clustering.rst2
-rw-r--r--docs/configuration-overview.rst6
-rw-r--r--docs/contributing/coding_guidelines.rst4
-rw-r--r--docs/contributing/development.rst2
-rw-r--r--docs/contributing/vyos_cli.rst4
-rw-r--r--docs/high-availability.rst4
-rw-r--r--docs/install.rst6
-rw-r--r--docs/qos.rst4
-rw-r--r--docs/routing/mss-clamp.rst2
-rw-r--r--docs/services/index.rst2
-rw-r--r--docs/services/lldp.rst2
-rw-r--r--docs/services/pppoe-server.rst8
-rw-r--r--docs/services/ssh.rst6
-rw-r--r--docs/services/sstp-server.rst2
-rw-r--r--docs/vpn/index.rst2
-rw-r--r--docs/vpn/openvpn.rst8
-rw-r--r--docs/vpn/site2site_ipsec.rst2
-rw-r--r--docs/vpn/wireguard.rst2
19 files changed, 35 insertions, 35 deletions
diff --git a/docs/build-vyos.rst b/docs/build-vyos.rst
index 2ea2c217..bcd32ecb 100644
--- a/docs/build-vyos.rst
+++ b/docs/build-vyos.rst
@@ -13,7 +13,7 @@ Docker and works best on a fresh installation of Debain 8 (Jessie).
the community. Since the source code is still public you can build your own
ISO using the process described here.
-Installing Docker and it's prequisites
+Installing Docker and it's prerequisites
.. code-block:: sh
diff --git a/docs/clustering.rst b/docs/clustering.rst
index 74cfcf42..d51f0073 100644
--- a/docs/clustering.rst
+++ b/docs/clustering.rst
@@ -3,7 +3,7 @@
Clustering
==========
-The cluster feature allows 2 vyos routers to share IP adresses and various services.
+The cluster feature allows 2 vyos routers to share IP addresses and various services.
VyOS supports multicast clustering.
diff --git a/docs/configuration-overview.rst b/docs/configuration-overview.rst
index 5bd80028..3a1014f0 100644
--- a/docs/configuration-overview.rst
+++ b/docs/configuration-overview.rst
@@ -105,7 +105,7 @@ The working configuration is the configuration which is currently being modified
Saved configuration
^^^^^^^^^^^^^^^^^^^
-A saved configuration is a configuration saved to a file using the `save` command. It allowes you to keep safe a configuration for future uses. There can be multiple configuration files. The default or "boot" configuration is saved and loaded from the file config.boot.
+A saved configuration is a configuration saved to a file using the `save` command. It allows you to keep safe a configuration for future uses. There can be multiple configuration files. The default or "boot" configuration is saved and loaded from the file config.boot.
Navigating in Configuration Mode
@@ -206,7 +206,7 @@ Managing the configuration
--------------------------
The configuration is managed by the use of `set` and `delete` commands from within configuration mode.
-Configuration commands are flattend from the tree into 'one-liner' commands shown in `show configuration commands` from operation mode.
+Configuration commands are flattened from the tree into 'one-liner' commands shown in `show configuration commands` from operation mode.
These commands are also relative to the level where they are executed and all redundant information from the current level is removed from the command entered.
@@ -370,7 +370,7 @@ To view existing revisions, use `show system commit` operational mode command.
6 2015-03-25 00:16:47 by vyos via cli
7 2015-03-24 23:43:45 by root via boot-config-loader
-You can compare revisions with `compare X Y` command, where X and Y are revision numbers. The output will describe how the configuration X is when comparted to Y, indicating with a plus sign (**+**) the additional parts X has when compared to y, and indicating with a minus sign (**-**) the lacking parts x misses when compared to y.
+You can compare revisions with `compare X Y` command, where X and Y are revision numbers. The output will describe how the configuration X is when compared to Y, indicating with a plus sign (**+**) the additional parts X has when compared to y, and indicating with a minus sign (**-**) the lacking parts x misses when compared to y.
.. code-block:: sh
diff --git a/docs/contributing/coding_guidelines.rst b/docs/contributing/coding_guidelines.rst
index ff863d61..9c996518 100644
--- a/docs/contributing/coding_guidelines.rst
+++ b/docs/contributing/coding_guidelines.rst
@@ -54,7 +54,7 @@ The **get_config()** function must convert the VyOS config to an abstract intern
representation. No other function is allowed to call ``vyos.config.Config`` object
methods directly. The rationale for it is that when config reads are mixed with
other logic, it's very hard to change the config syntax since you need to weed
-out every occurence of the old syntax. If syntax-specific code is confined to a
+out every occurrence of the old syntax. If syntax-specific code is confined to a
single function, the rest of the code can be left untouched as long as the
internal representation remains compatible.
@@ -75,7 +75,7 @@ The **apply()** function applies the generated configuration to the live system.
It should use non-disruptive reload whenever possible. It may execute disruptive
operations such as daemon process restart if a particular component does not
support non-disruptive reload, or when the expected service degradation is minimal
-(for example, in case of auxillary services such as LLDPd). In case of high impact
+(for example, in case of auxiliary services such as LLDPd). In case of high impact
services such as VPN daemon and routing protocols, when non-disruptive reload is
supported for some but not all types of configuration changes, scripts authors
should make effort to determine if a configuration change can be done in a
diff --git a/docs/contributing/development.rst b/docs/contributing/development.rst
index 4b762051..9e99ece8 100644
--- a/docs/contributing/development.rst
+++ b/docs/contributing/development.rst
@@ -31,7 +31,7 @@ This information is used in two ways:
* Keep track of the progress (what we've already done in this branch and what we still need to do).
* Prepare release notes.
-To make this approach work, every change must be associated with a bug number and componant.
+To make this approach work, every change must be associated with a bug number and component.
If there is no bug/enhancement request for the changes you are going to make, you must create a `bugtracker`_ entry first.
Once there is a `bugtracker`_ entry about it, you should reference in your commit message, as in:
diff --git a/docs/contributing/vyos_cli.rst b/docs/contributing/vyos_cli.rst
index f539efda..49f9a230 100644
--- a/docs/contributing/vyos_cli.rst
+++ b/docs/contributing/vyos_cli.rst
@@ -5,8 +5,8 @@ VyOS CLI
The bash completion in VyOS is defined in *templates*. Templates are text files
stored in a directory tree, where directory names define command names, and
-template files define command behaviour. Befor VyOS 1.2.x this files were created
-by hand. After a complex redesing process_ the new style template are in XML.
+template files define command behaviour. Before VyOS 1.2.x this files were created
+by hand. After a complex redesign process_ the new style template are in XML.
XML interface definitions for VyOS come with a RelaxNG schema and are located
in the vyos-1x_ module. This schema is a slightly modified schema from VyConf_
diff --git a/docs/high-availability.rst b/docs/high-availability.rst
index 9f4dd35d..54f2f388 100644
--- a/docs/high-availability.rst
+++ b/docs/high-availability.rst
@@ -61,12 +61,12 @@ VRRP priority can be set with ``priority`` option:
set high-availability vrrp group Foo priority 200
-The priority must be an interger number from 1 to 255. Higher priority value increases router's precedence in the master elections.
+The priority must be an integer number from 1 to 255. Higher priority value increases router's precedence in the master elections.
Preemption
----------
-VRRP can use two modes: preemptive and non-preemptive. In the preemptive mode, if a router with a higher priority fails and then comes back, routers with lower priority will give up their master status. In non-preemptive mode, the newly elected master will keep the master status and the virtual address indenfinitely.
+VRRP can use two modes: preemptive and non-preemptive. In the preemptive mode, if a router with a higher priority fails and then comes back, routers with lower priority will give up their master status. In non-preemptive mode, the newly elected master will keep the master status and the virtual address indefinitely.
By default VRRP uses preemption. You can disable it with the "no-preempt" option:
diff --git a/docs/install.rst b/docs/install.rst
index ba311a41..f64cf636 100644
--- a/docs/install.rst
+++ b/docs/install.rst
@@ -18,13 +18,13 @@ Registered subscribers can download stable release (LTS) images. If you log into
Non-subscribers can get the LTS release by building it from source. Just follow the instructions in
https://github.com/vyos/vyos-build
-Everyone can dowload VyOS rolling images from https://downloads.vyos.io/
+Everyone can download VyOS rolling images from https://downloads.vyos.io/
Preparing software verification
-------------------------------
-This subsection and the following one applies to dowloaded LTS images, for other cases please jump to :ref:`Install`.
+This subsection and the following one applies to downloaded LTS images, for other cases please jump to :ref:`Install`.
LTS images are signed by VyOS lead package-maintainer private key. If you have our public key, you will be able to verify the authenticity of the package.
@@ -123,7 +123,7 @@ GPG verification
As you have our public key, you just need the signature of the software you want to verify.
-.. note:: **In order to get the signature, go to your web browser and append .asc to the URL of your dowloaded VyOS image**. You will download a small *.asc* file, that's the signature of your image.
+.. note:: **In order to get the signature, go to your web browser and append .asc to the URL of your downloaded VyOS image**. You will download a small *.asc* file, that's the signature of your image.
So finally you can verify the authenticity of your image.
diff --git a/docs/qos.rst b/docs/qos.rst
index d68919d7..adf59108 100644
--- a/docs/qos.rst
+++ b/docs/qos.rst
@@ -809,7 +809,7 @@ Available commands:
:code:`set traffic-policy round-robin <policy name> default quantum <packets>`
-* Define a maximum queue lenght for the default policy in packets:
+* Define a maximum queue length for the default policy in packets:
:code:`set traffic-policy round-robin <policy name> default queue-limit <limit>`
@@ -926,7 +926,7 @@ different amounts of bandwidth to different traffic classes. In contrast to
round robin, shaper limits bandwidth allocation by traffic class whereas round
robin divides the total available bandwidth between classes.
-Avialable commands:
+Available commands:
* Define a shaper policy:
diff --git a/docs/routing/mss-clamp.rst b/docs/routing/mss-clamp.rst
index 9409690a..7cec4b7c 100644
--- a/docs/routing/mss-clamp.rst
+++ b/docs/routing/mss-clamp.rst
@@ -7,7 +7,7 @@ As Internet wide PMTU discovery rarely works we sometimes need to clamp our TCP
MSS value to a specific value. Starting with VyOS 1.2 there is a firewall option
to clamp your TCP MSS value for IPv4 and IPv6.
-Clamping can be disabled per interface using the `disable` keywork:
+Clamping can be disabled per interface using the `disable` keyword:
.. code-block:: sh
diff --git a/docs/services/index.rst b/docs/services/index.rst
index 8f7553a8..3e81b7a9 100644
--- a/docs/services/index.rst
+++ b/docs/services/index.rst
@@ -5,7 +5,7 @@
Services
========
-This chapter descriptes the available system/network services provided by VyOS.
+This chapter describes the available system/network services provided by VyOS.
.. toctree::
:maxdepth: 1
diff --git a/docs/services/lldp.rst b/docs/services/lldp.rst
index 6a3bee7b..37214506 100644
--- a/docs/services/lldp.rst
+++ b/docs/services/lldp.rst
@@ -92,6 +92,6 @@ Exemple:
Troubleshooting
^^^^^^^^^^^^^^^
-Use operationnal command ``show log lldp`` to display logs.
+Use operational command ``show log lldp`` to display logs.
.. include:: references.rst
diff --git a/docs/services/pppoe-server.rst b/docs/services/pppoe-server.rst
index 2acc93f1..03e14971 100644
--- a/docs/services/pppoe-server.rst
+++ b/docs/services/pppoe-server.rst
@@ -41,12 +41,12 @@ Connections can be locally checked via the command
Client IP address pools
=======================
-To automatically assign the client an IP address as tunnel endpoint, a client IP pool is needed. The source can be either RADIUS or a local subnet or IP range defintion.
+To automatically assign the client an IP address as tunnel endpoint, a client IP pool is needed. The source can be either RADIUS or a local subnet or IP range definition.
Once the local tunnel endpoint ``set service pppoe-server local-ip '10.1.1.2'`` has been defined, the client IP pool can be either defined as a range or as subnet using CIDR notation.
If the CIDR notation is used, multiple subnets can be setup which are used sequentially.
-**Client IP address via IP range defintion**
+**Client IP address via IP range definition**
.. code-block:: sh
@@ -116,7 +116,7 @@ If attribute Filter-Id redefined, replace it in radius coa request
Automatic VLAN creation
=======================
-VLAN's can be created by accel-ppp on the fly if via the use of the kernel module vlan_mon, which is monitoring incoming vlans and creates the neccessary VLAN if required and allowed.
+VLAN's can be created by accel-ppp on the fly if via the use of the kernel module vlan_mon, which is monitoring incoming vlans and creates the necessary VLAN if required and allowed.
VyOS supports the use of either VLAN ID's or entire ranges, both values can be defined at the same time for an interface.
.. code-block:: sh
@@ -127,7 +127,7 @@ VyOS supports the use of either VLAN ID's or entire ranges, both values can be d
set service pppoe-server interface eth3 vlan-range 2000-3000
-The pppoe-server will now create these VLANs if required and once the user session has been cancelled, and the VLAN is not neccessary anymore, it will remove it again.
+The pppoe-server will now create these VLANs if required and once the user session has been cancelled, and the VLAN is not necessary anymore, it will remove it again.
diff --git a/docs/services/ssh.rst b/docs/services/ssh.rst
index 4d96f8de..caa255ce 100644
--- a/docs/services/ssh.rst
+++ b/docs/services/ssh.rst
@@ -44,13 +44,13 @@ Options
* Allow ``root`` login, this can be set to allow ``root`` logins on SSH
connections, however it is not advisable to use this setting as this bears
- serious security risks. The default system user posesses all required
+ serious security risks. The default system user possesses all required
privileges.
:code:`set service ssh allow-root`
* Allowed ciphers - A number of allowed ciphers can be specified, use multiple
- occurances to allow multiple ciphers.
+ occurrences to allow multiple ciphers.
:code:`set service ssh ciphers <cipher>`
@@ -70,7 +70,7 @@ Options
* `cast128-cbc`
* Disable password authentication - If SSH key authentication is set up,
- password-based user authetication can be disabled. This hardens security!
+ password-based user authentication can be disabled. This hardens security!
:code:`set service ssh disable-password-authentication`
diff --git a/docs/services/sstp-server.rst b/docs/services/sstp-server.rst
index 8ee8ef45..6ddbce38 100644
--- a/docs/services/sstp-server.rst
+++ b/docs/services/sstp-server.rst
@@ -14,7 +14,7 @@ Configuration
The `Secure Socket Tunneling Protocol`_ (SSTP), provides ppp via a SSL/TLS channel.
Using publically signed certificates as well a by private PKI, is fully supported.
-All certficates should be stored on VyOS under ``/config/user-data/sstp``.
+All certificates should be stored on VyOS under ``/config/user-data/sstp``.
Self Signed CA and server certificates
diff --git a/docs/vpn/index.rst b/docs/vpn/index.rst
index 9bab2b0c..055a2d5c 100644
--- a/docs/vpn/index.rst
+++ b/docs/vpn/index.rst
@@ -5,7 +5,7 @@
VPN
===
-This chapter descriptes the available VPN services provided by VyOS.
+This chapter describes the available VPN services provided by VyOS.
.. toctree::
:hidden:
diff --git a/docs/vpn/openvpn.rst b/docs/vpn/openvpn.rst
index e252d016..7e468c7b 100644
--- a/docs/vpn/openvpn.rst
+++ b/docs/vpn/openvpn.rst
@@ -160,7 +160,7 @@ OpenVPN Server
Multi-client server is the most popular OpenVPN mode on routers. It always uses
x.509 authentication and therefore requires a PKI setup. This guide assumes you
have already setup a PKI and have a CA certificate, a server certificate and
-key, a certificate revokation list, a Diffie-Hellman key exchange parameters
+key, a certificate revocation list, a Diffie-Hellman key exchange parameters
file. You do not need client certificates and keys for the server setup.
In this example we will use the most complicated case: a setup where each
@@ -235,11 +235,11 @@ OpenLDAP
========
Enterprise installations usually ship a kind of directory service which is used
-to have a single password store for all employes. VyOS and OpenVPN support using
+to have a single password store for all employees. VyOS and OpenVPN support using
LDAP/AD as single user backend.
Authentication is done by using the ``openvpn-auth-ldap.so`` plugin which is
-shiped with every VyOS installation. A dedicated configuration file is required.
+shipped with every VyOS installation. A dedicated configuration file is required.
It is best practise to store it in ``/config`` to survive image updates
.. code-block:: sh
@@ -306,7 +306,7 @@ Despite the fact that AD is a superset of LDAP
</Group>
</Authorization>
-If you only wan't to check if the user account is enabled and can authenticate
+If you only want to check if the user account is enabled and can authenticate
(against the primary group) the following snipped is sufficient:
.. code-block:: sh
diff --git a/docs/vpn/site2site_ipsec.rst b/docs/vpn/site2site_ipsec.rst
index 41115f8c..ac410d52 100644
--- a/docs/vpn/site2site_ipsec.rst
+++ b/docs/vpn/site2site_ipsec.rst
@@ -41,7 +41,7 @@ Each site-to-site peer has the next options:
* ``cert-file`` - certificate file, which will be used for authenticating local router on remote peer;
- * ``crl-file`` - file with the Certificate Revocation List. Using to check if a certificate for the remote peer is valid or revocated;
+ * ``crl-file`` - file with the Certificate Revocation List. Using to check if a certificate for the remote peer is valid or revoked;
* ``key`` - a private key, which will be used for authenticating local router on remote peer:
diff --git a/docs/vpn/wireguard.rst b/docs/vpn/wireguard.rst
index a2f45913..bf14179c 100644
--- a/docs/vpn/wireguard.rst
+++ b/docs/vpn/wireguard.rst
@@ -42,7 +42,7 @@ Named keypairs can be used on a interface basis, if configured.
If multiple wireguard interfaces are being configured, each can have
their own keypairs.
-The commands below will generate 2 keypairs, which are not releated
+The commands below will generate 2 keypairs, which are not related
to each other.
.. code-block:: sh