| Age | Commit message (Collapse) | Author |
|---|
|
In order to reuse as much as possible before migrationg to get_config_dict()
and re-use Jinja2 snippets the name-server node must be moved one level up to
'set vpn sstp name-server'.
|
|
|
|
|
|
|
|
|
|
Both PPPoE and WWAN interfaces are dialer interfaces handled by ppp, but use
different CLI nodes for the same functionality. PPPoE has "connect-on-demand"
to initiate an "on-demand" dialing and WWAN uses "ondemand" for this purpose.
Rename WWAN "ondemand" node to "connect-on-demand".
|
|
In the past we had to provide the ethertype value used for the VLAN
protocol (0x88A8 -> 802.1ad or 0x8100 -> 802.1q).
This should be changed to a more user friendly CLI node (protocol over
ethertype) and 802.1ad over it's raw value 0x88A8. There is no need in
presenting RAW information from the ethernet header to the user. Also iproute2
calls it protocol which makes way more sense over the "raw" value.
|
|
|
|
The current CLI did not support multiple prefix-delegations per interface. Some
ISPs only send one /64 to a client per prefix-delegation request, but they
allow the customer to request multiple prefixes.
The 'dhcpv6-options prefix-delegation' node has been renamed and converted to a
tag node named 'dhcpv6-options pd'. The tag node specifies a PD request (>=0).
In the past the user needed to know what prefix will be assigned and required
to calculate the sla-len by himself. The 'sla-len' node was dropped and is now
calculated in the background from the 'dhcpv6-options pd 0 length' node.
It is no longer mandatory to supply the 'sla-id' node, if sla-id is not
specified it is 'guessed' by counting upwards.
Example configuration:
----------------------
ethernet eth1 {
address dhcpv6
dhcpv6-options {
pd 0 {
length 56
interface eth2 {
address 1
}
}
}
}
This will request a /56 assignment from the ISP and will delegate a /64 network
to interface eth2. VyOS will use the interface address ::1 on the delegate
interface (eth2) as its local address.
|
|
Migration files on the storage should be done one time by a migration script
instead of every time the configuration changes. Moving this to an older
migration script is fine as this is around for a long time and all rolling
releases are already up2date. It only affects updates from VyOS 1.2 series.
|
|
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.
|
|
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.
|
|
By implementation misstake we exited the migrationscript if no VXLAN interface
was found but this was wrong as the same loop is used on pseudo-ethernet
interfaces. The Migrator previously only worked on pseudo-ethernet when
also a VXLAN interface was present. This has been corrected.
|
|
T2486: DNS, vyos-hostsd fixes
|
|
When the 'powersave' option under 'system console' was defined but no actual
serial console device this cause the following error during migration:
Loading configuration from 'config.boot'
Traceback (most recent call last):
File "/opt/vyatta/etc/config-migrate/migrate/system/16-to-17", line 45, in <module>
for device in config.list_nodes(base + ['device']):
File "/usr/lib/python3/dist-packages/vyos/configtree.py", line 236, in list_nodes
raise ConfigTreeError("Path [{}] doesn't exist".format(path_str))
vyos.configtree.ConfigTreeError: Path [b'system console device'] doesn't exist
|
|
Boolean nodes have been removed b/c a boolean value makes less sense. The same
behavior can be achieved with the presence or absence of a node. Unfortunately
the 'autonomous-flag' node has been a negated one which did not migrate
it to 'no-autonomous-flag' if it was set to false previously.
|
|
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.
|
|
Support for Hayes modems has been long gone (1.2.x) and nobody cared. It was
removed in commit d582bbaf3 ("update console settings for systemd") of
vyatta-cfg-system.
So as there have been zero complaints - cleanup the CLI.
|
|
The current implementation only works once the system has been fully booted
up and the config nodes have been process. So there is no "early" kernel
debugging. It is started with priority 400 (after all network stuff) - thus it
has a questionable at all for Kernel debugging.
It would only make sense if the entire system is changed to supply the config
stuff to the Kernel commandline and then send it to a dedicated MAC address
target as network will be initialized late.
As there are zero Phabricator tasks available and we do not know any user using
this - the "feature" will be removed.
|
|
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.
|
|
|
|
Rename the CLI nodes for prefix delegation from "dhcpv6-options delegate
<interface>" to "dhcpv6-options prefix-delegation interface <interface>".
The change is required to add the possibility to request for specific prefix
sized via the CLI. That option was not possible with the old configuration
tree.
|
|
|
|
The subnet specific nodes sip-server-address & sip-server-name do the same for
the user - specify a SIP server. Only the backend is rendered in a different
way, as ISC DHCPv6 expects different options. There is absolutely no need for
the user to distinguish between both two nodes.
|
|
- delete log_file, log_level and user nodes
- rename hash_type to hash
- rename mine_interval to interval
|
|
|
|
|
|
... sometimes it seems to have been called dns-server or dns-servers :/ ...
lucky me!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Instead of having "dns-server server-1|server-2" nodes and the same for IPv6
all DNS nameservers are migrated to a common name-servers node.
|
|
Commit bbea850ea5f ("ifconfig: T2057: remove need for interface-types.json")
called the Interface() class with a wrong input variable, this caused the
following error:
Traceback (most recent call last):
File "/opt/vyatta/etc/config-migrate/migrate/dns-forwarding/1-to-2", line 64, in <module>
raise ValueError(f'Invalid interface name {intf}')
ValueError: Invalid interface name eth0 vif 202
|
|
Combining multiple options into a single CLI node is considered bad practice.
IPv6 prefixes consited of the prefix itself and a mask send to the client in
one node only.
The following CLI parts have been migrated from
client-ipv6-pool {
delegate-prefix fc00:0:1::/48,64
prefix 2001:db8::/64,64
}
to
client-ipv6-pool {
delegate fc00:0:1::/48 {
delegation-prefix 48
}
prefix 2001:db8::/48 {
mask 64
}
}
Thus regular validation steps from the VyOS CLI can be used when a prefix is
configured.
|
|
It makes less sense for the user to specify this behavior.
|
|
There is no reason to distinguish between WINS servers in terms of priority.
This is solely a task which can be done in the underlaying Python scripts.
|
|
There is no reason to distinguish between an IPv4 and IPv6 name-server node
on the CLI - this can be done in the underlaying Python scripts.
|
|
|
|
|
|
Restriction of api proxy should be owned by https.py, not http-api.py.
|
|
|
|
WireGuard has been the only subsystem combining a remote ip address and a
remote port number into a single node. This is bad as there is no possiblity
for the XML based input validation for IP address and port numbers.
That's the reason the peer endpoint node goets migrated into a peer address
and a peer port node utilizing the embedded syntax node checking for IP
addresses and port ranges.
|
