| Age | Commit message (Collapse) | Author |
|---|
|
This is a minor modification of the implementation by Thomas Mangin.
|
|
|
|
The 3rd party library used for calculating the SNMP hashes in advance only
worked for SHA and nod for MD5 as SHA was hardcoded [1]. The code has been
replaced by a class-less implementation providing only the required
functionality.
[1]: https://github.com/TheMysteriousX/SNMPv3-Hash-Generator/issues/2
|
|
|
|
As of now when adding new credentials for any SNMPv3 user we submit the
credential either plaintext or encrypted. A plaintext credential will be hashed
by SNMPd in the background and then passed back into the CLI so it's not stored
in cleartext. This feels like the wrong way in changing the CLI content with
data produced by a 3rd party daemon which implements the service.
It feels like the tail wiggles the entire dog.
This should be changed in the following way:
- After retrieving the plaintext password from CLI, use Python to hash the key
in advance
- Re-populate the encrypted key into the CLI and drop the plaintext one
- Generate service configuration and continue startup of SNMPd
This also fixes a race condition when SNMPd started up but not properly
provided the hasehd keys in the configuration resulting in a ConfigurationError.
Now as we also support binding SNMPd to a VRF this fixes a deadlock situation
on bootup as we can only bind late to the VRF and require up to 5 restarts of
the service - but the service will never start.
|
|
The current use of () does not allow to use found()
Converting to [] like all other tags
|
|
|
|
|
|
|
|
NTP configuration file requires the IP address and a netmask for client
subnets but the CLI will only provide a prefix based ntoation. Use custom,
reusable JInja2 template to transform a CIDR based prefix into its address
and netmask portion for IPv4 and IPv6.
Jinja2 custom filters are regular python functions - thus they can be re-used
directly when e.g. verifying the configuration in vyos-smoketests.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
T2638: FRR: New framework for configuring FRR
|
|
This commit adds the python module vyos.frr that support reading and modifying the frr cofiguration.
Functions
get_configuration() :
Collects the configuration from FRR and returns it as a string
reload_configuration() :
uses frr-reload.py to activate a new configuration.
The configuration applied will overwrite the current configuration.
mark_configuration() :
Does syntax check/validation and add "end" tags to the configuration
The marked configuration will be returned as a string
A syntax fault will render an Exception
execute() :
Execute a command inside vtysh
configure() :
Executes a command in vtysh config mode
replace_section() / _replace_section() :
Adds the ability to replace a section of frr code
remove_section() :
Removes the specified configuration block from the config
For now this supports replacing complete config sub-blocks of configuration and selecting the daemon
to replace inside. This should work for most daemons, but static routing will still be an issue because
this is not a separate sub-config mode
|
|
|
|
|
|
* 'T2656' of https://github.com/thomas-mangin/vyos-1x:
xml: T2656: option to not flatten the default dict
|
|
|
|
|
|
|
|
While moving towards a general interface abstraction based on get_config_dict()
and the use of vyos.ifconfig.Interfaces().update() it also makes sense, to
split out common verification code to a common util file - instead of
duplicating the code, which is infact one of the main forces drivind this
transition.
vyos.configverify will hold common functions called via verify() from our
src/conf_mode scripts so we do not need to copy/paste general verifications
methods.
|
|
|
|
This changes the dummy interface implementation to make use of get_config_dict()
and also implement a new vyos.ifconfig.Interface().update() function to gather
all the scattered calls to update common interface configuration options.
Derived classes of Interface() should extend update() to their needs for their
special interface type - e.g. bond or bridge.
|
|
|
|
|
|
|
|
|
|
Commit 289f513 ("wireguard: T2632: support PSK on multiple peers") introduced
a regression when multiple allowed-ips have been configured. They were not
properly quoted when passing them down to the wg binary.
|
|
dictconfig: T2637: identify sub-interfaces (vif) to delete
|
|
|
|
Commit 9390988709 ("vxlan: T2629: fix multiple configuration issues") called
append() on a list and passed two arguments which is invalid.
Traceback (most recent call last):
File "/usr/libexec/vyos/conf_mode/interfaces-vxlan.py", line 300, in <module>
apply(c)
File "/usr/libexec/vyos/conf_mode/interfaces-vxlan.py", line 245, in apply
v = VXLANIf(vxlan['intf'], **conf)
File "/usr/lib/python3/dist-packages/vyos/ifconfig/interface.py", line 221, in __init__
self._create()
File "/usr/lib/python3/dist-packages/vyos/ifconfig/vxlan.py", line 84, in _create
cmdline.append('group', 'src_interface')
TypeError: append() takes exactly one argument (2 given)
|
|
validation: T2630: bound to interface mtu if available
|
|
|
|
vxlan: T2629: fix multiple configuration issues
|
|
It was not possible to configure two WG peers with both utilized a pre-shared
key. This has been corrected.
WG psk can only be read from a file when starting the interface. The code for
creating this temporary file has been moved into the ifconfig.WireGuardIf()
class.
Tested with:
============
set interfaces wireguard wg0 address '192.0.2.0/31'
set interfaces wireguard wg0 peer one allowed-ips '0.0.0.0/0'
set interfaces wireguard wg0 peer one preshared-key 'e+SIIUcrnrSDHhbTtpjwKhSlSdUALA5ZvoCjfQXcvmA='
set interfaces wireguard wg0 peer one pubkey '/qQGAQ2HfLSZBSCpdgps04r9wRlK7bSFraCH9+MScmw='
set interfaces wireguard wg0 peer two allowed-ips '0.0.0.0/0'
set interfaces wireguard wg0 peer two pubkey '/qQGAQ2HfLSZBSCpdgfooor9wRlK7bSFraCH9+MScmw='
|
|
|
|
|
|
|
|
default-doct
* 'T2588' of https://github.com/thomas-mangin/vyos-1x:
xml: T2588: code to extract defaults values from xml
|
|
|
|
|
|
T2486: DNS, vyos-hostsd fixes
|
|
|
|
|
