[bug] VPN_NAME cannot contain whitespace due to supervisord limitations

[pandafy]

Describe the bug
If the VPN_NAME environment variable contains any whitespace characters, supervisord fails to start the associated process. This is because VPN_NAME is used internally by supervisord in a manner that does not handle whitespace correctly.

Steps To Reproduce
Steps to reproduce the behavior:

1. Set VPN_NAME to a value containing a space (e.g. export VPN_NAME="my vpn").
2. Build and run the docker-openwisp container.
3. Supervisord will fail to start as expected.

Expected behavior
VPN_NAME should either reject values with whitespace or documentation should clearly call out this limitation. Supervisord should not fail silently if VPN_NAME contains whitespace.

[pandafy]

I identified an additional issue related to the VPN_NAME environment variable.

According to the documentation, VPN_NAME is intended to define the VPN object name in OpenWISP. However, it is also implicitly used by the OpenVPN container to locate the corresponding server configuration file (see the original issue for context).

When OpenWISP generates the VPN configuration, it derives the OpenVPN configuration filename from:

Vpn.config['openvpn'][0]['name']

Reference:

docker-openwisp/images/openwisp_dashboard/openvpn.json

Line 5 in 2b174ff

"name": "default",

As a consequence, if a user sets the VPN_NAME environment variable to a value other than default, the OpenVPN container fails to start because it cannot find a matching configuration file.

In summary, VPN_NAME currently serves two distinct purposes:

1. Defining the VPN object name in OpenWISP.
2. Determining the expected OpenVPN server configuration filename.

This coupling creates a configuration inconsistency and prevents arbitrary renaming of the VPN via the VPN_NAME environment variable.

Possible fix

We can simplify the OpenVPN setup by explicitly configuring the interface name as tun0 in the OpenVPN configuration (e.g., dev tun0). This removes the need to dynamically determine or propagate the interface name.

With a fixed interface name, we can eliminate the VPN_NAME variable from the Supervisor configuration, reducing complexity and avoiding unnecessary coupling between OpenVPN and process supervision.

Additionally, we can implement a small script that inspects the vpn.tar.gz package downloaded from OpenWISP. The script would extract or identify the *.conf file within the archive, allowing us to reliably determine the OpenVPN configuration filename at runtime instead of relying on hardcoded assumptions.

[Piyushkhobragade]

Taking a look at this. I’ll investigate and open a PR with a fix.