mirror of
https://github.com/vyos/vyos-documentation.git
synced 2025-12-16 10:32:02 +01:00
Fix typos in pages
This commit is contained in:
parent
076f0f139d
commit
cfcd0f040b
@ -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
|
the community. Since the source code is still public you can build your own
|
||||||
ISO using the process described here.
|
ISO using the process described here.
|
||||||
|
|
||||||
Installing Docker and it's prequisites
|
Installing Docker and it's prerequisites
|
||||||
|
|
||||||
.. code-block:: sh
|
.. code-block:: sh
|
||||||
|
|
||||||
|
|||||||
@ -3,7 +3,7 @@
|
|||||||
Clustering
|
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.
|
VyOS supports multicast clustering.
|
||||||
|
|
||||||
|
|||||||
@ -105,7 +105,7 @@ The working configuration is the configuration which is currently being modified
|
|||||||
|
|
||||||
Saved configuration
|
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
|
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.
|
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.
|
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
|
6 2015-03-25 00:16:47 by vyos via cli
|
||||||
7 2015-03-24 23:43:45 by root via boot-config-loader
|
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
|
.. code-block:: sh
|
||||||
|
|
||||||
|
|||||||
@ -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
|
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
|
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
|
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
|
single function, the rest of the code can be left untouched as long as the
|
||||||
internal representation remains compatible.
|
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
|
It should use non-disruptive reload whenever possible. It may execute disruptive
|
||||||
operations such as daemon process restart if a particular component does not
|
operations such as daemon process restart if a particular component does not
|
||||||
support non-disruptive reload, or when the expected service degradation is minimal
|
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
|
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
|
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
|
should make effort to determine if a configuration change can be done in a
|
||||||
|
|||||||
@ -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).
|
* Keep track of the progress (what we've already done in this branch and what we still need to do).
|
||||||
* Prepare release notes.
|
* 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.
|
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:
|
Once there is a `bugtracker`_ entry about it, you should reference in your commit message, as in:
|
||||||
|
|
||||||
|
|||||||
@ -5,8 +5,8 @@ VyOS CLI
|
|||||||
|
|
||||||
The bash completion in VyOS is defined in *templates*. Templates are text files
|
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
|
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
|
template files define command behaviour. Before VyOS 1.2.x this files were created
|
||||||
by hand. After a complex redesing process_ the new style template are in XML.
|
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
|
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_
|
in the vyos-1x_ module. This schema is a slightly modified schema from VyConf_
|
||||||
|
|||||||
@ -61,12 +61,12 @@ VRRP priority can be set with ``priority`` option:
|
|||||||
|
|
||||||
set high-availability vrrp group Foo priority 200
|
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
|
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:
|
By default VRRP uses preemption. You can disable it with the "no-preempt" option:
|
||||||
|
|
||||||
|
|||||||
@ -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
|
Non-subscribers can get the LTS release by building it from source. Just follow the instructions in
|
||||||
https://github.com/vyos/vyos-build
|
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
|
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.
|
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.
|
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.
|
So finally you can verify the authenticity of your image.
|
||||||
|
|
||||||
|
|||||||
@ -809,7 +809,7 @@ Available commands:
|
|||||||
|
|
||||||
:code:`set traffic-policy round-robin <policy name> default quantum <packets>`
|
: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>`
|
: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
|
round robin, shaper limits bandwidth allocation by traffic class whereas round
|
||||||
robin divides the total available bandwidth between classes.
|
robin divides the total available bandwidth between classes.
|
||||||
|
|
||||||
Avialable commands:
|
Available commands:
|
||||||
|
|
||||||
* Define a shaper policy:
|
* Define a shaper policy:
|
||||||
|
|
||||||
|
|||||||
@ -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
|
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.
|
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
|
.. code-block:: sh
|
||||||
|
|
||||||
|
|||||||
@ -5,7 +5,7 @@
|
|||||||
Services
|
Services
|
||||||
========
|
========
|
||||||
|
|
||||||
This chapter descriptes the available system/network services provided by VyOS.
|
This chapter describes the available system/network services provided by VyOS.
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
|
|||||||
@ -92,6 +92,6 @@ Exemple:
|
|||||||
Troubleshooting
|
Troubleshooting
|
||||||
^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
Use operationnal command ``show log lldp`` to display logs.
|
Use operational command ``show log lldp`` to display logs.
|
||||||
|
|
||||||
.. include:: references.rst
|
.. include:: references.rst
|
||||||
|
|||||||
@ -41,12 +41,12 @@ Connections can be locally checked via the command
|
|||||||
Client IP address pools
|
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.
|
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.
|
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
|
.. code-block:: sh
|
||||||
|
|
||||||
@ -116,7 +116,7 @@ If attribute Filter-Id redefined, replace it in radius coa request
|
|||||||
Automatic VLAN creation
|
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.
|
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
|
.. 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
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@ -44,13 +44,13 @@ Options
|
|||||||
|
|
||||||
* Allow ``root`` login, this can be set to allow ``root`` logins on SSH
|
* 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
|
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.
|
privileges.
|
||||||
|
|
||||||
:code:`set service ssh allow-root`
|
:code:`set service ssh allow-root`
|
||||||
|
|
||||||
* Allowed ciphers - A number of allowed ciphers can be specified, use multiple
|
* 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>`
|
:code:`set service ssh ciphers <cipher>`
|
||||||
|
|
||||||
@ -70,7 +70,7 @@ Options
|
|||||||
* `cast128-cbc`
|
* `cast128-cbc`
|
||||||
|
|
||||||
* Disable password authentication - If SSH key authentication is set up,
|
* 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`
|
:code:`set service ssh disable-password-authentication`
|
||||||
|
|
||||||
|
|||||||
@ -14,7 +14,7 @@ Configuration
|
|||||||
|
|
||||||
The `Secure Socket Tunneling Protocol`_ (SSTP), provides ppp via a SSL/TLS channel.
|
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.
|
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
|
Self Signed CA and server certificates
|
||||||
|
|||||||
@ -5,7 +5,7 @@
|
|||||||
VPN
|
VPN
|
||||||
===
|
===
|
||||||
|
|
||||||
This chapter descriptes the available VPN services provided by VyOS.
|
This chapter describes the available VPN services provided by VyOS.
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:hidden:
|
:hidden:
|
||||||
|
|||||||
@ -160,7 +160,7 @@ OpenVPN Server
|
|||||||
Multi-client server is the most popular OpenVPN mode on routers. It always uses
|
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
|
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
|
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.
|
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
|
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
|
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.
|
LDAP/AD as single user backend.
|
||||||
|
|
||||||
Authentication is done by using the ``openvpn-auth-ldap.so`` plugin which is
|
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
|
It is best practise to store it in ``/config`` to survive image updates
|
||||||
|
|
||||||
.. code-block:: sh
|
.. code-block:: sh
|
||||||
@ -306,7 +306,7 @@ Despite the fact that AD is a superset of LDAP
|
|||||||
</Group>
|
</Group>
|
||||||
</Authorization>
|
</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:
|
(against the primary group) the following snipped is sufficient:
|
||||||
|
|
||||||
.. code-block:: sh
|
.. code-block:: sh
|
||||||
|
|||||||
@ -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;
|
* ``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:
|
* ``key`` - a private key, which will be used for authenticating local router on remote peer:
|
||||||
|
|
||||||
|
|||||||
@ -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
|
If multiple wireguard interfaces are being configured, each can have
|
||||||
their own keypairs.
|
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.
|
to each other.
|
||||||
|
|
||||||
.. code-block:: sh
|
.. code-block:: sh
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user