| Age | Commit message (Collapse) | Author |
|---|
|
definition
|
|
|
|
Re-organize the template code and add addtitional Jinja2 filters for processing
the ifconfig-pool statement. This reverts the changes from commit 7e546be9
("openvpn: T2994: temporary revert to 1.2 crux behavior for client pools").
|
|
Test additional network combinations of address and prefixes.
|
|
Remove workaround which split (local|remote)_address and also subnet keys into
individual keys for the assigned IP address family (4/6).
During template rendering check IP version by introducing new ipv4 and ipv6
Jinja2 filters {% if foo | ipv4 %} or {% if bar | ipv6 %} options.
|
|
After renaming the function in commit 25551c5a ("vyos.util: T2995: rename
vyos_dict_search() -> dict_search()"), the test case should be renamed, too.
|
|
|
|
|
|
|
|
|
|
|
|
Renamed using snippet below:
----------------------------
for file in $(find . -name "*.py")
do
sed -i "s/vyos_dict_search/dict_search/" $file
done
|
|
|
|
bgp: T2387: Fix XML sheme for new bgp and bgp.py handler
|
|
accel: T2631: Add option for radius disable-accounting
|
|
|
|
|
|
|
|
|
|
This reverts commit 9939139ba4ad18dc4b62a827d8ab7b74d0c28124.
Unfortunately this test does not work within the CI system. It fails with:
17:21:35 ======================================================================
17:21:35 FAIL: test_process_named_running (test_util.TestVyOSUtil)
17:21:35 ----------------------------------------------------------------------
17:21:35 Traceback (most recent call last):
17:21:35 File "/var/lib/jenkins/jenkins_slave/workspace/vyos-1x_current/build/src/tests/test_util.py", line 34, in test_process_named_running
17:21:35 self.assertTrue(isinstance(pid, int))
17:21:35 AssertionError: False is not true
As process_named_running() returns None on non existing bash process
|
|
The CLI node was read in incorrect (wrong path). In addtition the list was not
reset to [] when authentication was specified on the CLI.
|
|
|
|
|
|
|
|
|
|
The current wversion unfortunately will raise a KeyError:
>>> data = {}
>>> vyos_dict_search('foo', data)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3/dist-packages/vyos/util.py", line 685, in vyos_dict_search
return dict[path]
KeyError: 'foo'
|
|
|
|
|
|
A lot of VyOS code requires the Kernel interface to be present in order to
properly work and adjust the interface to the users CLI intends (alias, ipv6,
vrf - just to name a few).
OpenVPN - when run in client mode - only creates the interface (e.g. vtun1) when
the connection to the OpenVPN server was successful. This can't be always the
case due to e.g. software-updates or routing issues to the remote side. This
will in the end result in a zombie OpenVPN client interface where some config
items might not have been set when the interface finally comes up - imagine a
wrong assigned VRF instance.
By always creating the OpenVPN interface manuall we ensure that all the CLI
settings are properly configured in the OS kernel.
|
|
Check that interfaces have been returned from lldpcli to prevent trace when
no interfaces are enabled for lldp.
|
|
op-mode: lldp: T2993: Fix 'show lldp neighbors'
|
|
'show lldp neighbors' fails with:
Traceback (most recent call last):
File "./lldp_op.py", line 122, in <module>
config_text = tmpl.render(parse_data(neighbors))
File "./lldp_op.py", line 51, in parse_data
for local_if, values in tmp.items():
AttributeError: 'str' object has no attribute 'items'
`parse_data` was expecting data to be provided as a dict within an array
which doesn't match the format from the parsed json output of lldpcli.
Change `parse_data` and `main` to use a dict alone for passing interface
neighbors for rendering.
|
|
The current implementation for bridge based interfaces has an issue which is
caused by priority inheritance. We always assumed that the bridge interface will
be created last, but this may not be true in all cases, where some interfaces
will be created "on demand" - e.g. OpenVPN or late (VXLAN, GENEVE).
As we already have a bunch of verify steps in place we should not see a bridge
interface leak to the underlaying infrastructure code. This means, whenever an
interface will be member of a bridge, and the bridge does yet not exist, we will
create it in advance in the interface context, as the bridge code will be run
in the same commit but maybe sooner or later.
This will also be the solution for T2924.
|
|
|
|
|
|
|
|
|
|
|
|
The mandatory colon for separating the IPv6 address and port was missing.
|
|
|
|
|
|
|
|
pdns_recursor: T2964: Expose query-local-address to dns config.
|
|
In certain split DNS configurations, there is a need for more
fine-grained control over the local address DNS forwarding uses to
issue queries. The current pdns_recursor configuration allows the
recursor to send queries from any available address on the interface
the OS selects for the query, with no option to limit queries to a
particular address or set of addresses.
This commit exposes the `query-local-address` option in
`recursor.conf` to users via the `service` `dns` `forwarding`
`source-address` config node.
If the parameter is unspecified, the default value of 0.0.0.0 (any
IPv4 address) and :: (any IPv6 address) are used to match current
behavior.
Users who want more control can specify one or more IPv4 and IPv6
addresses to issue queries from. Per pdns_recursor docs, the recursor
will load balance queries between any available addresses in the
pools. Since IPv4 and IPv6 are different pools, note that specifying
only one type of address will disable issuing queries for the other
address family.
|
|
|
|
Required to not trigger the "Misssing WPA key or RADIUS server" exception due
to the new default value added in commit 2a0428bf ("wireless: T2963: set default
'both' on 'security wpa mode'").
|
|
dhcpv6: T2961: support stateless dhcpv6 clients
|
|
This commit adds support for configuring the DHCPv6 server to serve
"stateless" DHCPv6 clients (those that send an information-request
message and do not request an address).
The change introduces a `common-options` node at the
`shared-network-name` level, which allows specifying options
applicable to clients regardless of subnet assigned (or in the case of
stateless clients, when no subnet is assigned). Parameters specified
at the subnet level take precedence over those set at the
shared-network level.
Presently, only parameters that are meaningful to stateless clients
have been exposed under `common-options`, as there is no precedent of
exposing parameters at multiple levels under the current DHCPv4 or
DHCPv6 configuration syntax. If desired, additional parameters could
certainly be added with relative ease.
|
|
|
|
|
