Re: Change of route metric are not well propagated for default route
On Wed, 2018-07-18 at 23:18 +0200, Thomas Haller via networkmanager- list wrote: > > In 1.8, NetworkManager treated the default-route specially, and then > reapply (`nmcli device modify`) worked correctly to change the metric > of the default-route. > > With 1.10, NetworkManager's handling of routes was significantly > reworked. I actually would expect, that the bug was introduced > already > in 1.10.0, as side effect of the rework. Since you say, it worked in > 1.10, I am a bit surprised. > Anyway, clearly there is a misbehavior in 1.12.0. Ah, seems the issue was introduced by commit [1], which is 1.12.0. So, it makes sense that you say, > This works perfectly fine with NetworkManager 1.10.10 and I ended up > with a routing table like this one: [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=f4cbed3d4ff4e91e83f42c63b3602efa014ed72f best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Change of route metric are not well propagated for default route
On Wed, 2018-07-18 at 07:30 +, Frederic Martinsons wrote: > Hello guys, > > I would like to change route metric on a device without reactivated > its connection profile. For example, with nmcli, to change the metric > from 100 to 800, I do the following: > > nmcli device modify eth0 ipv4.route-metric 800 > > This works perfectly fine with NetworkManager 1.10.10 and I ended > up with a routing table like this one: > > default via 10.30.1.254 dev eth0 proto static metric 800 > 10.30.0.0/16 dev eth0 proto kernel scope link src 10.30.38.49 metric > 800 > > But this doesn't work with NetworkManager 1.12.0 and only the route > metric to reach subnet is changed (the one to reach the gateway is > not changed): > > default via 10.30.1.254 dev eth0 proto static metric 100 > 10.30.0.0/16 dev eth0 proto kernel scope link src 10.30.38.60 metric > 800 > > Moreover, always with NM 1.12, if I configured my device with a > manual IP (ip4.method=manual), the metric change is also correctly > propagated to all route that implies the device. > > I've raised the logging level of NetworkManager but I did'nt manage > to know why the default route is not changed when dhcp setup is > involved. I join two log files (one in dhcp and one in manual) to > emphasize the moment I execute the nmcli command. > > Can you guys please help me or give me some advice to solve this ? > > Note: I use internal dhcp client in the NetworkManager conf. Hi, I think what you see here is a bug. It has the effect, that nmcli device modify "$IF" ipv4.route-metric "$VALUE" and nmcli connection modify "$PROFILE" ipv4.route-metric "$VALUE" nmcli device reapply "$IF" don't work correctly to change the default-route. I think this issue is also tracked as [1]. In 1.8, NetworkManager treated the default-route specially, and then reapply (`nmcli device modify`) worked correctly to change the metric of the default-route. With 1.10, NetworkManager's handling of routes was significantly reworked. I actually would expect, that the bug was introduced already in 1.10.0, as side effect of the rework. Since you say, it worked in 1.10, I am a bit surprised. Anyway, clearly there is a misbehavior in 1.12.0. TODO. Sorry for the incovenience. best, Thomas [1] https://bugzilla.redhat.com/show_bug.cgi?id=1528071#c4 signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Change of route metric are not well propagated for default route
Hello guys, I would like to change route metric on a device without reactivated its connection profile. For example, with nmcli, to change the metric from 100 to 800, I do the following: nmcli device modify eth0 ipv4.route-metric 800 This works perfectly fine with NetworkManager 1.10.10 and I ended up with a routing table like this one: default via 10.30.1.254 dev eth0 proto static metric 800 10.30.0.0/16 dev eth0 proto kernel scope link src 10.30.38.49 metric 800 But this doesn't work with NetworkManager 1.12.0 and only the route metric to reach subnet is changed (the one to reach the gateway is not changed): default via 10.30.1.254 dev eth0 proto static metric 100 10.30.0.0/16 dev eth0 proto kernel scope link src 10.30.38.60 metric 800 Moreover, always with NM 1.12, if I configured my device with a manual IP (ip4.method=manual), the metric change is also correctly propagated to all route that implies the device. I've raised the logging level of NetworkManager but I did'nt manage to know why the default route is not changed when dhcp setup is involved. I join two log files (one in dhcp and one in manual) to emphasize the moment I execute the nmcli command. Can you guys please help me or give me some advice to solve this ? Note: I use internal dhcp client in the NetworkManager conf. dhcp_setup Description: dhcp_setup manual_addr_setup Description: manual_addr_setup ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
How to use PKCS#11 with nm-applet?
Hello everyone, I am running the following configuration: - Ubuntu 18.04 Bionic - network-manager-gnome_1.8.10-2ubuntu1_amd64 - network-manager 1.8.10 I have seen that there is a commit, which "adds PKCS#11 login dialog" (https://github.com/GNOME/network-manager-applet/commit/0c54ce2670dbb942f0fd7cc72f6cd4ef841ca916). According to this commit, the versions built after 1.7.1-dev (including my version 1.8.10) should include the changes made here. However, I am not able to enter a PKCS#11 URI in the Wi-Fi connection dialog (WPA & WPA2 Enterprise; TLS).It only shows me the file picker for the CA certificate, user certificate and private key. What am I doing wrong? Kind regards / MfG Jan Bissinger CI/CBW ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: defaulting `rc_manager=symlink` to creating a symlink?
On Wed, 2018-07-18 at 05:25 -0400, Colin Walters wrote: > > On Wed, Jul 18, 2018, at 4:20 AM, Thomas Haller wrote: > > On Tue, 2018-07-17 at 22:32 -0400, Colin Walters wrote: > > > See discussion in https://github.com/projectatomic/rpm-ostree/pul > > > l/14 > > > 64 > > > > > > Is there a reason that the `symlink` mode doesn't default to > > > creating > > > a symlink? It'd help for mounting `/etc` read-only. > > > > Hi, > > > > Writing /etc/resolv.conf as symlink, is an action reserved to the > > administrator. > > Right, but I want to do it by default for > CoreOS/Silverblue. Remember > here we're talking about the case where the file doesn't exist > at all. > > So we either change NM upstream, change the Fedora package, or do: > https://github.com/projectatomic/rpm-ostree/pull/1464 > > OK, I just read the linked bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1367551 > and I disagree with the rationale but whatever. No point fighting > to change the default back globally I guess. > > Also particularly because at least for single-node systems we > should be using a local caching resolver anyways. > > > Why is there a problem with "mounting `/etc` read-only"? > > Just try it, add `/etc /etc none bind,ro 0 0` into your `/etc/fstab`, > then e.g.: > ``` > rm /etc/resolv.conf > systemctl stop NetworkManager > mount /etc > systemctl start NetworkManager > ``` > > As expected you won't have an /etc/resolv.conf since NM gets EPERM, > which is what's desired here - /etc should be immutable. > > Anyways I'll argue to merge the rpm-ostree patch based on this > discussion - it will create a new distinction between "classic" and > "ostree-based" > systems, so if anyone wants to use e.g. networkd on e.g. > CoreOS/Silverblue they'll have to also run `rm` (how painful!). Hi, You anyway have to configure /etc with all the settings you want. If somebody wants to run networkd, the person needs to setup /etc in a particular way. At least, creating symlinks like /etc/systemd/system/multi-user.target.wants/systemd-networkd.service, etc. Why is it a problem, to also create the /etc/resolv.conf symlink, accordingly? If the patch achieves setting up the symlink the most elegant way, it seem right -- though I thought configuring systemd-tmpfiles would be more elegant, and generic. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: defaulting `rc_manager=symlink` to creating a symlink?
On Wed, Jul 18, 2018, at 4:20 AM, Thomas Haller wrote: > On Tue, 2018-07-17 at 22:32 -0400, Colin Walters wrote: > > See discussion in https://github.com/projectatomic/rpm-ostree/pull/14 > > 64 > > > > Is there a reason that the `symlink` mode doesn't default to creating > > a symlink? It'd help for mounting `/etc` read-only. > > Hi, > > Writing /etc/resolv.conf as symlink, is an action reserved to the > administrator. Right, but I want to do it by default for CoreOS/Silverblue. Remember here we're talking about the case where the file doesn't exist at all. So we either change NM upstream, change the Fedora package, or do: https://github.com/projectatomic/rpm-ostree/pull/1464 OK, I just read the linked bug: https://bugzilla.redhat.com/show_bug.cgi?id=1367551 and I disagree with the rationale but whatever. No point fighting to change the default back globally I guess. Also particularly because at least for single-node systems we should be using a local caching resolver anyways. > Why is there a problem with "mounting `/etc` read-only"? Just try it, add `/etc /etc none bind,ro 0 0` into your `/etc/fstab`, then e.g.: ``` rm /etc/resolv.conf systemctl stop NetworkManager mount /etc systemctl start NetworkManager ``` As expected you won't have an /etc/resolv.conf since NM gets EPERM, which is what's desired here - /etc should be immutable. Anyways I'll argue to merge the rpm-ostree patch based on this discussion - it will create a new distinction between "classic" and "ostree-based" systems, so if anyone wants to use e.g. networkd on e.g. CoreOS/Silverblue they'll have to also run `rm` (how painful!). ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: defaulting `rc_manager=symlink` to creating a symlink?
On Tue, 2018-07-17 at 22:32 -0400, Colin Walters wrote: > See discussion in https://github.com/projectatomic/rpm-ostree/pull/14 > 64 > > Is there a reason that the `symlink` mode doesn't default to creating > a symlink? It'd help for mounting `/etc` read-only. Hi, Writing /etc/resolv.conf as symlink, is an action reserved to the administrator. The symlink is intent/configuration of the administrator that /etc/resolv.conf is managed by a particular component. NetworkManager should not write such intent, it's reserved to the admin. See in particular the commit message of [1] and bug [2]. According to NetworkManager manual [4]: 1) if /etc/resolv.conf is already a symlink, the symlink will not be changed. - with "rc-manager=file", NM would follow the symlink, and write the file it points to. - with "rc-manager=symlink", NM would not modify the symlink at all. I older versions, there were cases, where this was not true (see [1], [3]). 2) NetworkManager will never create /etc/resolv.conf to be a symlink. In older versions, that was not the always the case [1]. 3) Noteable exception: with rc-manager=symlink and /etc/resolv.conf being a symlink to "/var/run/NetworkManager/resolv.conf", then NetworkManager will replace the symlink with a symlink to the same file (to trigger an inotify notification). Why is there a problem with "mounting `/etc` read-only"? Note that behavior of NetworkManager was slightly refined in recent versions. So, depending on which version of NetworkManager, the optimal answer might differ slightly. On recent versions, just set rc- manager=symlink, and symlink /etc/resolv.conf to "../var/run/NetworkManager/resolv.conf" (beware that it does not literally point to "/var/run/NetworkManager/resolv.conf"). [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=15177a34be297654086005f2d796e6a4c6a1b918 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1367551 [3] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=644aa42f68d9d6f30144dba243f95690226a777c [4] https://developer.gnome.org/NetworkManager/unstable/NetworkManager.conf.html best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
