I have two systems using OpenVPN and recently upgraded to 2.1_rc9 on ~x86. Suddenly I found that PEER_DNS was no longer honoured (set in /etc/conf.d/openvpn). I use a /etc/init.d/openvpn.<myvpn> style configuration. Reproducible: Always Steps to Reproduce: 1. Upgrade to latest OVPN with PEER_DNS="no" set 2. DNS settings in resolv.conf overwritten 3. /etc/resolv.conf gets changed Actual Results: resolv.conf changed Expected Results: resolv.conf not to change I can see where the init script has this: # Ensure that our scripts get the PEER_DNS variable export PEER_DNS I set an ewarn in the script and saw the setting at that point OK. I changed up.sh and down.sh by adding SET_PEER="no" manually and that "fixed it". I am using OpenRC but don't think that is the fault because I'm fairly sure that the previous OVPN I ran didn't suffer from this.
I am having the same problem. Using OpenRC with /etc/conf.d/openvpn -> PEER_DNS="no" but it does get changed. A fix for that would be highly appreciated.
(In reply to comment #0) > I have two systems using OpenVPN and recently upgraded to 2.1_rc9 on ~x86. > Suddenly I found that PEER_DNS was no longer honoured (set in > /etc/conf.d/openvpn). > > I use a /etc/init.d/openvpn.<myvpn> style configuration. > > Reproducible: Always > > Steps to Reproduce: > 1. Upgrade to latest OVPN with PEER_DNS="no" set > 2. DNS settings in resolv.conf overwritten > 3. /etc/resolv.conf gets changed > > Actual Results: > resolv.conf changed > > Expected Results: > resolv.conf not to change > > I can see where the init script has this: > # Ensure that our scripts get the PEER_DNS variable > export PEER_DNS > > I set an ewarn in the script and saw the setting at that point OK. > > I changed up.sh and down.sh by adding SET_PEER="no" manually and that "fixed > it". Did you verify that PEER_DNS was empty in this script? > I am using OpenRC but don't think that is the fault because I'm fairly sure > that the previous OVPN I ran didn't suffer from this. This looks like the same bug I'm seeing with SVCNAME. I've checked, as you did, and I see it's defined correctly in the init script, but is empty when the up.sh script is run. As a result, my service-specific ${SVCNAME}-up.sh script doesn't get run. As in your case, I can 'fix' it by redefining SVCNAME in up.sh.
Here's a fix for both of our problems that, at least, doesn't break when a different vpn service is started: Modify /etc/init.d/openvpn as follows: < -- --config "${VPNCONF}" --writepid "${VPNPID}" --daemon ${args} --- > -- --config "${VPNCONF}" --writepid "${VPNPID}" --setenv SVCNAME "${SVCNAME}" \ > --setenv PEER_DNS "${PEER_DNS}" --daemon ${args}
oops...that also needs to be done for shutdown; add -- --setenv SVCNAME "${SVCNAME}" --setenv PEER_DNS "${PEER_DNS}" to the end of the start-stop-daemon call
Thanks meme, it works really well. I tested it with settings peerdns to yes and no and the config works fine again. I am using openrc as well so I don't know if it still works with the old system. If no one objects this should enter the tree.
Maybe there's a better way to get the environment across to openvpn, or maybe there are more variables needed... Noone else seems to be reading this bug, so CC:roy@marples.name
Created attachment 166092 [details, diff] Fix openvpn init script for setenv OpenRC is not to blame here - newer versions of OpenVPN dictate the whole env to the scripts, so exporting variables is now useless. This patch to the script fixes that.
Thanks Roy. Something is needed for the shutdown side too though. I did this: ebegin "Stopping ${SVCNAME}" start-stop-daemon --stop --quiet \ - --exec /usr/sbin/openvpn --pidfile "${VPNPID}" + --exec /usr/sbin/openvpn --pidfile "${VPNPID}" \ + -- --setenv SVCNAME "${SVCNAME}" --setenv PEER_DNS "${SVCNAME}" eend $? }
(In reply to comment #8) Oops...worked for me, but the last line, of course, should be > + -- --setenv SVCNAME "${SVCNAME}" --setenv PEER_DNS "${PEER_DNS}"
Your patch does nothing, as stopping OpenVPN does not affect the environment the current OpenVPN process sends to scripts. What issues did you see shutting OpenVPN down?
(In reply to comment #10) > Your patch does nothing, as stopping OpenVPN does not affect the environment > the current OpenVPN process sends to scripts. > > What issues did you see shutting OpenVPN down? My shutdown script didn't run...I thought. I've checked again with only the startup part of the patch, and it works fine. Sorry about that.
Fix in cvs
