systemctl and service name on Debian Jessie about stouts.openvpn

[kidk]

@davidlballenger Does this cause the openvpn service not to start?

I've seen an issue like that on my Debian machine, and was just wandering if this is related. If so, could you share your changes?

Thanks

[ceribik]

I can confirm this issue. the @server part has to reflect the config name in /etc/openvpn

The server will not start if only "openvpn" is enabled.

[mowgli]

This is a particular stopper at all to use Stouts.openvpn on jessie. The bla@foo style only works with systemd. Usually you don't want to have a full blown systemd on your server(s).

For all others (and as I can see also with systemd) there is the way to enable the server via /etc/defaults/openvpn as usual.

So please revert to that style or make it at least overwritable. vars are not overwritable. I suggest to use ansible_service_mgr fact.

[conorsch]

To be clear, the initial issue presented here was resolved by #39.

This is a particular stopper at all to use Stouts.openvpn on jessie. The bla@foo style only works with systemd. Usually you don't want to have a full blown systemd on your server(s).

The new format works well for me under Jessie—are you modifying your Jessie boxes to use less systemd?

So please revert to that style or make it at least overwritable. vars are not overwritable.

You have a point there; role vars are quite aggressive and difficult to override. The most effective pragma I've seen for dealing with distro-specific vars files while preserving override capability is a two-pass approach with wrapper vars. @geerlingguy uses this quite a bit, e.g.

1. https://github.com/geerlingguy/ansible-role-apache/blob/b280d7af54103270fda16f06f24dfa43b74c291d/vars/Debian.yml#L8-L10
2. https://github.com/geerlingguy/ansible-role-apache/blob/b280d7af54103270fda16f06f24dfa43b74c291d/tasks/main.yml#L6-L9

Would an approach like the above work for your use case, @mowgli?

[mowgli]

No, I didn't modify it. I simply refused to use systemd. I simply use the more stable initv init system.

I guess that this would help. But where is that different then to just move it to defaults/main.yaml?

However, for this specific case there is already a fact "ansible_service_mgr" available that can be the values "sysvinit", "systemd" or "upstart" (maybe more). Just using the distribution to decide that value is not stable.

[mowgli]

I add #60 to fix the problem (themprarily).

As I mention there, the fix should work with systemd too (just the same way as all other setup on debian will work) The systemd @blabla stuff is just some non-compatible shortcut.

[nkakouros]

We already have this in place.