Bug 700490 - RFE/Patch: start openvpn for each *.ovpn in addition to *.conf in /etc/openvpn
RFE/Patch: start openvpn for each *.ovpn in addition to *.conf in /etc/openvpn
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: openvpn (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Sommerseth
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-28 10:07 EDT by Ville Skyttä
Modified: 2017-03-25 02:20 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-03-24 19:50:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Make init script start openvpn for each *.ovpn in addition to *.conf (126 bytes, text/plain)
2011-04-28 10:07 EDT, Ville Skyttä
no flags Details

  None (edit)
Description Ville Skyttä 2011-04-28 10:07:18 EDT
Created attachment 495551 [details]
Make init script start openvpn for each *.ovpn in addition to *.conf

Many systems (appliances etc) generate and assume OpenVPN config files to be named *.ovpn; the attached patch makes the init script activate openvpn on them in addition to *.conf in /etc/openvpn.

I submitted a patch upstream but after some discussion they decided to reject it.  I think their reasoning for the rejection was quite thin and I don't agree with it at all (they seem to be making a tempest in a teacup out of it in my opinion), but anyway they seem to encourage distributors to do something like this.

The patch and discussion is at https://community.openvpn.net/openvpn/ticket/96 , please consider applying the patch to the init script shipped in Fedora and EPEL openvpn packages.
Comment 1 Fedora Admin XMLRPC Client 2014-11-10 10:37:49 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 2 Fedora Admin XMLRPC Client 2014-11-10 10:51:12 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 Fedora Admin XMLRPC Client 2017-03-14 08:15:17 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 David Sommerseth 2017-03-24 19:50:44 EDT
A lot have happened since this bz was opened, like the introduction of systemd.

The recommended approach by upstream (available in openvpn-2.4.1) is to use the openvpn-client@.service and openvpn-server@.service systemd unit files, which provides far better control of OpenVPN tunnels.

For more info: http://pkgs.fedoraproject.org/cgit/rpms/openvpn.git/tree/README.systemd

We will not add support for .ovpn files at this point, as the more common file extension for configuration files on Linux are .conf while .ovpn is an artefact to avoid "double click clashes" on Windows.
Comment 5 Ville Skyttä 2017-03-25 02:20:19 EDT
(In reply to David Sommerseth from comment #4)
> We will not add support for .ovpn files at this point, as the more common
> file extension for configuration files on Linux are .conf while .ovpn is an
> artefact to avoid "double click clashes" on Windows.

There are firewall appliances etc out there that give out their configs named as .ovpn, and that obviously can't really be changed. It doesn't matter why it was done, Windows reasons or not, but it does require e.g. Fedora users to jump through extra hoops. Making a tiny change like this in this package would make life easier for its users (no need to fiddle with the filenames), without any drawbacks. Otherwise dealing with it is left to the users themselves.

Yeah, a lot has happened, and maybe the systemd stuff has made the request obsolete. From a very quick look at the linked documentation, I suppose it hasn't though (as it does insist on .conf filenames still).

But meh, I'm no longer personally affected by this, so I'm not going to be burning any more cycles here. I'm just pretty surprised and somewhat disappointed about the reluctance to apply something as trivial as this.

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