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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 12 2024
Jul 11 2024
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
Jul 10 2024
@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?
Jul 9 2024
Any idea for CLI?
Jul 8 2024
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.
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.
Jul 7 2024
There are two possible places where encrypted DNS support might be desired in a standard setup where VyOS is hosting a local resolver/recursor:
Jul 6 2024
After spending more time handling VRFs within VyOS the answer from @Viacheslav is best
Jul 5 2024
In T6211#194799, @stephenmcmahon wrote:In T6211#189615, @Viacheslav wrote:Probably the best way will be moving the config to the vrf section (not implemented)
For example:set vrf name foo service dhcp-server shared-network-name eth1 option default-router '192.168.1.1' set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 lease '300' set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default start '192.168.1.10' set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default stop '192.168.1.100' set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 subnet-id '1'