Put in PR for op commands:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 27 2020
Dec 26 2020
Dec 25 2020
- https://github.com/vyos/vyos-1x/pull/643 only missing part is squidguard. Smoketests are already live for the other parts.
- ddclient 3.9.1 with cloudflare api4 support not in Debian Buster
- udp-broadcast-relay -> there is no upstream Debian Package
- mdns-repeater -> There is no upstream Debian Package
After the testing with a standalone User-Data handler, this feature was ported to the main cloud-init package in https://github.com/vyos/vyos-cloud-init/pull/27.
Currently, supported only set and delete commands processing. They must be provided as a list in the vyos_config_commands option.
Hi there,
Dec 24 2020
vyatta-biosdevname:
https://github.com/vyos/vyatta-cfg-system/blob/ebbdfe44aa321a2de35ddccaa255d384a5fd99e4/scripts/vyatta_net_name#L96
Used for calculating initial interface order, to try getting a ordered list and not only the random init-order used by the kernel
Does it possible to cherry-pick to 1.3? Because in 1.3 rollings we have the same bug.
vyatta-webproxy: 80% done, @cpo grabbed it since I had no time to continue for a while and put it on hold. I removed obsolete options which implies the need of a migration script. Ldap, AD, IP and user/passwd auth works, I removed caches, squidguard, include domain filters (just a list) and so on, but I stopped it now since it's been taken away.
Kernel modules are pre-compiled and can be loaded.
Dec 23 2020
I got this when several times change boot with
set system image default-boot
1.2.6 => 1.3 => 1.2.6 => 1.3
I successfully update the image from 1.2.6-s1 to VyOS 1.3-rolling-202012231522
Thanks for the feedback and telling us about how to solve this issue.
Successfully tested on 1.3-rolling-202012230217
The main problem is that you use the same name for different group types.
@tjh How you want to integrate it with CLI or use it as a separate pkg?
Dec 22 2020
The issue turned out to be at the host level. By default SR-IOV VFs are not allowed to change their own mac addresses or send packets with a different mac address, and since this is required for LACP bonding the configuration would just fail.
@robertoberto Can you provide next commands?
show interfaces ethernet eth0 physical sudo ethtool -k eth0 | grep offload
Put in a PR to add LDP ordered control operation for LDP.
[email protected]# commit Both Wireguard port and address must be defined for peer "foo" if either one of them is set!
@primoz What are the benefits?
This breaks with common configuration patterns/naming in Wireguard. Nobody will know what you're talking about when you say address and port in this context. And the CLI helpers adds documentation that would lead you to believe you are listening for connections, see line 105 in nterface-definitions/interfaces-wireguard.xml.in.
dhcpcd is a pretty good alternative. Well maintained and popularly used by many. I used it in a plain Linux router project and it was good enough for my use cases.
PR for crux https://github.com/vyos/vyos-build/pull/138
It still would be nice though. ANy other good IPv6 DHCP clients out there?
Yeah also it looks like wide is hardcoded to support only type 1 DUID (LLT) anyway.... so probably it wasn't accidentally "forgotten" in 1.3 migration that someone probably has realized it wasn't viable to support it... Thanks :)
Undortunately it only worked in 50% of the cases properly. Also there is only one global duid file so you can not have multiple duids (one per each interface).
@vagardx thank you for this rant.
Sorry I am confused. I took a brief look at the code of dhcp6c and it appears manually modifying the dhcp6c_duid file should be able to keep the change persistent: https://github.com/jinmei/wide-dhcpv6/blob/24ee2a4f0009bc6ac9bd0b7b737aef93a4aa9905/common.c#L992. Did I miss anything? Thanks :)
Dec 21 2020
Accidentally deleted the comment. Is there plan to migrated to dhcpcd instead? dhcpcd has good ipv6 support and being actively maintained too. Thanks.