Bug 1253942 - NetworkManager-openconnect no longer passes nameservers to dispatcher scripts
NetworkManager-openconnect no longer passes nameservers to dispatcher scripts
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-15 17:38 EDT by James Ralston
Modified: 2015-09-18 14:15 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-18 14:15:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Ralston 2015-08-15 17:38:49 EDT
Description of problem:

When connecting to a VPN server via NetworkManager-openconnect, although NetworkManager updates /etc/resolv.conf with the nameservers as supplied by the VPN server, it fails to export those nameservers into the environment for dispatcher scripts.

This is a new problem that I've only noticed since I updated to Fedora 22. When I was running Fedora 20, NetworkManager properly exported the nameservers into the environment for dispatcher scripts, using the VPN_IP4_NAMESERVERS variable. (I believe Fedora 21 also worked correctly, but I can't say that for certain.)

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

1:NetworkManager-1.0.6-0.1.20150813git7e2caa2.fc22.x86_64
0:NetworkManager-openconnect-1.0.2-1.fc22.x86_64
0:openconnect-7.06-1.fc22.x86_64

Steps to Reproduce:

To reproduce this, just create a dispatcher script that dumps the current environment into a temporary file. Here's what I see when I connect to our VPN server:

#BASH=/bin/sh
#BASHOPTS=cmdhist:complete_fullquote:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
#BASH_ALIASES=()
#BASH_ARGC=([0]="2")
#BASH_ARGV=([0]="up" [1]="vpn0")
#BASH_CMDS=()
#BASH_LINENO=([0]="0")
#BASH_SOURCE=([0]="/etc/NetworkManager/dispatcher.d/50-facter")
#BASH_VERSINFO=([0]="4" [1]="3" [2]="39" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu")
#BASH_VERSION='4.3.39(1)-release'
#CONNECTION_ID=vpn0
#CONNECTION_UUID=96a81e96-133b-4bcc-bf66-20cf39e8a4d0
#DEVICE_IFACE=vpn0
#DEVICE_IP_IFACE=vpn0
#DIRSTACK=()
#EUID=0
#FACTER_FILE=/etc/facter/facts.d/if_vpn0.yaml
#GROUPS=()
#HOSTNAME=myhost.example.org
#HOSTTYPE=x86_64
#IFS=' 	
#'
#IP4_ADDRESS_0='1.2.3.4/24 0.0.0.0'
#IP4_GATEWAY=0.0.0.0
#IP4_NUM_ADDRESSES=1
#IP4_NUM_ROUTES=0
#IP6_GATEWAY=::
#MACHTYPE=x86_64-redhat-linux-gnu
#OPTERR=1
#OPTIND=1
#OSTYPE=linux-gnu
#PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
#PIPESTATUS=([0]="0")
#POSIXLY_CORRECT=y
#PPID=22353
#PS4='+ '
#PWD=/
#SERVICE=50-facter
#SHELL=/bin/bash
#SHELLOPTS=braceexpand:hashall:interactive-comments:posix
#SHLVL=1
#TERM=dumb
#UID=0
#_=echo

Notice that neither VPN_IP4_NAMESERVERS nor IP4_NAMESERVERS is set. On Fedora 20, VPN_IP4_NAMESERVERS was set.

Again, the problem is *NOT* that the VPN server isn't communicating the nameservers: it is, because NetworkManager updates /etc/resolv.conf with the nameservers. The problem is that NetworkManager is no longer exporting the nameservers into the environment for dispatcher scripts.
Comment 1 James Ralston 2015-08-15 17:44:11 EDT
Correction: I'm not sure whether NetworkManager was setting VPN_IP4_NAMESERVERS or IP4_NAMESERVERS, as the code in my dispatcher script checks for both.

But it was definitely one of those two.
Comment 2 David Woodhouse 2015-08-16 02:49:52 EDT
(In reply to James Ralston from comment #0)
> Again, the problem is *NOT* that the VPN server isn't communicating the
> nameservers: it is, because NetworkManager updates /etc/resolv.conf with the
> nameservers. The problem is that NetworkManager is no longer exporting the
> nameservers into the environment for dispatcher scripts.

That would be a NM bug then, rather then NM-openconnect.
Comment 3 Jirka Klimes 2015-08-18 09:57:23 EDT
I have tested now on Fedora 22 (with vpnc) and I can see VPN_IP4_NAMESERVERS in the dispatcher output.

Maybe you looked into the output for "up" action instead of "vpn-up" action.

/etc/NetworkManager/dispatcher.d/99-my-test
--8<------------
#!/bin/bash
interface=$1
action=$2

echo "$interface $action" >> /tmp/nm-disp-output
echo "===============" >> /tmp/nm-disp-output
env >> /tmp/nm-disp-output
echo "" >> /tmp/nm-disp-output
-->8------------
Comment 4 Fedora Admin XMLRPC Client 2015-08-18 11:00:33 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 James Ralston 2015-09-18 14:15:06 EDT
Jirka is correct in comment 3: I was looking at the "up" action instead of the "vpn-up" action.

I was fooled by the fact that until recently, most of the VPN_* variables were set in both "up" and "vpn-up". Now, most of them are only set in "vpn-up".

(While this is arguably more correct behavior, it was confusing to anyone who was unintentionally relying on the old behavior, because this change wasn't announced.)

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