the /etc/init.d/openvpn from the latest version 2.0.2-r3 of openvpn (at linely 43) may not want to have --cd "${VPNDIR}" since it will restrict the entire machine to only one configuration directory. For people with multiple VPN connections will be a hassle. Instead allow the cd option to be defined within local.conf of each openvpn setup. In addition, the init.d file also enforce single configuration file, /etc/openvpn/openvpn.conf instead of allowing multiple VPN connections setup. Reproducible: Always Steps to Reproduce: 1. emerge to openvpn 2.0.2-r3 2. etc-update to accept the new /etc/init.d/openvpn 3. restart openvpn Actual Results: * Starting openvpn for server ... [ !! ] Expected Results: * Starting openvpn for server ... [ok] if run the openvpn startup via command line, it will complain not able to find the server certificate (if my server certificate reside under /etc/openvpn/newyork/ instead of /etc/openvpn since I use multiple openvpn connection for different offices, there are /etc/openvpn/newyork, /etc/openvpn/idaho, etc...) The init script may want to loop thru /etc/openvpn/*.conf instead of single file since each of the /etc/openvpn/*.conf can be symbolic link from sub-directory for each corresponding setup.
Created attachment 70732 [details] init.d file that have the workaround as described in the bug note
If you read the post emerge instructions, you would have a .conf file for each vpn you wish to run in /etc/openvpn. Each .conf file requires it's own init.d script - this is to allow each vpn to be started and stopped independantly of each other, and each can optionally depend on specific net interfaces. For example, 3 vpns /etc/openvpn/openvpn.conf /etc/openvpn/foo.conf /etc/openvpn/bar.conf Require 3 init scripts /etc/init.d/openvpn /etc/init.d/openvpn.foo /etc/init.d/openvpn.bar You can create the extra to as symlinks, so when the main openvpn init script gets updated the others do as well. cd /etc/init.d ln -s openvpn openvpn.foo ln -s openvpn openvpn.bar As to the --cd option - that only affects relative paths, for example ca /etc/ssl/certs/uberCA.pem ca uberCA.pem The first option always works, whereas the second one means that the ca cert has to be in /etc/openvpn marking as WONFTIX - reopen if you disagree
Created attachment 70951 [details] More clean up for the sake of completeness
Some issues with that script 1) You cannot start/stop each vpn individually. This is a must. 2) Say you remove/rename a .conf file in /etc/openvpn and then "stop". That openvpn instance will not get stopped (yes, you could argue that the same occurs with symlinking init scripts, but that applies to all Gentoo at this time)
Created attachment 70983 [details] Updated init.d file to address the stop issue mentioned by Roy
Regarding start/stop individual openvpn, I believe having separate init.d script to do that may be not so "scalable", i.e. if I have more VPN connections where each of these connections has its own set of config and certificate files... it will be quite a nightmare to maintain provide system admin point of view. I wonder (for discussion purpose) if init.d script can take "additional" parameter so we can start/stop the individual "sub" openvpn connections by doing: /etc/init.d/openvpn start gateway where gateway is from /etc/openvpn/gateway.conf and /etc/openvpn/gateway is the sub-directory for all the certificate files. This may not be so much into LSB standard (correct me if I am wrong.) Just a thought.
(In reply to comment #7) > Regarding start/stop individual openvpn, I believe having separate init.d script > to do that may be not so "scalable", i.e. if I have more VPN connections where > each of these connecti ons has its own set of config and certificate files... it > will be quite a nightmare to maintain provide system admin point of view. You mean that creating a new foo.vpn config takes less time and effort than a cd /etc/init.d ln -s openvpn openvpn.foo ??? I think not. The net.ethx scripts are setup in the same way, and yet I hear no-one complaining about scalability there. I myself have around 30 net.* symlinks. Is this a pain to maintain? Nope. Also, if you're a sysadmin with many openvpns and you add a new one, you have to restart all the others this init script! Won't that kill active connections? What I do think though is that the openvpn script could provide both - controlled by a variable in /etc/conf.d/openvpn. Say OPENVPN_ONE_INIT="yes|no" defaulting to "no". But I'm loath todo this as the only argument for your way of thinking so far is "may not scale" and I doubt you'll have more openvpns than net.* scripts.
config files also referring to certificates and post-connect/post-disconnect script. So there will be a bunch of files not just one config file. The current init.d script will require sysadmin to go from one directory to another for a single VPN connection. I prefer every related file in single directory. I do agree with you that restart is an issue with the single init.d file approach since it require bounces of all existing connection. [brain storming mode] may be we can suggestion openvpn author to include "graceful" shutdown option like apache has.[/brain storming mode] In my real-life openvpn application, I have multiple OpenVPN connections for different network segments each connection has it's own setup of SSL certificates. These connections are managed by a single server dedicated as OpenVPN server. Like you said and as I stated in the forum, my preference not neccessary your preference, and most likely exception case. Just hoping init.d script can be more flexible to address different needs. [brain storming mode]May be we can have a script, something like, ovpn-config, to centralize typical operational on config, ssl certificate and post-connect/post-disconnect scripts, so sysadmin won't have to remember/dig into the script to figure out where are the ssl certificate, post-connect/post-disconnect scripts in the environment.[/brain storming mode]
re-opening
openvpn-2.0.4 init script now appends the --cd option only when the config file does not contain it. This should satisfy your initial report. If you still think we should add an option to troll through /etc/openvpn and start all *.conf files there, then please open a new bug.