Re: NetworkManager permissions
Sounds good, ive now reported the bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1176042 Thank you for your help Dan. On Thu, Dec 18, 2014 at 5:32 PM, Dan Williams d...@redhat.com wrote: On Thu, 2014-12-18 at 11:44 +0100, Peter Magnusson wrote: Hi Dan, Thank you for the reply! This sounds like a good solution to me, unfortunately we are indeed using Gnome Shell UI so that would cause a problem. So what you are saying is that right now there is no way to achieve this while using gnome shell ? There might be something we can do in NM itself though, given the way the shell and most other clients create new connections. But either way, best thing to do would be to file a bug at http://bugzilla.redhat.com against RHEL7 and assign to the NetworkManager component so it doesn't get lost. Does that sound OK? Thanks! Dan On Wed, Dec 17, 2014 at 4:53 PM, Dan Williams d...@redhat.com wrote: 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.
Dan Haven't heard back so not sure if you've seen my messages over the last couple of days. Do you want me to file this as a bugzilla? Regards Tony On 18 December 2014 at 13:19, Another Sillyname anothersn...@googlemail.com wrote: Dan I've responded with a couple of log attachment zips direct to your account, if you don't see them they may be in your spamtrap. Regards Tony On 17 December 2014 at 15:56, Dan Williams d...@redhat.com wrote: 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
ANN: NetworkManager 1.0.0 released!
Hi, I'm very happy to announce that after more than 10 years of development and 10 years of making the world a better place, NetworkManager 1.0 has been released! This release brings a more modern GObject-based client library, many bug fixes and updated translations, more flexible routing, hugely improved nmcli with password support, improved nmtui, a light-weight internal DHCP client, configure and quit mode, Bluetooth DUN support with Bluez5, VPN connection persistence, improved cooperation with external tools, expanded manpages and documentation, WWAN IPv6 support, and much much more. Full release notes are below... A huge thanks to everyone who contributed to this release (and there are many of you!), and to everyone who's been a part of the NetworkManager project over the past 10 years. Let's make the next 10 even better! Grab NetworkManager, the applet/editor, and the VPN plugins here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.0.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network-manager-applet-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.0/NetworkManager-openconnect-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openswan/1.0/NetworkManager-openswan-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.0/NetworkManager-openvpn-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.0/NetworkManager-pptp-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.0/NetworkManager-vpnc-1.0.0.tar.xz Cheers, Dan - This is a new stable release of NetworkManager. Notable changes include the following features and fixes. * New client library: libnm A new GObject-based client library, libnm, has been written, merging the existing libnm-util and libnm-glib and simplifying the API while using modern GLib APIs (such as using GDBus rather than dbus-glib, and providing gio-style asynchronous operations). IP addresses, routes, hardware addresses, and other properties are now represented as strings rather than binary types, allowing much simplified code for most languages including C, Python, and Javascript. For more information see https://wiki.gnome.org/Projects/NetworkManager/libnm libnm-util and libnm-glib are still available for backward compatibility, and the D-Bus interface remains fully compatible with 0.9.10. * New internal DHCP client A faster, lighter-weight internal DHCP client based on code from systemd-networkd has been added, and may be selected with the dhcp=internal option in NetworkManager.conf or in a configuration snippet. (Note that it does not yet support as many DHCP options as dhclient, and does not support DHCPv6.) * Configure interfaces and then quit mode A new 'configure-and-quit=yes' option has been added for environments with less dynamic network configuration. With this option set in NetworkManager.conf, available interfaces will be configured and NetworkManager will quit, spawning small nm-iface-helper processes for each interface that uses DHCP and/or IPv6, to preserve DHCP leases and IPv6 address lifetimes. No helper will be spawned for purely static IP configurations. * Improved cooperation with non-NetworkManager network configuration NetworkManager now does a better job of not interfering with devices which it did not create itself. (In particular, it no longer sets IFF_UP on externally-created devices.) * Improvements to nmcli nmcli now supports password requests and PolicyKit authorizations, allowing fully command-line based activation of connections that require passwords. (Note that activation of VPNs is not yet supported, because of the additional complexity of VPN password properties.) 'nmcli dev connect interface' will now automatically create a connection if none exists. This command is now a more useful shortcut to activate a network interface by device name. 'nmcli dev delete interface' lets you delete unused software devices (bridge, bond, team, etc). * IPv6 configuration improvements IPv6 router advertisement MTUs are now respected WWAN connections now support IPv6 if the modem and provider support IPv6. When running on 3.17 and later kernels, NetworkManager will handle IPv6 link-local address assignment to ensure that IPv6 connectivity is not enabled on interfaces that are up but not active. This means that until an IPv6-enabled connection is started, the interface will have no IPv6 link-local address. (If external tools add IPv6 addresses to the interface, NetworkManager will immediately create the IPv6 link-local address to ensure compliance with RFCs. IPv6 interface configuration that exists before NetworkManager starts is left unchanged.) Manually-configured static IPv6 configuration is kept even if automatic configuration fails. Previously, a connection configured for automatic IPv6 addressing (SLAAC) with additional static
Re: ANN: NetworkManager 1.0.0 released!
Quoting Dan Williams d...@redhat.com: I'm very happy to announce that after more than 10 years of development and 10 years of making the world a better place, NetworkManager 1.0 has been released! Congratulations and many thanks for this wonderful software! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
