GNOME.org
 

Re: NetworkManager behavior answers not found in docs

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

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]