openvpn: should it include a runit service?

[slymattz]

OpenVPN - a debate whether to include a runit service

As many of you might know, OpenVPN can be run either as a server or a client.

When run as a server, it needs some kind of a trigger that will start it at boot time. The current OpenVPN package does not, however, include a runit service.

When run as a client, it can be either started on boot which would typically require a runit service or it can be executed with the simple command openvpn /etc/openvpn/yourconfig.conf.

In the first two cases, I believe it is justifiable and reasonable to include a runit service. A few years ago, such a proposal wasn't upheld (https://github.com/void-linux/void-packages/pull/17906#issuecomment-569937899). I believe now's a good time to re-address this issue.

In my opinion, if Void aims to be as good of an option for a desktop as for a server, we require this change to happen. Of course, you can create the appropriate run file manually in /etc/sv/openvpn and you're good to go. However, such an approach seems to be particularly confusing for new users and it is also inconsistent with the fact that many other daemon servers DO have runit services that come along with them.

Therefore, I'd like to raise the question from the heading: should the openvpn package come with a runit service?

[Duncaen]

Might make sense to include example services for client and server, resembling usr/lib/systemd/system/[email protected] and usr/lib/systemd/system/[email protected] so users don't blindly enable the service just because they want to use openvpn as a client.

We've had bad experiences with shipping ready to use system services for things that should most likely not run as the system services, as example the pipewire and pulseaudio system services, where unexpected users started to enable those services without knowing that the preferred method of starting them is through some other means.

pipewire ships the example service as /usr/share/examples/sv/pipewire: https://github.com/void-linux/void-packages/blob/f574870935ed5c4f122c5ba84417f449dd4ca863/srcpkgs/pipewire/template#L61

[slymattz]

Enabling OpenVPN through ln -sv /etc/sv/openvpn /var/service would do nothing by default as /etc/openvpn does not even exist in Void's OpenVPN package.

You would have to either

mkdir -p /etc/openvpn
chmod 755 /etc/openvpn
cp /usr/share/examples/openvpn/client.conf /etc/openvpn/openvpn.conf
chmod 600 /etc/openvpn/openvpn.conf
vim /etc/openvpn/openvpn.conf # modify the default script
# or
cp /path/to/your/config.conf /etc/openvpn/openvpn.conf # if you have a tailor-made config for yourself

With no user intervention, OpenVPN won't run. If you have another path pointing to a client/server configuration, you can point to it by: echo "CONF_FILE=/path/to/vpn.conf > /etc/sv/openvpn/conf

As for the pipewire and pulseaudio analogy - I think these are completely different cases as the preferred method for them is, like you say, to be run by a user.

In an OpenVPN config file, you can specify both the user and the group that the process should be run by. As a matter of fact, you can run the process as an unprivileged user (on Debian, for instance, you just insert these lines in your openvpn config):

/etc/openvpn/openvpn.conf

user nobody
group nogroup

[Duncaen]

runit would restart the service every second.

[slymattz]

Oh, this I didn't know about :(

[Duncaen]

As for the pipewire and pulseaudio analogy - I think these are completely different cases as the preferred method for them is, like you say, to be run by a user.

Depends, many users probably just use NetworkManager to handle their VPN.

[slymattz]

I second the idea of supplying a runnit service somewhere in /usr/share/examples/sv/openvpn so that you could easily copy it to /etc/sv. For a regular user that would save a lot of trouble.

If you guys were to decide for it, do you think it would be necessary to have two directories, i.e. openvpn-client, openvpn-server or perhaps one openvpn should suffice?

[github-actions[bot]]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.