Re: NetworkManager behavior answers not found in docs

[Thomas HUMMEL <thomas hummel pasteur fr>]

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 ?


> 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) ?

> 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 ?


>    - 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 ?



> "Autoconnect" prefers profiles which
> were active last

Same remark here


> 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)

Also, that profile autocreation works (when its not forbidden by 
no-auto-default for instance) only on managed devices

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 ?

Or maybe nmcli con up or device connect would create a profile and apply 
it but the device would still be unmanaged ?

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 ?
I mean the persistent profile would make NM "manage" the device even if 
not really set to managed yes ?


> > 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)

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) ?

So shouldn't NM have auto created a temp profile and auto connected it 
for my eth1 ?


> 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 ?

> > 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 ?

> 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" ?

> , 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 ;-)

Thank you

--
Thomas Hummel