I've create a PR which does the retry part. It retries 10 time every 0.5 seconds until it succeeds or it's out of retries.

Tested via:

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

This is what I did (forgot to write it here) with the difference that my sleep timer is 60s as my config has many lines.
Would be good to have this fixed properly.

I think I found the "problematic" commit.
https://github.com/vyos/vyos-1x/commit/41477cc85208507be55f8db4e412ad78eae764eb#diff-8e6f3b9122c8406707eb59334978290d083995acf7de0323111d4eed1656693dL311

The problem here seems to be that keepalived is started before the complete commit is finished. So conf.get_config_dict() fails to get the config.

With an older version:

vagrant@s1:~$ sudo bridge vlan
port              vlan-id
eth1              1000 PVID Egress Untagged
eth2              1001 PVID Egress Untagged
br0               1 PVID Egress Untagged
                  1000
                  1001
vagrant@s1:~$ show version

I guess it the task T4632

Can confirm.

Created PR for this https://github.com/vyos/vyos-build/pull/256

Hi, I've created https://github.com/vyos/vyos-1x/pull/1483 for this one.

@c-po @itspngu , as mentioned above, we have held off on implementing the fix, as there is a compelling argument to disallow whitespace in tag node names, just as it is disallowed in node names in general; making an exception in the case of tag node names invites problems going forward. On the other hand, thanks to the details that you provided, @itspngu, we can implement a workaround for the case of ssh-copy-id; I know of no other instance of the problem. If we do find a necessary use case of whitespace in tag node names in the future, the simple fix can then be implemented.

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

set nat66 destination rule 120 description 'foo'
set nat66 destination rule 120 destination port '4545'
set nat66 destination rule 120 inbound-interface 'eth0'
set nat66 destination rule 120 protocol 'tcp'
set nat66 destination rule 120 source address '2001:db8:2222::/64'
set nat66 destination rule 120 source port '8080'
set nat66 destination rule 120 translation address '2001:db8:1111::1'
set nat66 destination rule 120 translation port '5555'

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

@itspngu you might try tomorrows rolling release and upgrade again. The issue should be resolved - it also helps us to see of the fix works!

There is a bug with such implementation check for openconnect
It is not possible to create the second user in another commit (as port already bonded)

vyos@r14# run show conf com | match vpn
set vpn openconnect authentication local-users username foo password 'bar'
set vpn openconnect authentication mode local 'password'
set vpn openconnect listen-ports tcp '8443'
set vpn openconnect listen-ports udp '8443'
set vpn openconnect network-settings client-ip-settings subnet '100.64.0.0/24'
set vpn openconnect network-settings name-server '100.64.0.1'
set vpn openconnect ssl ca-certificate 'ca-ocserv'
set vpn openconnect ssl certificate 'srv-ocserv'
[edit]
vyos@r14# commit
No configuration changes to commit
[edit]
vyos@r14# sudo netstat -tulpn | grep 8443
tcp        0      0 0.0.0.0:8443            0.0.0.0:*               LISTEN      23880/ocserv-main   
tcp6       0      0 :::8443                 :::*                    LISTEN      23880/ocserv-main   
udp        0      0 0.0.0.0:8443            0.0.0.0:*                           23880/ocserv-main   
udp6       0      0 :::8443                 :::*                                23880/ocserv-main   
[edit]
vyos@r14# set vpn openconnect authentication local-users username foo2 password 'bar2'
[edit]
vyos@r14# commit
[ vpn openconnect ]
"tcp" port "8443" is used by another service

In T4628#129192, @jestabro wrote:

Note that a fix for 1.4 will address the user's issue, as he is updating to 1.4-rolling, so the migration will take place upon booting into 1.4.

It seems after this commit https://github.com/vyos/vyos-1x/commit/1b637f78b870f8ecc4971de5baf0a6fda54c40f7 for T4597
As the port already listens by ocserv itself, maybe we should revert it or change the logic to check that the port bind is not ocserv service

I can confirm this has been the reason I've had issues upgrading from 1.2.x to 1.3.x.
Removing this statement before attempting, I can now upgrade from 1.2 to 1.3 smoothly, no OOM errors or other problems.

This is on hold, pending discussion on whether whitespace should be allowed in tag node names in 1.4.

The show command worked:

Note that a fix for 1.4 will address the user's issue, as he is updating to 1.4-rolling, so the migration will take place upon booting into 1.4.

https://github.com/vyos/vyos1x-config/pull/11

I see the issue. Whitespace is fine in a tag node name as long as the name is quoted, however ConfigTree.to_string() does not re-quote the name, hence on the next migration script, parsing the config file will throw an error. I will investigate the proper solution.

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

PR for vyos 1.3 (equuleus) https://github.com/vyos/vyos-1x/pull/1479

Nothing helps

Successfully tested

There is an example of how we build ocserv for 1.3 https://github.com/vyos/vyos-build/commit/2e1eac5980720d060834540e717f4f8a1189b9b0

I was also suggested to try this -

I tried this command as suggested - no luck.

Try to add some capabilities, for example, CAP_CHOWN or CAP_DAC_OVERRIDE or something else

sudo nano /etc/systemd/system/vyos-telegraf.service.d/10-override.conf

https://github.com/vyos/vyos-1x/blob/1f880973e221b91ac843a27d2e4c0b3de1880b97/data/templates/monitoring/override.conf.j2#L6

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

set firewall name FOO rule 10 action 'drop'
set firewall name FOO rule 10 protocol 'tcp'
set firewall name FOO rule 10 tcp flags syn
set firewall name FOO rule 10 tcp mss '1-500'

Discussed in dev meeting today and the conclusion was to move this to 1.3.3.

I did my internal tests and can't reproduce it
20K entries applied in 0.20 sec

root@r14:/home/vyos# cat tmp.nft | wc -l
20029
root@r14:/home/vyos# 
root@r14:/home/vyos# sudo time nft -f tmp.nft
real	0m 0.20s
user	0m 0.13s
sys	0m 0.06s
root@r14:/home/vyos#

200K entries in 2 sec

root@r14:/home/vyos# cat tmp.nft | wc -l
200029
root@r14:/home/vyos# 
root@r14:/home/vyos# sudo nft flush ruleset
root@r14:/home/vyos# 
root@r14:/home/vyos# sudo time nft -f tmp.nft
real	0m 1.91s
user	0m 1.20s
sys	0m 0.70s
root@r14:/home/vyos#

The only way to start telegraf with ip vrf exec i found - is to comment out
#User=telegraf
in /etc/systemd/system/vyos-telegraf.service and
chown root:root /run/telegraf

Not supported at the moment, but we can look into adding it for both ipv4/v6 in 1.4

While I'm for changing to prefixed tables, I think the issue of tailscale and custom apps should fall under the accepted risk of running custom scripts outside of the config.

Any config available to test against?

I think that having the configuration stored exclusively in files outside the config file breaks portability as exporting system state through # show | commands won't produce an output sufficient for full state backup of a device.
If the configuration attributes were all in the CLI which then generated the relevant files in the FS, that would address the stateless backing filesystem concern by centralizing the device config as the source of truth.
@SquirePug - could you possibly provide a link to or the contents of the changes you made? Thanks

@m.korobeinikov Could you check it in 1.3