| Age | Commit message (Collapse) | Author |
|---|
|
message
|
|
We have "set system name-server <ipv4|ipv6>" to specify a name-server IP
address we wan't to use. We also have "set system name-servers-dhcp <interface>"
which does the same, but the name-server in question is retrieved via DHCP.
Both CLI nodes are combined under "set system name-server <ipv4|ipv6|interface>"
to keep things as they are in real life - we need a name-server.
(cherry picked from commit 2ecf7a9f9cbe9359457bd23b4a0c45f3763123c7)
|
|
VyOS 1.3 equuleus now uses version 21 so we have to bump this by one.
|
|
|
|
Commit 27e53fbc ("op-mode: T3619: bugfix "show interfaces" for VLANs") fixed
the op-mode command for the "show interfaces" operation, but if a user was
interested in all the ethernet or bridge interfaces, the command "show
interfaces <type> detail" did not yield any output.
The filtered_interfaces() function was further generalized to only operate on
base components and call itself recusively if required.
|
|
Commit 31169fa8a7 ("vyos.ifconfig: T3619: only set offloading options if
supported by NIC") always instantiated an object of the Ethtool class for an
ethernet object - this is right as a real ethernet interface is managed by
Ethtool.
Unfortunately the script used for "show interface" determindes the "base class"
for an interface by its name, so eth0 -> Ethernet, eth0.10 -> Ethernet. This
assumption is incorrect as a VLAN interface can not have the physical parameters
changed of its underlaying interface. This can only be done for eth0.
There is no need for the op-mode script to determine the implementation class
for an interface at this level, as we are only interested in the state of the
interface and it's IP addresses - which is a common operation valid for every
interface on VyOS.
|
|
|
|
Commit 5f1c1ae4 ("bgp: T3798: add support for neighbor local-as <n> replace-as")
added support for a new CLI option when the local-as is changed for a specified
neighbor or peer-group.
There was an error in the CLI / design as the "replace-as" option can only be
used when "no-prepend" is defined. Thus "no-prepend" became a <node> and
the new "replace-as" leafNode is now a child of "no-prepend".
|
|
This patch allows the use of `"` in ssh public-key options which
unlocks the ability to set the `from` option in a way that sshd will
accept to limit what hosts a user can connect from.
|
|
|
|
Keys are not allowed with ipip and sit tunnels
|
|
While migrating to get_config_dict() in commit e8a1c291b1 ("login: radius:
T3192: migrate to get_config_dict()") the user-name was not excluded
from mangling (no_tag_node_value_mangle=True).
This resulted in a username "vyos-user" from CLI to be actually created as
"vyos_user" on the system.
This commit also adds respective Smoketests to prevent this in the future.
|
|
The workaround is no longer required, as the issue was resolved in
get_config_dict() so if it is a <multi/> node, a list is always returned.
|
|
Commit 9f20bee81c ("T1376: improve show_dhcp and show_dhcpv6") added the tab
completion helper to list the availbale IP pools to query. This was done by
calling a python script which then called cli-shell-api which resulted in a
penalty by the Python interpreter startup.
This can be solved by directly using the cli-shell-api wrapper available
as <path> in op-mode - as also seen for DHCPv6.
|
|
tunnel: T2920: Add checks tun with same source addr and keys
|
|
2 tunnels with the same local-address should has different keys
Check existing tunnels (source-address key) with new tunnel.
|
|
It makes no sense to have a parser for the ethtool values in ethtool.py
and ethernet.py - one instance ios more then enough!
|
|
Only update the RX/TX ring-buffer settings if they are different from the ones
currently programmed to the hardware. There is no need to write the same value
to the hardware again - this could cause traffic disruption on some NICs.
|
|
Not all interface drivers have the ability to change the speed and duplex
settings. Known drivers with this limitation are vmxnet3, virtio_net and
xen_netfront. If this driver is detected, an error will be presented to the
user.
|
|
SSH keys used for remote login are supplied as base64 encoded data on the CLI.
The key is not validated, thus an invalid copy/pasted key will render the login
useless. This commit adds a custom and re-usable validator which check if the
data is properly base64 encoded.
|
|
Ethernet adapters have a discrete set of available speed and duplex settings.
Instead of passing every value down to ethtool and let it decide, we can do
this early in the VyOS verify() function for ethernet interfaces.
|
|
tunnel: T3786: Add checks for source any and not key
|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
(cherry picked from commit f5e46ee6cc2b6c1c1869e26beca4ccd5bf52b62f)
|
|
An analysis of the code base from VyOS 1.2 -> 1.3 -> 1.4 revealed the following
"root-cause"
VyOS 1.2 uses the "old" node.def file format for:
* Generic Segmentation Offloading
* Generic Receive Offloading
So if any of the above settings is available on the configuration CLI, the
node.def file will be executed - this is how it works.
By default, this CLI option is not enabled in VyOS 1.2 - but the Linux Kernel
enables offloading "under the hood" by default for GRO, GSO... which will boost
the performance for users magically.
With the rewrite in VyOS 1.3 of all the interface related code T1579, and
especially T1637 this was moved to a new approach. There is now only one handler
script which is called whenever a user changes something under the interfaces
ethernet tree. The Full CLI configuration is assembled by get_interface_dict() -
a wrapper for get_config_dict() which abstracts and works for all of our
interface types - single source design.
The problem now comes into play when the gathered configuration is actually
written to the hardware, as there is no GSO, GRO or foo-offloading setting
defined - we behave as instructed and disable the offloading.
So the real bug originates from VyOS 1.2 and the old Vyatta codebase, but the
recent XML Python rewrites brought that one up to light.
Solution:
A configuration migration script will be provided starting with VyOS 1.3 which
will read in the CLI configuration of the ethernet interfaces and if not
enabled, will query the adapter if offloading is supported at all, and if so,
will enable the CLI nodes.
One might say that this will "blow" the CLI configuration but it only represents
the truth - which was masked in VyOS 1.2.
(cherry picked from commit a515212f4efb08846df04405f31a828edcd63552)
|
|
VyOS 1.4 already had a migrator for interfaces 20 -> 21, but this is a different
one compared to the one in VyOS 1.3 - thus we bump every migration scripts
version by one to have the same 20-to-21 converter in both VyOS 1.3 and 1.4.
This is possible as VyOS 1.4 (sagitta) is still a highly experimental version
and expected to break from time to time :(.
|
|
|
|
Check a port availability only if it was changed in current commit.
This should protect from fail-positive errors when other parameters
change for an interface.
|
|
The commit fixes the problem, when port availability check is
triggered even if a port for WireGuard interface is not defined
(randomized port, default behavior).
|
|
|
|
Add new CLI command:
* "set protocols ospf redistribute table <n>"
|
|
Mandatory FRR options for spf-delay-ietf did not get rendered in the Jinja2
template.
|
|
wireguard: T3763: Added check for listening port availability
|
|
`print` was removed or replaced to `ValueError`, where possible.
|
|
Extended CLI command: "set vpn ipsec remote-access connection rw pool" with a
"radius" option.
|
|
(cherry picked from commit b4b2c91127289c7b62afb24304054d57357a48c5)
|
|
Each wireguard interface requires a unique port for in and out
connections. This commit adds the new `vyos.util` function -
`check_port_availability`, and uses it to be sure that a port
that is planned to be used for wireguard interface is truly
available and not used by any other services (not only other
wireguard interfaces).
|
|
|
|
T3773: delete the original "show system integrity" command
|
|
|
|
|
|
The "l2vpn evpn" address-family route-target command only accepts a single
route-target value consisting of (A.B.C.D:MN|EF:OPQR|GHJK:MN). The
"ipv4-unicast or ipv6-unicast" address-family route-target command for VPNs
support multiple, whitespace separated route-target values.
This commit adds a new custom validator named "bgp-route-target" with a --single
and a --multi option to pass one or more route-target values.
|
|
|
|
... as we will get another bgp route-target validator soon.
|
|
After commit 209ce3d9 ("container: T3769: when container networks are used,
always bridge the networks") IP masquerading (NAT) was disabled. No need to
keep the haipin flag.
|
|
As VyOS is a network operation system with bridging and NATing available from
the VyOS CLI, it makes no sense to let podman do it's own sort of "NAT".
If one really want's to NAT into a container, use the VyOS CLI to do so. If you
wan't to bridge your networks, use the VyOS CLI to do so.
|
|
|
|
Volumes must have both a source and destination path specified. Also the
source path must exist on the current system.
|
|
A call to .items() was missing that triggered the following error:
ValueError: too many values to unpack (expected 2)
|
|
As VyOS CLI is the only truth for dealing with containers we do not need to
query if a container is running, exists or what so ever. We simply always
restart it if something changes and do not rely on the underlaying Linux
status.
If a users does container stuff under the hood - it will be overridden.
|
|
|
