In T5797#195193, @marekm wrote:

Hmmm... nothing before today in this task seems related to ddclient at all, isn't this task referenced by mistake?
BTW, does anyone know what happened that Debian un-released ddcilent 3.10.0-3 (reverted to 3.10.0-2.1)?

Hmmm... nothing before today in this task seems related to ddclient at all, isn't this task referenced by mistake?
BTW, does anyone know what happened that Debian un-released ddcilent 3.10.0-3 (reverted to 3.10.0-2.1)?

This was completed at the time of T5248.

@Viacheslav, Thank you for the hint. After further analysis, these are the findings from the tests done in the lab running 1.4.0 version on both sides with server/client setup.

@fernando Any idea for CLI?

The solution sketched above will be handled in subtask T6569; in this task we will revert to using only the local redundancy removal in order to provide per-script error reporting.

PR for current: https://github.com/vyos/vyos-cloud-init/pull/78

PR for 1.4: https://github.com/vyos/vyos-1x/pull/3806

In T6545#194997, @SrividyaA wrote:

@Viacheslav, For site-to-site or server/client mode, when used cipher option as none then also issue is noticed. When you commit, it gives this warning:

vyos@vyos# set int openvpn vtun1 encryption cipher none
[edit]
vyos@vyos# commit
Warning: "encryption none" was specified!
No encryption will be performed and data is transmitted in plain text over the network!

Logs:

Jul 10 14:51:39 openvpn-vtun1[12357]: Cipher NONE not supported

https://github.com/vyos/vyos-1x/pull/3805

@Viacheslav, For site-to-site or server/client mode, when used cipher option as none then also issue is noticed. When you commit, it gives this warning:

In T6563#194972, @Viacheslav wrote:

Any idea for CLI?

Any idea for CLI?

Since loopback and dummy are fundamentally different in Linux, trying to pretend they are not would be misleading rather than helpful. Unless anything changes in the kernel, we should keep things as is.

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

Recovering gracefully and logging an error is a simple fix, and will be committed in the interim while the larger issue is addressed: namely, when running under vyos-configd, a ConfigError in a called dependency script should elicit a commit error in the originating config session. Here, however, we confront again the constraints of operating under the legacy commit algorithm. To address the matter, we will implement a partial solution to T5731 so as to catch verification errors in the (first instance of) sequential processing of the priority queue and cache the data for final processing of the activation stages (generate/apply); errors in the latter stages, as less common, will be logged. The sketch provided summarizes a design that balances the needs of early and correct (verify stage) error reporting with removing redundancy overhead when running under configd.