MichaIng
Bad news :PiVPN is ending.
@MichaIng
Will DietPi support PiVPN or remove PiVPN from Dietpi-software?
That is bad news indeed. We will keep it for a while. I mean the repo will remain and functional, it is just not updated anymore.
However, it is not so bad. In the end, PiVPN was only a CLI for managing OpenVPN/WireGuard client certificates, which we both have dedicated install options for. It is not a huge task to just create an own CLI and whiptail dialog UI for the OpenVPN and WireGuard options we already have. Still someone needs to find time and mood to do it.
That's so bad - such a software jewel....
Maybe is a wg-easy without docker a alternate solution...
Will Dietpi update piVPN to the latest build? Apt Update doesn't find any updates...
There was never any PiVPN APT repo, or did I miss something? Just reinstalling it will rerun the installer script, which implies an update to latest release:
dietpi-software reinstall 117
Yep - I've write bullshit and removed sec ago - sorry 😅
If i reinstall I've got this feedback
Jep, that looks good. ... erm or not
The updating functionality for PiVPN scripts is temporarily disabled
What? Oh, indeed, somehow this update functionality has been "temporarily disabled" since 4 years already, with this PR: https://github.com/pivpn/pivpn/pull/1060 No idea why and whether it is intended or not.
In this case, select "Repair".
I posted to the forum thread but probably better to share the hardened openvpn script here. Obviously doesn’t cover wireguard however. https://github.com/angristan/openvpn-install
I posted to the forum thread but probably better to share the hardened openvpn script here. Obviously doesn’t cover wireguard however. https://github.com/angristan/openvpn-install
huh? Don't have dietpi-software openvpn?
My mistake. I didn’t realize there was a good openvpn script in place. I’ve always used pivpn 🫣🥺. Not sure about dietpi’s openvpn script but the one I shared’s main focus is being hardened.
We offer own individual options for Wireguard as well as OpenVPN. However client management needs to be done manually by the user.
Benefit of PiVPN was the CLI interface around both VPN server.
Indeed, and I am not aware of other well known/trusted CLI wrappers for OpenVPN and WireGuard. There are web interfaces and fancy stuff like that, but I personally prefer simple/slim CLIs over fancy often bloated web interfaces, which require another open port, imply another attack vector, are often intended to be installed with a container engine (another possible point of failure) etc.
And the web tools usually have their own individual configuration, not taking into account the one we use. Which makes it quite complicated to add to existing installations. At least I did not find a web interface for Wireguard respecting existing configuration.
Jep. If we create an own CLI, I want to have it as compatible as possible, allowing to edit individual known config entries of any existing server and client config (found in a specific path), only optionally creating/resetting a config to/from scratch.
Is it not somewhat easier to just fork PiVPN and customise it for DietPi?
We can and will just keep using the original PiVPN repo as long as it works. There is no need to customise it for DietPi. But at some point, just in case it is really not maintained anymore (currently it looks like it will still be maintained), we are not able to maintain a project like PiVPN ourselves. But we are able to maintain a little CLI for our own OpenVPN/WireGuard server implementations, based on initial client config/certs and docs we already have.
UPDATE: I'm owner now.
currently it looks like it will still be maintained
I'm currently unable to do that since the master branch is locked and branch protection can't be disabled by collaborators. In case @4s3ti doesn't fix this, I can fork the repo and you can switch DietPi to the fork if you want.
Thanks for chiming in, and great that you have become orga owner. With stricter issue rules and "best-efforts maintenance" notice it is a good solution, IMO. I've seen that you raised min Debian version to Buster. As it is required for our own OpenVPN implementation, I'll have a closer look OpenVPN server settings from v2.5 on and in case open some PR to update them at PiVPN for current best practice.
And I think that is makes sense to think about either removing the (disabled) "Update" option on for existing PiVPN installs or (my preference) re-enable it, in case combined with some config migration (notice) system, when incompatibilities between client and server configs are possible.
I'll have a closer look OpenVPN server settings from v2.5 on and in case open some PR to update them at PiVPN for current best practice.
Me too, I was considering jumping directly to OpenVPN 2.6 for Ubuntu 24.04 and Debian 12 users if client software for Mac/Windows/iOS/Android support the new features, while keeping 2.4 option for compatibility.
re-enable it, in case combined with some config migration (notice) system, when incompatibilities between client and server configs are possible
Notice systems shouldn't be difficult by including the git tag in the setupVars.conf and comparing with the new version. Config migration would require some generic system with pre/post update scripts.
Config migration would require some generic system with pre/post update scripts.
Yes, this is what I was thinking about. Elegant would be to show some notice that a migration is required, prior to the update, giving the option to exit, and otherwise a migration script after the update.
However, as far as I can think of, it is about the compatibility between newly generated or updated client configs and the existing server config. If the server config is migrated, all client configs might need to be updated, which cannot be done at the client side by a server-side script. And since an update of the PiVPN scripts does not necessarily imply an update of any client or server config (?), it could also be done when adding/updating client configs instead: Checking the server config for some known changed (and in case incompatible) settings, and give a warning that a server config change would need to be required, and in case an update of all other client configs. But probably the issue/reason why updates were disabled initially were different than what I am thinking about. Because a reinstall/reconfiguration can cause exactly the same problem, as this does imply a rewrite of the server config (?) and in case incompatibility of client configs.