| Age | Commit message (Collapse) | Author |
|---|
|
Please note that either interface or address can be configured.
system {
options {
http-client {
source-interface eth0
source-address 1.1.1.1
}
}
}
|
|
|
|
|
|
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.
|
|
Match the full input string in regex validation. Previosly "sha123456" was
allowed by the validator but we only support "sha".
|
|
When migrating the conf from VyOS 1.2 to 1.3 a configuration error could appear
if the user specified "info" as loglevel instead of "INFO". There was no input
validation done in 1.2 but this is now enforced in 1.3.
In VyOS 1.3 loglevel will be always lowercase on the CLI and when migrating the
config this is transformed. Also VyOS 1.2 accpeted any arbitrary loglevel. If
an invalid loglevel is found it will be set to info.
|
|
ids: T2659: Add priority after bgp for correct service starting
|
|
|
|
VRFs should be created as early as possible.
|
|
ids: T2659: Implement fastnetmon support
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jinja template contains some workarounds like {% if port is string %}, this
depends of the resolution of https://phabricator.vyos.net/T2636
|
|
tunnel: T2633: add support for ip (arp) commands
|
|
|
|
SSH mac, ciper and key exchange algorithms are not ynamically and only change
on distro upgrades. Thus it is easier to have them in a list and use a regex
based constraint. In the past users could have entered anything here!
|
|
|
|
* 'default-dict' of github.com:c-po/vyos-1x:
console-server: T2588: migrate to defaults from XML interface definitions
xml: T2588: add gitignore for generated defaults
xml: T2588: code to extract defaults values from xml
Debian: remove duplicate build dependency
xml: ssh: fix typo in service description
|
|
|
|
|
|
|
|
|
|
T2486: DNS, vyos-hostsd fixes
|
|
... to ensure the service is started very late.
|
|
|
|
|
|
A user can define a port under the SSH node per device. WHen connecting to that
port and authenticating using regular credentials we will immediately drop to
the serial console. This is the same as executing "connect serial-proxy <name>".
|
|
For more examples on the new get_config_dict() approach migrate this
implementation as it is not yet in production use. Also this serves as proof of
concept code for further migrations.
|
|
|
|
|
|
|
|
Using "ls" is much faster compared to "find ... -exec basename"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add new nodes for 'service dns forwarding domain':
'addnta': adds addNTA to lua-config-file
'recursion-desired': sets '+' before the zone in forward-zones-file
The migrator sets both options for all configured domains. This is
usually the desired config.
|
|
The previous implementation only supported disabling DHCP nameservers for
all interfaces, and was implemented improperly so it didn't work anyway.
This migrates it to name-servers-dhcp <interface>, which allows us to enable
just the interfaces we want to use for system DNS, identical in syntax to
'service dns forwarding dhcp <interface>'.
The migrator searches through all interfaces that have address 'dhcp(v6)?'
and adds them to the name-servers-dhcp list if disable-dhcp-nameservers is
not set, else it does nothing.
|
|
|
|
During testing it was discovered that there is a well known problem (we had for
ethernet interfaces) also in the serial port world. They will be enumerated and
mapped to /dev/ttyUSBxxx differently from boot to boot. This is especially
painful on my development APU4 board which also has a Sierra Wireless MC7710
LTE module installed.
The serial port will toggle between ttyUSB2 and ttyUSB5 depending on the
amount of serial port extenders attached (FT4232H).
The shipped udev rule (/usr/lib/udev/rules.d/60-serial.rules) partly solves
this by enumerating the devices into /dev/serial/by-id folder with their name
and serial number - it's a very good idea but I've found that not all of the
FT4232H dongles have a serial number programmed - this leads to the situation
that when you plug in two cables with both having serial number 0 - only one
device symlink will appear - the previous one is always overwritten by the
latter one.
Derive /usr/lib/udev/rules.d/60-serial.rules and create a /dev/serial/by-bus
directory and group devices by attached USB root port.
|
|
Migrate the serial console subsystem to XML and Python.
|
|
|
|
Commit 1c7d7cbd39 ("wwan: T2529: migrate device from ttyUSB to usbXbY.YpZ.Z")
added a new completion helper path for USB based serial interfaces. If no USB
based serial port was available on the system this produced the following
error: "ls: cannot access '/dev/serial/by-bus': No such file or directory"
Only list USB based serial interfaces if there is at least one connected to
the system.
|
|
During testing it was discovered that there is a well known problem (we had for
ethernet interfaces) also in the serial port world. They will be enumerated and
mapped to /dev/ttyUSBxxx differently from boot to boot. This is especially
painful on my development APU4 board which also has a Sierra Wireless MC7710
LTE module installed.
The serial port will toggle between ttyUSB2 and ttyUSB5 depending on the
amount of serial port extenders attached (FT4232H).
The shipped udev rule (/usr/lib/udev/rules.d/60-serial.rules) partly solves
this by enumerating the devices into /dev/serial/by-id folder with their name
and serial number - it's a very good idea but I've found that not all of the
FT4232H dongles have a serial number programmed - this leads to the situation
that when you plug in two cables with both having serial number 0 - only one
device symlink will appear - the previous one is always overwritten by the
latter one.
Derive /usr/lib/udev/rules.d/60-serial.rules and create a /dev/serial/by-bus
directory and group devices by attached USB root port.
vyos@vyos:~$ find /dev/serial/by-bus/ -name usb* -exec basename {} \; | sort
usb0b1.3p1.0
usb0b1.3p1.2
usb0b1.3p1.3
usb0b2.4p1.0
usb0b2.4p1.1
usb0b2.4p1.2
usb0b2.4p1.3
So we have USB root 0 with bus 1.3 and port 1.0. The enumeration is constant
accross reboots.
|
