In case of filtering on a VRF, would it be an idea to use the MAC address instead of the interface name in the rule?

This will be resolved by the PR in T4664.

PR: https://github.com/vyos/vyatta-cfg/pull/50

@c-po suggested the very good idea of using a migration script to remove whitespace in this case, however, upon closer inspection, we realized that this cannot work, as a result of the binding between Python and config_tree: namely, the translation uses a split_on_whitespace function which will lose access to tag node value names containing whitespace, so the name is not manipulable through standard migration techniques. One can replace split_on_whitespace with smarter translations, however, a global solution is preferable: following discussion, the suggestion is to add a check in the legacy cstore backend to reject node names containing whitespace; the future vyconf will have this check built-in. This is the approach we will investigate.

The same for VyOS 1.4-rolling-202208290458

vyos@r14# set interfaces ethernet eth0 offload gro
[edit]
vyos@r14# commit

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1504

This bug was in T4241, client couldn't connect to openconnect server and logs from the server site like:

Feb 16 19:46:03 r4 ocserv[2409]: main:192.168.122.1:44480 user disconnected (reason: unspecified, rx: 0, tx: 0)
Feb 16 19:46:03 r4 ocserv[2409]: main:192.168.122.1:44482 user disconnected (reason: unspecified, rx: 0, tx: 0)
^C

It was tested with self-signed certificates.

@syncer It is affected also and 1.3
It should be a warning if we delete an interface (IP address of Interface) that belongs to some service.

@Viacheslav - how does the bug around which you were working manifest itself? I just pulled the 1.1.6 sources and built from that repo using the same command as the Jenkinsfile. Happy to test for whatever condition was being fixed in the local build

In T4533#126598, @c-po wrote:

In T4533#126578, @Viacheslav wrote:

It is operator level, that shouldn’t have permission for configurations. Only basic diagnostics (op-mode)

Operator mode is no longer supported in VyOS 1.4

Even if so - we should still try to "support" it somehow for the upcoming future when there is a true secure op-mode again.

Could you please add a new Cmnd_Alias vor VRF to /etc/sudoers.d/vyos and allow it for the %operator group?

ip vrf exec requires the CAP_SYS_ADMIN capability which somehow is more or less equal to root.

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