Replace current OpenVPN Rockon with official docker image

[Hooverdan96]

This issue is opened in the context of one in the rockstore-core repo #2913.

The current Rockon with its underlying image is the last remaining one that takes advantage of the custom_config tag, to enable additional automated setup/config that the usual docker run context does not provide out of the box. To reduce the dependency on additional coding, it should be considered to switch the Rockon to the image offered by OpenVPN:

OpenVPN has (not known when) released its own official version of a docker image, including a WebUI which could possibly make configuration more user-friendly:

https://hub.docker.com/r/openvpn/openvpn-as

Let's determine whether this is a viable replacement.

[Hooverdan96]

I might have jumped the gun a little bit here. The "official" container is not the community edition, but the commercial one (Access Server). With that one 2 concurrent connections are available for free, but beyond that, there's a cost. It's nicely done, of course.

So, probably need to look for another community version that's more recent and fits into the Rockon framework. playing around with another server/UI combo from here, is not that straightforward due to shared directories, which Rockstor currently does not support "(yet):

https://github.com/d3vilh/openvpn-server (and the corresponding UI container: https://github.com/d3vilh/openvpn-ui). Cool combo, though.

The other one I'm currently looking at, is this one, but it also comes with a few caveats:
https://github.com/dockovpn/dockovpn?tab=readme-ov-file

So, not sure, on some forums the opinion is that everybody went to Wireguard (or Tailscale) and hence OpenVPN on docker has been abandoned in many cases ... not sure about that.

So, question then is, whether to fix the current OpenVPN incarnation (which, considering the number of pulls on docker Hub is still the most popular, though I stopped using it and made the switch to Wireguard), try to figure out what to do about an alternative, or abandon it.

[phillxnet]

@Hooverdan96 Re:

... is not that straightforward due to shared directories, which Rockstor currently does not support "(yet): ...

You can do this, between containers in a Rockon, via the --volumes-from, but this requires the container mapped dir to be the same. I.e. as done with the progress to date on the Bareos PR Rockon. Just a thought.

Re:

So, question then is, whether to fix the current OpenVPN incarnation ... try to figure out what to do about an alternative, or abandon it.

I'm OK with sun-setting our OpenVPM Rock-on. But I'd like to keep our custom_options capability however. We may end-up needing this again, and it could enable our incorporating an important Rock-on that otherwise is just not accessible to us. I think the Discourse container was a candidate on that front: needed quite the external treatment as I remember, when last I looked.

See what you think re available OpenVPN container options.

[Hooverdan96]

You can do this, between containers in a Rockon, via the --volumes-from, but this requires the container mapped dir to be the same. I.e. as done with the progress to date on the Bareos PR Rockon. Just a thought.

yes, so far it will work partially in the first example (for all the config directories). For the d3vilh version (server and UI), I was able to consolidate most of the configuration mappings into a single one. Unfortunately, one of the storage places (for the pki) is specific on the UI and needs to be defined in both containers and that's when I will run into the "duplicate" share usage constraint we still have.

[phillxnet]

@Hooverdan96
Re:

Unfortunately, one of the storage places (for the pki) is specific on the UI and needs to be defined in both containers and that's when I will run into the "duplicate" share usage constraint we still have.

Another hack I used in the same draft Bareos PR referenced already, was to state an share must be named 'what-ever'. Then this same share name can be mapped differently to two different containers. One via our Volumes, and then do a -v option to map it specifically by name to a different internal directory to the second container. Messy I know. Look to the bareos-webui and it's associated PHP-FPM container. They each needed to share a volume but at different internal directories. That was a hack-to-far for me, especially on-top of all the other 'accomodations. Hence embarking on bareos docker image definitions of our own from there-on. But it may relate to your requirement here.

[Hooverdan96]

ah, yes, I will look at that more closely again.