There should also be migration scripts, as CLI will be changed.

Proposal:

set system config-management commit-archive uri "stor01z-cs.int.trae32566.org/cr01b-vyos"
set system config-management commit-archive scheme "sftp"
set system config-management commit-archive username "cr01b"
set system config-management commit-archive password "$T3$TP@$$W0^%"

We could improve it by breaking up configuration, having the user providing a URI, Protocol and optional username/password as separate values.
Then we can properly encode username/password. This would also give more flexibility how username/password are handled and passed on.

In both cases it is kind of an user error, the password would have to be properly url encoded if provided in one (@ should be %40 in an URI, a ! should be %21).

Migration needed for listen-address when upgrading from isc-dhcp to kea dhcp (1.4 to 1.5)

PR for 1.5: https://github.com/vyos/vyos-build/pull/579

PR https://github.com/vyos/vyos-1x/pull/3379

@Zen3515, any idea for regex?

Works as expected in VyOS 1.5-rolling-202404290019 and VyOS 1.4-stable-202404300309 and VyOS 1.3-stable-202404300508

vyos@r1-right:~$ cat /etc/resolv.conf 
### Autogenerated by VyOS ###
### Do not edit, your changes will get overwritten ###

In T6281#185394, @c-po wrote:

Please note that the Wireguard tunnel itself is sourced from the default VRF. Only the "inner side" of the tunnel runs in VRF wan.

There is no possibility to source the wireguard interface from

• Another VRf
• A discrete source IP
• A discrete source interface

This can only be handled by applying fwmark values and policy based routing - this is a WireGuard design thing.

Please note that the Wireguard tunnel itself is sourced from the default VRF. Only the "inner side" of the tunnel runs in VRF wan.

It would be useful for 1.4 as well, to be able to rebuild the LTS with local patches to some packages but otherwise unmodified, for example to make it easier to test bug fixes in a single package (such as accel-ppp https://vyos.dev/T4600 ) without much risk to introduce new bugs.

If this ever becomes a thing, support for directly connected routes (ie. PPPoE) would be great as well.

@yarokifor The current version is updated, add steps to reproduce (set of commands) or close the task

vyos@r4# run show ver all | match upnp
ii  miniupnpd-nftables                   2.3.1-1                          amd64        UPnP and NAT-PMP daemon for gateway routers - nftables backend
[edit]
vyos@r4#

Fixed in the commit https://github.com/vyos/vyos-1x/commit/b75e0ba0a297fd64307960f98f30c27a689deab7

It seems like if there's an option to use remote backup in the config, yet the keys get erased every time it's upgraded that would be a bug. However , I am new to dev on VYOS, so classify it as makes sense for the team and I'll hope it get implemented at some point. 👍

The bug means the feature is implemented but works with issues, but this functionality has never been implemented :)
I created a root task T6279, and several similar/related subtasks.

I disagree, being that there's a command and associated config entry to backup config to a remote ssh server. This config option requires key based authentication. It would seem that the backup function puts this in- scope as a bug. Everyone who uses the remote configuration backup to an external ssh box is affected.

It is not a bug but a feature request.
Only keys in /etc/ssh are copied. The keys in the home user directory were never copied.

PR for 1.5:
https://github.com/vyos/vyos-1x/pull/3372
Combined PRs for backport to 1.4 of T5839, T5660, T6276 pending.

@Viacheslav can you create root task maybe and we consolidate related tasks under it

@Viacheslav @c-po can you guys review this PR

PR: https://github.com/vyos/vyos-1x/pull/3371

This would be the key's themselves and known_hosts, stored in the non-root user folder. The prompt during upgrade seems to indicate it'll copy them over. However, whenever I upgrade, I have to manually perform ssh-keygen and ssh-copy-id again for my backup server to allow my config backup to work.

we talking about athorized_keys or known_hosts?

You are right - I wonder why it didn't work when I tested it back then. (Most likely I forgot to write "comment")

I explored implementing this feature, turns out it is already available.
Correct syntax for commit messages is commit comment "example message".

Probably related: https://vyos.dev/T5388

Tested as working in: VyOS 1.5-rolling-202404250020

PR: https://github.com/vyos/vyos-1x/pull/3369

PR https://github.com/vyos/vyos-1x/pull/3368

vyos@r4# compare 
[interfaces]
+ wireless wlan0 {
+     address "192.0.2.5/32"
+ }

PR: https://github.com/vyos/vyos-1x/pull/3367