Apply the x86-only OpenVPN repo on x86 systems only

[MichaIng]

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 😉.

[orazioedoardo]

Which /etc/os-release does DietPi ship with? I always thought something like this:

$ cat os-release 
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="https://www.raspbian.org/"
SUPPORT_URL="https://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="https://www.raspbian.org/RaspbianBugs")

With such release file the script is not broken on supported boards as PLAT would be Raspbian.

Nevertheless, checking for the architecture too is a good idea, I wil also add something similar to avoid this.

[coolapso]

Which /etc/os-release does DietPi ship with? I always thought something like 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 ...

[MichaIng]

@orazioedoardo

With such release file the script is not broken on supported boards as PLAT would be Raspbian.

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 os-release to derive architecture or similar, but only derive whether Raspbian repo, Debian repo or Ubuntu repo should be present. But all those can be installed on all SBCs (~95% of cases 😉) as well.

uname -m reliably prints the kernels architecture, but e.g. aarch64 is compatible with armv6hf (Raspbian), armv7hf (Debian) arm64 deb packages. Based on which distro/particular image is installed, it can be one of those three. Hence I used the dpkg --print-architecture command here which is the only 100% reliable command to show which package architecture is pulled by default with apt/dpkg, hence also which 3rd-party repos can be used.

Nevertheless, checking for the architecture too is a good idea, I wil also add something similar to avoid this.

😄 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:

• Official RPi repo: raspberrypi-kernel-headers
• Debian (x86 only): linux-headers-amd64/linux-headers-686
• Armbian: Based on SoC and if legacy or mainline kernel, newer or older naming scheme, e.g. linux-source-current-rockchip64 ... however vast differences here, at best can be derived from currently installed kernel package, but then the version could be too old to still be present in repo etc...
  • But in case of Armbian our WireGuard build attempts failed so far.
• Everything else highly differs, e.g. Meverics Odroid repo, official Radxa, FriendlyARM, Pine64 repos, not to mention Orange/BananaPi and all those, not sure if they even have an official kernel repo, however different package names everywhere 😢.
• So DietPi only offers WireGuard for a handfull SBCs where we exactly know with kernel repo we ship with our images, hence which kernel+headers meta packages+naming are available.
• I see on Ubuntu you install linux-headers-generic, but this also only fits for the very specific Linux package shipped by Ubuntu repo. And I don't know any non-x86 system/image which seriously uses the Debian or Ubuntu generic ARM kernel packages, since they either simply do not work or only with very limited/broken hardware support.

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.

[orazioedoardo]

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:

• OpenVPN
  • Debian / Ubuntu with amd64/i686 repos: add repo and install
  • Raspbian with any repo (are there non ARM Raspbian?): install
• WireGuard
  • Debian with amd64 repo: install linux-headers-amd64, add repo and install
  • Debian with i686 repo: install linux-headers-686 (currently missing), add repo and install
  • Ubuntu with amd64/i686 repos: install linux-headers-generic, add PPA and installl
  • Raspbian with armv7l kernel: install raspberrypi-kernel-headers, add repo and install
  • Raspbian with armv6l kenel: install raspberrypi-kernel-headers, download and compile from source

uname -m reliably prints the kernels architecture, but e.g. aarch64 is compatible with armv6hf (Raspbian), armv7hf (Debian) arm64 deb packages. Based on which distro/particular image is installed, it can be one of those three. Hence I used the dpkg --print-architecture command here which is the only 100% reliable command to show which package architecture is pulled by default with apt/dpkg, hence with repos can be used.

Works fine with OpenVPN but not with WireGuard, see:

pivpn/auto_install/install.sh

Lines 1148 to 1151 in f749d6b

	# If this Raspberry Pi uses armv7l we can use the package from the repo
	# https://lists.zx2c4.com/pipermail/wireguard/2017-November/001885.html
	# Otherwhise compile and build the kernel module via DKMS (so it will
	# be recompiled on kernel upgrades)

Armbian: Based on SoC and if legacy or mainline kernel, newer or older naming scheme, e.g. linux-source-current-rockchip64 ... however vast differences here, at best can be derived from currently installed kernel package, but then the version could be too old to still be present in repo etc...

Indeed, discussed in the comments here: #957

[MichaIng]

@orazioedoardo

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.

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.

• OpenVPN
  • Debian / Ubuntu with amd64/i686 repos: add repo and install
  • Raspbian with any repo (are there non ARM Raspbian?): install

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.

• WireGuard

To be precise, "Raspbian" is not what counts here, but the Raspberry Pi repo for kernel/firmware/headers (raspi.list), which can be applied on Debian/Ubuntu as well to run an RPi there. However checking for all possible combinations is probably out of scope for now:

• If Raspbian is the OS, then one can 99% assume that it's an RPi => raspberrypi-kernel-headers and actually I would not apply a 3rd-party repo for WireGuard itself but use bullseye where WireGuard is natively available for Raspbian, hence ARMv6 RPi1/Zero as well now.
• Debian + Ubuntu x86-only makes sense as only combination where kernel+header packages can be reliable derived. Also there I would not add the "unstable" repo anymore but "bullseye" instead (if the system is not already on this Debian version), which passed one testing cycle already. Also I see you pin priority to 80, which prevents WireGuard package upgrades via apt upgrade. Use 100 instead to allow these. All other packages can be pinned to -1 to assure there are no accidental installs of other packages from this repo. E.g. on DietPi we do:

Package: *
Pin: release n=bullseye
Pin-Priority: -1

Package: wireguard wireguard-dkms wireguard-tools
Pin: release n=bullseye
Pin-Priority: 100

• (Only WireGuard packages can be pulled from bullseye, and those get sufficient pin priority to auto upgrade. However as fast as there are packages available on other/stable repo, those are preferred.)

[orazioedoardo]

The OpenVPN repo for x86 is nice-to-have for newer version but not required and might even make installs less comparable?

Agree but it provides a big version jump on Debian Stretch (from 2.4.0 to 2.4.8).

If Raspbian is the OS, then one can 99% assume that it's an RPi => raspberrypi-kernel-headers and actually I would not apply a 3rd-party repo for WireGuard itself but use bullseye where WireGuard is natively available for Raspbian, hence ARMv6 RPi1/Zero as well now.

Great, I didn’t know that.

Also there I would not add the "unstable" repo anymore but "bullseye" instead (if the system is not already on this Debian version), which passed one testing cycle already.

This may prevent incidents like this too.

Will try to reorganize the installer and do some test when I have time.

[MichaIng]

@orazioedoardo

This may prevent incidents like this too.

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.

[orazioedoardo]

@MichaIng I pushed some changes to the test branch. Specifically, switching to bullseye allowed me to remove a lot of code!

[MichaIng]

@orazioedoardo
I added some comment regarding priority pin on Bullseye systems and a more generic check if the wireguard package is already available via any installed repository: 0a30365#r37636774

Specifically, switching to bullseye allowed me to remove a lot of code!

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 /etc/kernel/postinst.d/ script as well for this. The package at least is less overhead coding- and dependency-wise and assured to be well integrated into the OS. Only downside with Bullseye repo is that one does not get the newest upstream version directly. We'll see how frequent those packages are updated, currently it looks fine: https://metadata.ftp-master.debian.org/changelogs//main/w/wireguard/wireguard_1.0.20200206-2_changelog