Notification disjoint - VPN now failed, notifications showing still connected.
I have setup a VPN on a Laptop using Fedora 21 x86_64. The VPN works fine however the gnome notifications are not reflecting the true state of the VPN. In Network Settings you can connect to XXXVPN using the ON/OFF switch. If you then do a 'nmcli connections show --active' you will get the correct information regarding the VPN and also the tun will show active on a separate line. ifconfig reports the 'hard' settings for the nic together with the relevant VPN settings. I had noticed on a couple of occasions the VPN had dropped however the gnome settings were still showing active. So if the VPN gets dropped (NOT manually disconnected) Gnome settings will still show the VPN as connected. nmcli connections show --active will still show the VPN as active, however the 'tun' line has now disappeared confirming the VPN is down. ifconfig shows the 'hard' settings for the nic but no entry for the VPN. This means there's a disjoint in what is being reported via Gnome/NetworkManager and the actuality of the status of the VPN. In effect there would appear to be a need to 'actively poll' the tun to ensure the VPN is still active and if the tun fails NetworkManager needs to be updated accordingly. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager permissions
On Thu, 2014-11-27 at 11:59 +0100, Peter Magnusson wrote: > Im having some problems with permissions on NetworkManager. We are in > the process of migrating our clients from RHEL 6.6 to RHEL 7. > The clients connect to our wireless network using eap-tls, we provide > the configuration,certificate and keys for this from our central > configurationserver so that the connection is transparent to the user. > > In RHEL6.6 the password for the privatekey(pkcs12 used for > authentication) was not visible to the users only to administrators. > This was achieved by setting the connection as "system wide" in which > case the configfile was stored under /etc/sysconfig/network-scripts > and only accessible by root. > > In RHEL7 and NM version 0.9.9.1-28.git20140326.4dba720.el7_0.2 (lbuild > from git) we can still limit the permissions to NM config using polkit > but when doing this we also limit the possiblity for the user to add > new wifi-networks. > > So what i would like to achieve is to limit access to existing > connections (or connections not added by user) but i still want the > users to be able to add new wificonnections. Is this possible ? I looked into this yesterday, and I think the way forward here is to restrict the user's permissions for "modify.system", but allow them permissions for "modify.own" (own == self, not possession). This will prevent the user from being able to change any connection that is in /etc and does not have specific permissions. But it allows the user to create new connections that are restricted to that user only. There's one catch though; if you're using the GNOME Shell UI on RHEL 7.0 it doesn't set the necessary flags to create these user-specific connections when the modify.system permission is denied. We can work on fixing that though. Do you think this solution would work for you? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Notification disjoint - VPN now failed, notifications showing still connected.
On Wed, 2014-12-17 at 14:45 +, Another Sillyname wrote: > I have setup a VPN on a Laptop using Fedora 21 x86_64. > > The VPN works fine however the gnome notifications are not reflecting > the true state of the VPN. > > In Network Settings you can connect to XXXVPN using the ON/OFF switch. > > If you then do a 'nmcli connections show --active' you will get the > correct information regarding the VPN and also the tun will show > active on a separate line. > > ifconfig reports the 'hard' settings for the nic together with the > relevant VPN settings. > > I had noticed on a couple of occasions the VPN had dropped however the > gnome settings were still showing active. > > So if the VPN gets dropped (NOT manually disconnected) > > Gnome settings will still show the VPN as connected. > > nmcli connections show --active > > will still show the VPN as active, however the 'tun' line has now > disappeared confirming the VPN is down. If this happens, then it seems that the VPN you're using isn't notifying the NM VPN plugin about the failure, or there's a bug in the plugin. But we'll need some logs for that. Based on what you describe, I think this VPN drop thing is a bug in NM or the VPN plugin. Can you grab some /var/log/messages about that? Also very useful is to run the specific VPN plugin with "--debug --persist" which will dump a ton of information that we can use to figure it out. eg: /usr/libexec/nm-vpnc-service --debug --persist /usr/libexec/nm-openvpn-service --debug --persist Dan > ifconfig shows the 'hard' settings for the nic but no entry for the VPN. > > This means there's a disjoint in what is being reported via > Gnome/NetworkManager and the actuality of the status of the VPN. > > In effect there would appear to be a need to 'actively poll' the tun > to ensure the VPN is still active and if the tun fails NetworkManager > needs to be updated accordingly. > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The short road to 1.0 (ANN: 0.995 released)
On Fri, 2014-12-12 at 16:05 -0600, Dan Williams wrote: > Hi everyone! > > The 1.0 release is imminent. We've been cleaning out the 1.0 tracker > bug [1] for more than a month. With your help we'll get there next > week! A holiday present for everyone! We're getting very close to 1.0, so this is last call for any showstopper bugs that you can find. Thanks! Dan > The 1.0 release will be huge step forward in functionality, cooperation, > client APIs, configurable routing, nmcli/nmtui, DHCP, IPv6, reduced > footprint, and tons more. It just doesn't stop. I'm looking forward to > 1.0 and I hope you are too! > > I've branched git master for 1.0 and released 0.995/1.0-rc1 tarballs. > Hammer on these so we can make 1.0 as solid as ever. Please file bugs > at bugzilla.gnome.org, or drop by #nm on freenode. Let's get this done. > > http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.995/NetworkManager-0.995.0.0.tar.xz > http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.995/network-manager-applet-0.995.0.0.tar.xz > http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openconnect/0.995/NetworkManager-openconnect-0.995.0.0.tar.xz > http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openswan/0.995/NetworkManager-openswan-0.995.0.0.tar.xz > http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openvpn/0.995/NetworkManager-openvpn-0.995.0.0.tar.xz > http://ftp.gnome.org/pub/gnome/sources/NetworkManager-pptp/0.995/NetworkManager-pptp-0.995.0.0.tar.xz > http://ftp.gnome.org/pub/gnome/sources/NetworkManager-vpnc/0.995/NetworkManager-vpnc-0.995.0.0.tar.xz > > Thanks, > Dan > > [1] https://bugzilla.gnome.org/showdependencytree.cgi?id=682947 > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
