@darkdragon-001 It will be available in the next rolling release, can you test it?

PR for current https://github.com/vyos/vyos-1x/pull/974

Might be good to have a workaround in VyOS in the mean time

Thank's for opening an upstream bug

Fixed, 1.3-beta-202108151336

[email protected]# run show conf com | match openvpn
set interfaces openvpn vtun10 encryption cipher 'aes256'
set interfaces openvpn vtun10 hash 'sha512'
set interfaces openvpn vtun10 local-host '192.168.122.14'
set interfaces openvpn vtun10 local-port '1194'
set interfaces openvpn vtun10 mode 'server'
set interfaces openvpn vtun10 persistent-tunnel
set interfaces openvpn vtun10 protocol 'udp'
set interfaces openvpn vtun10 server client client1 ip '10.10.0.10'
set interfaces openvpn vtun10 server domain-name 'vyos.net'
set interfaces openvpn vtun10 server max-connections '250'
set interfaces openvpn vtun10 server name-server '172.16.254.30'
set interfaces openvpn vtun10 server subnet '10.10.0.0/24'
set interfaces openvpn vtun10 server topology 'subnet'
set interfaces openvpn vtun10 tls ca-cert-file '/config/auth/ca.crt'
set interfaces openvpn vtun10 tls cert-file '/config/auth/central.crt'
set interfaces openvpn vtun10 tls dh-file '/config/auth/dh.pem'
set interfaces openvpn vtun10 tls key-file '/config/auth/central.key'
set interfaces openvpn vtun10 tls tls-version-min '1.0'
set interfaces openvpn vtun10 use-lzo-compression
[edit]
[email protected]#
[email protected]# set interfaces openvpn vtun10 authentication username foo
[edit]
[email protected]# commit

I have just opened a GitHub issue for this at FRR as well: https://github.com/FRRouting/frr/issues/9405

Just checked, the behaviour for this bug is still the same.

more amount of generalisation as we would not only want to use it for DHCp but all kind of services

Well the commit you outlined alters file ins src/conf_mode - that directory is reserved for CLI configuration scripts.

I can confirm that this works fine on the latest 1.3 nightly.

Thanks, that makes sense. Do you think the current outstanding change could be merged in? It's not resulting in any incompatibilities (that I'm aware of), and while it doesn't fix the problem entirely on its own (doesn't include infrastructure work), it improves the code under test.

That is a noble idea. There are some build time tests available here: https://github.com/vyos/vyos-1x/tree/current/src/tests - maybe this helps

As far as I can tell (from README), smoke tests are meant more to be integration than unit tests:

that feels like you wan't to achieve the same goal as https://github.com/vyos/vyos-1x/blob/current/smoketest/scripts/cli/test_service_dhcp-server.py
I think the easiest way would be to just extend the smoketest with your tests that you find missing.

I managed to make the DHCP configuration testable, although the code has some hardcoded paths which I didn't want to mess with too much, so my addition may be suboptimal.

Merging this PR can fix this problem. Due to the complexity of the JSON parsing of NFT by the operation mode script, this task still needs to be tested, and the local test passes

@c-po It makes sense
Need to try.

Well test it tomorrow once it becomes available :)

They are all intermixed ;) - maybe I also missinterpreted the issue. Maybe you can retest the latest rolling which will be available by tomorrow? Image is currently build: https://ci.vyos.net/job/vyos-build/job/current/2195

https://github.com/vyos/vyos-build/pull/182

Nvm I just noticed that the task number was mentioned in a commit, I have a feeling this won't solve the issue as this is related to the router bgp 123 vrf something rather than vrf something statements.

Very cool this has apparently been fixed already, I was reading through the vyos-1x commints and didn't see anything that looked related. What was the implemented change for this?

https://github.com/vyos/vyos-1x/blob/595ab70a5d50ef1f9e166959affd96ea1ee8c8c8/data/templates/openvpn/server.conf.tmpl#L228

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

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

No, I am assuming it will be created when they have implemented a fix. In the meantime, I guess VyOS 1.4 could pin the package back to the previous 4.3.7-1pdns.buster version which is what we are doing locally for the moment. The developer on the pdns thread said that he hopes to have a fix out in a few days.

I don't see the repo for "bullseye"
http://repo.powerdns.com/

PR for current https://github.com/vyos/vyos-1x/pull/967

Fixed, thanks.

@Viacheslav we have other "objects" in VyOS which also require deletion first under certain circumstances.

It seems impossible to delete network and container and add a new one in one commit

Fixed by PR966

Duplicate of T3499

It appears things are in such a state where that network doesn't actually exist:

To add to this, it looks like I'm not going to be able to get rid of that without rebooting: