@adestis Can you add an example of the expected configuration if use-lzo-compression is configured and not configured?
https://github.com/vyos/vyos-1x/blob/e270712f7ebd76e4e1be598766d999cef4f05e26/src/op_mode/generate_ovpn_client_file.py#L57
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 1 2024
Jun 30 2024
Jun 29 2024
I've submitted the PR at github: https://github.com/vyos/vyos-1x/pull/3743
There's no smoketest for this functionality, but I've build a qemu-live image and the commands seems to at least start running (instead of instantly crashing).
Would the project accept community contributions to Debianize more of the packages?
It is not clear what "no plans" really means - simply "no time for it right now, but community help is welcome" (understandable) or "we don't want it because ..." (please explain the reasons).
There are no plans to implement this
According to https://forum.vyos.io/t/building-rolling-apt-repo-with-deb-packages-from-source/14651/7 (I can't reply there - that thread is locked, and my account silenced) - "Jenkins build system is in process of deprecation."
This is news to me. Whatever the replacement will be, this feature request is not about deprecating Jenkins, but rather about Debianizing all of the source packages in the VyOS APT repo, in the same way some packages already are.
Search for *.dsc files in the current rolling-packages APT repo finds 21 of them, this is only a small part, it would be nice to see all packages there Debianized like this - this is what this feature request is about.
Then standard Debian tools can be used to rebuild *.deb packages from source packages. No need to search all of GitHub and assemble all parts.
Debian doesn't say "all source is in GitHub". Debian handles source packages as part of the standard packaging system. Debian is good. Please be like Debian. Thank you.
New PR that will allow targeting VRFs directly by name, to reach higher table IDs: https://github.com/vyos/vyos-1x/pull/3740
Jun 28 2024
Using native nft tooling does not seem to help, I will keep investigating - seems to be very little information online on the topic, mostly people having the same issue as me.
Note that all Jenkins setup is in vyos-build: https://github.com/vyos/vyos-build/tree/current/packages
True, it is the user's responsibility to comply, no disagreement on that.
But a fairly simple change would make user's compliance easier, and it would be a win-win for everyone - why not?
Users who spend less time navigating a minefield of legal issues, could spend more doing useful things for the project.
It's not Invalid by any means. At least in my humble opinion - if you disagree, that's fine but please provide reasoned counter-arguments.
This was not about .deb packages in Debian itself, but from the VyOS APT repo used for building the rolling images.
Wishlist priority previously triaged (just 2 weeks ago) was fine, it's not Invalid - or at least have some civil discussion if we disagree on some points.
Quoting the GPL below, of course it's not legally required for other licenses like BSD, but still a good thing for any open source project anyway.
PR merged:
https://github.com/vyos/vyos-1x/pull/3692
source code from Debian is available on Debian repos
All source code is located in GitHub
It's user's responsibility to comply with trademark and copyright requirements
Will investigate!
The correct pass options without "
set interfaces openvpn vtun20 encryption ncp-ciphers 'aes256' set interfaces openvpn vtun20 hash 'sha512' set interfaces openvpn vtun20 mode 'server' set interfaces openvpn vtun20 openvpn-option 'push keepalive 1 10' set interfaces openvpn vtun20 server subnet '10.10.2.0/24' set interfaces openvpn vtun20 server topology 'subnet' set interfaces openvpn vtun20 tls ca-certificate 'ca' set interfaces openvpn vtun20 tls certificate 'cert' set interfaces openvpn vtun20 tls dh-params 'dh'
This could be achieved with conntrack ignore
set system conntrack ignore ipv4 rule 10 destination address '100.64.0.0/28'
vyos-vm-images has been archived
Provide the set of commands to reproduce
Still bug, the original config in the top of the task
vyos@r4# run show conf com | match "nat " set nat source rule 100 destination port '5000-8000' set nat source rule 100 outbound-interface name 'eth0' set nat source rule 100 protocol 'tcp' set nat source rule 100 source address '10.0.0.0/24' set nat source rule 100 translation address 'masquerade' [edit] vyos@r4# [edit] vyos@r4# run show nat source rules Rule Source Destination Proto Out-Int Translation ------ ----------- ----------------------------- ------- --------- ------------- 100 10.0.0.0/24 0.0.0.0/0 IP eth0 masquerade sport any dport {'range': [5000, 8000]} [edit] vyos@r4# [edit] vyos@r4# [edit] vyos@r4# run show ver Version: VyOS 1.5-rolling-202406260020 Release train: current Release flavor: generic
We have ENV OCAML_VERSION 4.14.2 for both, @dmbaturin. Can we close it, or will you do an update to 5.0?
Not actual
vyos@r4:~$ show version all | match conntrack ii conntrack 1:1.4.7-1+b2 amd64 Program to modify the conntrack tables ii conntrackd 1:1.4.7-1+b2 amd64 Connection tracking daemon ii libnetfilter-conntrack3:amd64 1.0.9-1 amd64 Netfilter netlink-conntrack library vyos@r4:~$ vyos@r4:~$ show version Version: VyOS 1.5-rolling-202406260020 Release train: current Release flavor: generic
Try native nft commands for offload and check what it says.
# cat /tmp/offload.nft