-
Notifications
You must be signed in to change notification settings - Fork 627
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apply the x86-only OpenVPN repo on x86 systems only #963
Conversation
Which
With such release file the script is not broken on supported boards as Nevertheless, checking for the architecture too is a good idea, I wil also add something similar to avoid this. |
As we are frequently using that file ... I am actually building a repo with distros os-release files ... so we can later one use them for testing. will let you know when its done .. i might have it done next weekend. Sorry for not paying to much attention to whats going on at the moment but been busy with IRL work ... |
Ah yes that's true for RPis on DietPi as well, but on all other SBCs Debian is the base OS. (@4s3ti) Generally, as I see Ubuntu also supported and potentially other distros, one cannot rely on
😄 I was already thinking/wanted to have a look about how you manage to support WireGuard in a generic way, which we (DietPi) fail so far. The problem is indeed the kernel headers, which are not always pre-installed, and depending on particular used kernel/bootloader/firmware repo/sources those can follow a vast difference of naming schemes:
So basically, if one does not want to force/install a specific kernel package along with PiVPN, the only reliable way is to tell users on non-RPi ARM systems to assure that matching kernel headers are available, before proceeding. |
Considered that the team currently working on PiVPN is very small, I think it's best to officially support Raspbian, x86/x86_64 Debian, x86/x86_64 Ubuntu. By official I mean that the script should have a code path for those platform (even though with minor variations more platforms can be added, however, those require hours of testing over time and we cannot afford this). To break down:
Works fine with OpenVPN but not with WireGuard, see: Lines 1148 to 1151 in f749d6b
Indeed, discussed in the comments here: #957 |
Same here 😅, sounds reasonable. We can share the cases where DietPi offers WireGuard and how to detect reliable if related repos are available, if wanted.
Actually in case of OpenVPN there should be no limitations required. Debian and Ubuntu provide packages for all architectures and no kernel headers are required. Raspbian is not compatible with x86 and provides packages for armv6hf, compatible with all ARMs (in theory). The OpenVPN repo for x86 is nice-to-have for newer version but not required and might even make installs less comparable? However "openvpn" is available on all DPKG-based distros that I know, Raspbian, Debian, Ubuntu with official repo sources for sure.
To be precise, "Raspbian" is not what counts here, but the Raspberry Pi repo for kernel/firmware/headers (
|
Agree but it provides a big version jump on Debian Stretch (from 2.4.0 to 2.4.8).
Great, I didn’t know that.
This may prevent incidents like this too. Will try to reorganize the installer and do some test when I have time. |
Possible. Especially on Raspbian the native Raspbian bullseye suite might as well contain some tweaks/fixes for RPis, e.g. not sure if DKMS is triggered on RPi kernel upgrades when using the Debian repo/packages. |
@MichaIng I pushed some changes to the test branch. Specifically, switching to bullseye allowed me to remove a lot of code! |
@orazioedoardo
Ah I see you did a source build prior to this. The advantage of the Debian/Raspbian package as well is that a DMKS module rebuild is forced on every kernel package upgrade. Not sure if the source build adds an |
I think the point is clear? See https://build.openvpn.net/debian/openvpn/stable/dists/buster/main/ for supported architectures.
Adding this to non-supported systems (all ARMs) leads to apt update failures and hence breaks error handled scripts.
The alternative would be to simply remove applying this repo, which would make installs across different architectures consistent, by staying with official distro repo. But better to have a quick fix now than long discussion 😉.