On Wed, 2018-10-17 at 19:34 +0200, Thomas HUMMEL wrote: > Hello, > > thanks for your answers. Very useful ! > Much content to digest ;-) > > > you can ignore > > initscripts entirely. > > I know, I was just curious about how they used D-Bus and nmcli and > how > compatibility worked both ways (network-scripts <-> NM) > > > > There is little difference > > > > - `nmcli connection up "$PROFILE"` will find a suitable device > > automatically. > > - `nmcli device connect "$DEVICE"` will find a suitable > > connection > > automatically. Note this may create a new profile (see later). > > - `nmcli connection up "$PROFILE" ifname "$DEVICE" explicitly > > selects > > both the profile and the device. > > ok > > > As the profile contains the necessary settings for what to do with > > the > > device, you cannot ~configure~ a device without a profile. > > ok > > > re-activating can be done via `nmcli connection up` (or similar) > > and > > goes through a full re-activation cycle (and temporarily > > disconnects > > you). A more graceful way is `nmcli device reapply "$DEVICE"` which > > takes the changes and configured on the device. > > > > `nmcli device reapply` may also be useful if there are no actual > > changes in the device. For example, it will re-start DHCP and > > restore > > IP address configuration (if it was modified, for example via > > iproute). > > > > > > You see, when a profile is activated on a device, the original > > settings > > were internally copied and those are "applied". And "nmcli device > > reapply" just updates the "applied" clone to be the current profile > > and > > does the changes. > > ok, so those details apart, > > - profile is applied or re-applied to a device > - connection is up-ed or activated > - profile is activated > - device is connected > > > are kind of synonymous ?
Yes. > > Usually, NetworkManager (the daemon) does not automatically create > > connection profiles > > > But when it does (as in your cases), is it always only in RAM (unless > we > then save the profile to disk of course) ? Yes. But when you modify this profile, it usually gets persisted to disk. Except case 4). But there it's not really NetworkManager who creates the profile but nmcli/nm-applet. Such profiles to get persisted. > > Regarding "autoconnect", that is a property of the connection > > profile > > itself. > > So in a way, when a profile is autocreated and activated, it is > first > created with this property which make it then immediatly > (auto)connect, > correct ? Not necessarily. When NetworkManager creates a bluetooth pan profile (case 1)), this one will not be connected right away. Such a profile also has "connection.autoconnect=no". For the auto-default profiles (case 2, "Wired Connection #"), the purpose is to create a profile and activate it right away. Indeed, such a generated profile has "connection.autoconnect=yes". But it would work the same (and connect the profile) also with "connection.autoconnect=no". NM here (auto)creates the profile and goes ahead to activate it. I wouldn't call this behavior "autoconnect", but yes, kind of. > > - per-device: nmcli device set $DEVICE autoconnect no > > this confuses me since we just said autoconnection was a property of > a > profile and this command deals with a device ? The profile has a "connection.autoconnect" property. If it's "no", the profile never autoconnects. Period. But there also needs to be a device which is currently in a state where it would like to autoconnect a profile. With `nmcli device set "$DEVICE" autoconnect no" you can set that. for example, `nmcli device disconnect "$DEVICE"` will block autoconnect on the device. It would be pretty annoying, if you disconnect the device and immediatley some profile autoconnects again. > > "Autoconnect" prefers profiles which > > were active last > > Same remark here When a device wants to autoconnect a profile, there might be multiple profiles which are compatible candidtes. Then, the one is chosen with the best "connection.autoconnect-priority" or as last, the timestamp when the profile was activate the last time. > > > > If a device is unmanaged, NetworkManager does nothing with it. It > > won't > > autocreate a profile for it, and it won't autoactivate anything > > > Depending on the reasons why it's unmanaged, you still can let > > NetworkManager take over, either via > > > > nmcli device set $DEVICE managed yes > > > > or simply `nmcli con up` or `nmcli device connect`. > > My understanding is that a device is managed by default unless > explicitly set to unmanaged (via one of the several ways you > described) yes > Also, that profile autocreation works (when its not forbidden by > no-auto-default for instance) only on managed devices yes > So in your above example I don't understand how nmcli con up alone > or > nmcli device connect alone would actually create the profile without > the > device set managed yes first ? `nmcli con up` never creates a profile. `nmcli device connect` usually does not create a profile either (unless, no suitable profile exists). The `nmcli con up` or `nmcli device connect` commands are clear indications that the user wants NetworkManager to now manage this device. It doesn't require the user to first issue nmcli device set $DEVICE managed yes because it's clear(?) that this is what the user wants. Actually, there was a change in this regard recently: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0cb8bed23c22b01cce38e03d14ce29e5f73c28d2 > Or maybe nmcli con up or device connect would create a profile and > apply > it but the device would still be unmanaged ? No. unmanaged devices are not touched by NM. First the device gets set to "managed". Then a profile may be created, then the profile gets actiated. > Also, since adding a profile creates a persistent profile (provided > the > save option is not set to false), is there a point to set a device > to > managed when a persistent profile for it exists ? Sure. Unmanaged devices are not very useful, as far as NetworkManager is concerned. > I mean the persistent profile would make NM "manage" the device even > if > not really set to managed yes ? No it wouldn't. Unless you issue a client command like `nmcli con up`. Especially, nothing would autoconnect, and now profiles are automatically created by NetworkManager (case 4 doesn't count). > > > Let's take the following use case as an example : > > > > > > - a host with 2 ethernet devices : eth0 and eth1 > > > > > > - eth0 has a network-script like connection file > > > (/etc/sysconfig/network-scripts/ifcfg-eth0) and is NetworkManager > > > managed (either by default because no "NM_CONTROLLED=no" is > > > stated > > > or > > > explicitly with "NM_CONTROLLED=yes") > > > - eth1 has no connection file (neither ifcfg-rh style nor keyfile > > > style, > > > that is nothing for eth1 neither in /etc/sysconfig/network- > > > scripts > > > nor > > > in /etc/NetworkManager/system-connections) > > > > > > - no NM_UNMANAGED=1 in udev > > > > > > test 1 : > > > > > > -> after boot, as expected eth0 is configured and up, nmcli shows > > > a > > > connection for it but eth1 has no connection. It has to be > > > manually > > > connected for that matter. If done, NetworkManager seems to auto > > > magically CREATE the connection > > > > I guess, on CentOS you have a package NetworkManager-config-server, > > which installs a file /usr/lib/NetworkManager/conf.d/00-server.conf > > That's not the case for me : I don't see any no-auto-default > anywhere > which could match eth1 or any at all (I only have 10-slaves- > order.conf > in conf.d) Maybe NM created such an "auto-default" (named "Wired Connection #"), but then you deleted it? It wouldn't create it again, see file /var/lib/NetworkManager/no-auto-default.state. > By default, without any profiles files, would be my eth1 device > managed > or unmanaged (I would guess managed since I'm not in any case you > describe where a device could be unmanaged) ? Whether it's managed does not depend on the presence of connection profiles. Possibly it would be managed, as you see in `nmcli device` output. Everything where the state is not "unmanaged", is managed :) Well, if you have an ifcfg-file that specifies NM_CONTROLLED=no, then the device would be unmanaged. But such a ifcfg isn't a real "connection" (you wouldn't see it in `nmcli connection`). Btw, note that if you configure the device as unmanaged via NM_CONTROLLED=no in ifcfg, then the device cannot be set to managed. This way of unmanaging a device is definite, nmcli device set "$DEVICE" managed yes nmcli device connect "$DEVICE" will both fail. Not every device can be set to managed. For example, "lo" is never manageble. But what I said above is still the case, nmcli device connect "$DEVICE" safes you from explict `nmcli device set $DEVICE managed yes`. It doesn't mean, that this will work with every device. > So shouldn't NM have auto created a temp profile and auto connected > it > for my eth1 ? Possibly not. Is the MAC address in "/var/lib/NetworkManager/no-auto- default.state" ? > > man nmcli: > > > > connect ifname > > Connect the device. NetworkManager will try to find a > > suitable connection that will be activated. It will also consider > > connections that are not set to auto > > connect. > > > > ok. It's not described. That's a documentation bug. > > So you confirm that unless a device in explictly unmanaged, a device > connect would not only look for declared profiles but would also if > no > suitable profile is found create a temp profile creation and activate > it ? Yes. First it tries to find a profile to activate. If there is none, it would create one. But not a "temp" profile, it's persisted. And it's not "automatically" created by NetworkManager daemon, but by you (issuing the nmcli command). Actually, first it might even need to set the device as managed, if it was unmanaged before... > > > test 2 under the same conditions : > > > > > > - reboot of the host > > > - only one connection (eth0) as expected > > > - create the foobar connection like this > > > > > > nmcli connection add type ethernet con-name foobar ifname > > > eth1 > > > > > > -> as expected a ifcgh-rh format connection file has been created > > > in > > > /etc/sysconfig/network-scripts/ifcfg-foobar and nmcli shows 2 > > > connections : eth0 and foobar > > > > > > - manually delete foobar connection file : rm > > > /etc/sysconfig/network-scripts/ifcfg-foobar > > > > > > -> as expected nmcli still shows foobar connection > > > > > > - reload connection files via nmcli connection reload > > > > > > -> as expected nmcli only shows eth0 connection > > > > > > So far, everything seems to work as expected BUT : > > > > > > if instead of nmcli connection reload we RESTART (not reload, but > > > restart) NetworkManager via systemctl restart NetworkManager, > > > ANOTHER > > > (different UUID and eth1 instead of foobar for the name) > > > connection > > > is > > > auto created and auto activated > > > > Yes, that is case 3). NM (re) starts and sees the the device is > > already > > configured. > > you mean via the /run state dir we talked about ? Partly. NM sees that the device is configured because it has an IP address. In the state file it says that the connection with UUID XYZ should be active on it, but no such connection exists anymore. At that point, NM does not know what configuration (profile) should be used, and it assumes the user externally handles it. Then, it generates this in- memory connection (named "eth1") and pretends that it is active. But it does not do anything with it! This is a problem, your DHCP addresses will expire... > > It has no configuration for that device > > You mean no more persistent profile ? > > Those 2 above facts seems contradictory to me : if the device is > "already configured" doesn't it mean that it has some in RAM profile > applied ? Then NM hasn' "no configuration for that device" ? The device is configured with IP addresses in kernel. As you see with `ip addr` and `ip route`. NM sees something is going on there... but the configuration and original intent that lead to this configuration are unknown to NetworkManager (in this example, because you deleted files under NetworkManager's feet and it can no longer find the profile that it previously activated there). In general: - you usually don't need to restart NetworkManager. If you think you do, you might do something wrong. Of course, restart during package update or just for the fun of it, are good reasons. Restart is supposed to work well and as non-disruptive as possible. - If you restart, avoid confusing NetworkManager, like deleting files of NetworkManager without telling NM. - If you confuse NM, be prepared to manually fix the situation after starting NM again. That may simply mean to explicitly `nmcli connection up` the right profile afterwards, to get rid of this generated (case 3) connection. > > , so it assumes > > somebody else was configuring it and does not touch it. This eth0 > > device is no longer managed by NetworkManager. For example, it does > > no > > DHCP and your addresses will time out. > > Sorry for the confusion. I'm sure that when sorted out, those > concepts > are simple ;-) I hope this helped :) 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
