openvpn-install: FIX - Error opening configuration file: server.conf

fixfiles -R openvpn restore

also did fix this issue on Rocky Linux 9. Thanks @Sispheor

On my side the error was due to selinux (centos8) I used this to fix

fixfiles -R openvpn restore

Tried that first time it didn’t work and got sudo: fixfiles: command not found. Did apt-get install policycoreutils which after that, I retyped sudo fixfiles -R openvpn restore got this error /sbin/fixfiles: line 204: rpm: command not found openvpn not found

As you can see, the syslog is pumping the above reported error non-stop, which cannot possibly be good, but the service seems to be reporting that it is running.

openvpn-server@server.service (which is the right service) is not the same as openvpn@server.service (which is the one where you are seeing errors).

Use the script in a clean system and don’t mess with the services, it will work.

On my side the error was due to selinux (centos8) I used this to fix

fixfiles -R openvpn restore

you should start service after installation in the script

I do, see line 365.

I always used openvpn@server in the past, I do not know why it has 2 service files?

Because the maintainers/developers decided to use a new service unit which is more flexible. The old service you were using will probably be discontinued in the future.

I’m from the upstream OpenVPN core team. Please read the documentation for the systemd implementation, available here: https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/README.systemd

The separation between client and server profiles was done for 2 reasons: a) To not collide with the brokenness various Linux distros ships which has not been coordinated with the upstream OpenVPN project, and b) to allow different security hardening and behavior (like automatic service restart) in server and client roles.

The openvpn.service and openvpn@.service methods is not supported by upstream OpenVPN and considered being a broken legacy approach. Which is why upstream OpenVPN ships openvpn-client@.service and openvpn-server@.service to provide a standardized way to manage OpenVPN configurations across all distributions.

I can see why it’s happening:

openvpn package owns /lib/systemd/system/openvpn@.service systemd service file which has these lines:

WorkingDirectory=/etc/openvpn
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid

So, when template unit is instantiated as e.g. “openvpn@server.service”, it will look for config in --config /etc/openvpn/server.conf. Which obviously does not exist. Even openvpn package itself does not provide it, nor implies that location. I checked dpkg-query --listfiles openvpn:

/etc/openvpn
/etc/openvpn/client
/etc/openvpn/server
/etc/openvpn/update-resolv-conf

— that’s all for /etc/openvpn, and it does look like server config supposed to go under /etc/openvpn/server/ directory.

Moreover, openvpn-server@.service template uses different syntax for ExecStart:

WorkingDirectory=/etc/openvpn/server
ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf

Note that different working directory and the non-absolute config path being used here.

---

I think the we found here is the issue with openvpn packaging and systemd integration, and should be reported to OpenVPN repository instead.

You don’t need to do that. Service should be managed like this:

systemctl status openvpn-server@server.service