does not work with systemd and severals VPN created

[jdevzero]

Tried running it on Centos 7 latest and it doesn't start the openvpn process because of the new openvpn systemd logic

openvpn@service where service=service.conf inside /etc/openvpn.

[luxflux]

Could you elaborate this a bit more? What should be changed to get this working? Is there an error message?

[ulfdalen]

CentOS Linux release 7.2.1511 (Core)

Work fine.

[jameskirsop]

This seems to be true for me, running under the patches I've mentioned in #216 to support easy-rsa 3.0. I'm unsure if it worked before that because I never tried under easy-rsa 2.0:

I get the following output after the configuration is successfully deployed:

Info: Openvpn::Deploy::Client[rmc-nms.rmcollege.local]: Scheduling refresh of Class[Openvpn::Deploy::Service]
Info: Class[Openvpn::Deploy::Service]: Scheduling refresh of Service[openvpn]
Error: Systemd start for openvpn failed!
journalctl log for openvpn:
-- No entries --

Error: /Stage[main]/Openvpn::Deploy::Service/Service[openvpn]/ensure: change from 'stopped' to 'running' failed: Systemd start for openvpn failed!
journalctl log for openvpn:
-- No entries --

My understanding is that the issue is the service name should be openvpn@${name} where $name is the name of the host (and hence the config file) that it loads on launch.

Using the hostname in the example above, I can run service [email protected] start and have it start with no problem. I've tried hacking something together to make this work but haven't really got anywhere.

[jameskirsop]

An update on this that might be of assistance while people wait for this to be fixed properly. I've put together a not-very-clean hack that gets the service to start with no trouble. It's only good if you have a single host connection back to one server (one-to-one) and you name your connections the same as your $clientcert fact.

It's working for us in production now - and is far better than having services not start or restart when required (which meant manual intervention on all our nodes every time something fell off-line or we needed to make a change).

[Dan33l]

since #216 is closed, i suppose this issue can also be close.

[barrypitman]

I don't think so - the name of the service is still hard-coded to "openvpn" in openvpn::deploy::service.

The problem with recent versions of OpenVPN & CentOS is that there isn't a single "openvpn" service anymore. Instead, OpenVPN makes use of systemd's support for "Instantiated Services" to dynamically create a new logical service for each *.conf file under /etc/openvpn/.

So if I want to start an OpenVPN instance based on the contents of /etc/openvpn/myvpn.conf, I would need to start/stop it using systemctl start|stop [email protected]. You can also start/stop all openvpn instances using systemctl start|stop 'openvpn*.service'.

Out of interest, this is the content of the /usr/lib/systemd/system/[email protected] file on my system (note the use of %i):

Description=OpenVPN Robust And Highly Flexible Tunneling Application On %I
After=network.target

[Service]
Type=notify
PrivateTmp=true
ExecStart=/usr/sbin/openvpn --cd /etc/openvpn/ --config %i.conf

[Install]
WantedBy=multi-user.target

Currently, openvpn::deploy::service is declared as a class, so there can only be once instance of it. The easy fix will be to use a service name of openvpn* instead of openvpn in openvpn::deploy::service (for newer versions of CentOS/Red Hat). This will start/stop all openvpn service instances on the target machine.

Ideally though, openvpn::deploy::service would need to be re-worked as a define/resource instead of a class so that each openvpn service can be managed individually

[Dan33l]

Ah yes it makes sense. Are you interested in proposing a PR ?

[oscar-vlugt]

I'm still experiencing this issue and I do wonder why the proposed PR https://github.com/voxpupuli/puppet-openvpn/pull/350 isn't merged at this point or fixed?

[plexium]

Same. This PR would be great if merged!