This article could have been avoided if the Debian documentation was up-to-date. Actually it is not, and the solution came from Fedora documentation for OpenVPN.

Debian 8 uses systemd by default, and it implies several changes, in  particular the way you start/stop your services.

The main topic : systemd

What changes

  • A new fancy command now manage the startup : systemctl (don't mess with the sysctl command used for network configuration !)

  • The startup dependencies are no longer in the LSB headers in startup scripts (way too simple, boy), the dependencies are stored as symlinks in subdirectories located in /etc/systemd/* . Note that /etc/systemd/ contains some static configuration files, and that the real services configuration files are stored in /lib/systemd/* (this is where the symlinks from /etc/systemd/* points to).

  • Some services have been split from monolithic startup to dynamic. It means that you potentially have to enable and run multiple "services" in order to actually start the full "service". For instance, OpenVPN no longer runs every available configuration in /etc/openvpn/*.conf , you have to explicitely activate each *.conf file as a service in systemd !

What doesn't change

  • You can still start your services with service servicename start.

  • The init scripts in /etc/init.d/* still exists, and some are still usable (monolithics services).

Run your OpenVPN configuration

While you can still use the command openvpn --config /etc/openvpn/yourconfigfile.conf, you should do it with systemd. If your configuration file is /etc/openvpn/sample.conf, you should start your VPN connexion with systemctl start openvpn@sample.service .

Note that service openvpn@sample start also works.

Start your VPN at boot

Again, the auto startup was too simple. You now have to enable every *.conf file at boot. Enable you newly sample.conf at startup with the command systemctl enable openvpn@sample.service

This actually creates a symlink in /etc/systemd/system/ pointing to /lib/systemd/system/openvpn@.service

Ok, it's simpler for dynamic loads, but who needs to dynamically enable and disable configuration at boot ? If I want a different configuration, I simply write different files in the right folder...

Meanwhile, in Debian Apache package

You can enable and disable VirtualHosts by using the /etc/apache2/sites-available/ and /etc/apache2/sites-enabled/ folders. No hidden features, no boot startup configuration, all configuration files in /etc/programname/ . Way too simple ?

Hey, what if we had to configure a startup script for every VirtualHost ? Should be fun, don't you think ?