Bug 1118441 - custom script is not executed on startup
Summary: custom script is not executed on startup
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: openvpn
Version: epel7
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Steven Pritchard
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-10 17:47 UTC by Jiří Sléžka
Modified: 2018-02-16 11:40 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2018-02-16 11:40:12 UTC

Attachments (Terms of Use)

Description Jiří Sléžka 2014-07-10 17:47:10 UTC
Description of problem:

Openvpn's behavior from el6 Epel is this: When exists .sh script in /etc/openvpn directory with the same name as .conf file then it is executed on openvpn startup. It is done by startup script.

Epel7 version doesn't behave this way.

Version-Release number of selected component (if applicable):


How reproducible:

have myvpn.conf configuration file and myvpn.sh shell script (btw. mostly used for setting-up bridging).

Steps to Reproduce:

Actual results:

script is not executed on startup

Expected results:

script is executed on startup

Additional info:

my workaround is to modify systemd startup script at /lib/systemd/system/openvpn@.service

I added line

ExecStartPre=-/bin/bash -c /etc/openvpn/%i.sh

before line

ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf

Comment 1 David Sommerseth 2018-02-16 11:40:12 UTC
The workaround here is in this case a far better approach than to let OpenVPN do this execution.  Systemd can ensure the script runs with the proper privileges, while the OpenVPN binary will not be capable of that in the same degree.

The script hooks in OpenVPN will have issues on modern Linux distributions when it wants to modify the system configuration on-the-fly, often due to restrictions set by SELinux or capabilities via systemd.  There are no good solutions to that without reducing the security measurements around OpenVPN.

So the best approach is to let OpenVPN take care of the VPN tunnel itself and the changes to the system configuration to be done outside of OpenVPN.

Note You need to log in before you can comment on or make changes to this bug.