In my case, the container is created and running using IPv4 only. The network it is in has a defined prefix for IPv4 and IPv6. Then, the only thing I try to do is add an IPv6 address to the container. The network it is connected to already has the IPv6 prefix defined. That is when it dies.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Dec 18 2023
The mentioned file that missing is located upstream in https://github.com/miniupnp/miniupnp/tree/miniupnpd_2_3_1/miniupnpd/netfilter_nft/scripts
and the upstream configuration options that we think are missing to match vyos chains is https://github.com/miniupnp/miniupnp/blob/miniupnpd_2_3_1/miniupnpd/miniupnpd.conf#L77
Could you point out some documentation/examples on which scripts are missing?
It seems it has never been tested since @jack9603301 implemented it in task T3420. It seems he also didn't test it.
Adding a new container with both addresses and networks in one commit works fine.
set container name alp01 image 'alpine' set container name alp01 network NET01 address '10.0.0.12' set container name alp01 network NET01 address '2001:db8::12' set container network NET01 prefix '10.0.0.0/24' set container network NET01 prefix '2001:db8::/64'
We don't use /usr/libexec/vyos/validate-value.py anymore
There should be a separates tasks if required.
There is nothing to do there, all checks for linter Jinja included to vyos-build.
Close it.
It was changed for 1.4/1.5 and won't be changed for 1.3 LTS (old backend)
If someone wants it for 1.3
set protocols bgp 65001 parameters default no-ipv4-unicast
We are using sshguard
set service ssh dynamic-protection
@thomas-mangin Do you have a PoC?
Comparing boot time for now 1.3 and 1.1.8 is not actual
There are 2 different systems :)
Also, some validators were rewritten on 1.2 to Python and for 1.3 to sh, OCAML and so on (python validators could be cause of the issue)
In my internal test VM loads ~40 sec tested in VyOS 1.3.5
We always can improve something, but lets find what we can improve in separate tasks.
@mb300sd could you re-check?
The main issue is synchronization between all routing daemons and zebra, especially with "policy".
So you are getting strange things like a policy configured for zebra but the same policy not exists/applied for other daemons.
It is impossible to integrate it the correct way.
Reopen for 1.5, 2.0 if required and if it will be possible in the future with correct syncing between all daemons.
We can't do more due to old backend on the 1.3
If there will be a specific options to improve it should be a separate task
Close it.
Refactored in 1.4/1.5
Let's avoid the firewall migrations for the stable branch.
It won't be implemented for 1.3
Configs weren't provided, so closed the task as invalid. Works with internal tetts.
Re-open it or add steps to reproduce.
Implemented in 1.4
Wontfix for 1.3 due to old backend.
/config/dhcp4.leases ownership seem to change when migrating to latest 1.5-rolling-202312171632
Forgot to ever reply to this - I just wanted it added as a standard debian package so that scripts that depend on it can have it available without needing to be installed seperately.
Think this can be closed - there's no such command in 1.3 is there?