Bug 1654098 - [RFE] why `nmcli d set eth0 autoconnect no managed no` not effect in system reboot
Summary: [RFE] why `nmcli d set eth0 autoconnect no managed no` not effect in system r...
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Francesco Giudici
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-28 03:47 UTC by fzxiaomange
Modified: 2018-11-29 13:46 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

Description fzxiaomange 2018-11-28 03:47:24 UTC
Description of problem:
When I exec `nmcli d set eth0 autoconnect no managed no`, I wish it will effect permanent. But after the reboot, the device state convert back into autoconnect yes managed yes, include the connection would be auto effect

Version-Release number of selected component (if applicable):
rhel8.0 beta

Steps to Reproduce:
1.nmcli d set eth0 autoconnect no managed no
2.reboot
3.nmcli d; nmcli c

Actual results:
After the reboot, the `autoconnect no managed no` convert back into `autoconnect yes managed yes`

Expected results:
After the reboot, it still be `autoconnect no managed no`

Comment 1 Thomas Haller 2018-11-28 07:01:57 UTC
It's a missing feature.


Also, it's not exactly clear how such configuration could be persisted. That is, because networking devices don't have a stable identifier that is guaranteed to be the same after reboot. For example, nowadays with persistent interface naming, the unmanaged state could be stored per-interface name, but it's not clear that this is the correct behaviour in all use-cases. Maybe it should tie the persistent setting to the MAC address? What if you change the hardware or plug it into a different location? Also, how to ever clean-up such persistent data if the device actually goes away (and how to know, that the device is really gone).

Of course, a similar problem already exists for

  - lease files (/var/lib/NetworkManager/*lease)
  - no-auto-default setting (/var/lib/NetworkManager/no-auto-default.state)
  - and for profiles' connection timestamps (/var/lib/NetworkManager/timestamps)

We should improve persisting such per-device configuration (or per-profile configuration), in particular with respect 

  - unify the implementation of such persistent settings
  - device a scheme how the per-device configuration matches to a device
  - how to garbage collect old configuration for devices that are gone.


Until this feature is added, you can configured devices persistently by editing configuration files or udev rules.

Comment 2 fzxiaomange 2018-11-29 13:46:18 UTC
(In reply to Thomas Haller from comment #1)
> It's a missing feature.
> 
> 
> Also, it's not exactly clear how such configuration could be persisted. That
> is, because networking devices don't have a stable identifier that is
> guaranteed to be the same after reboot. For example, nowadays with
> persistent interface naming, the unmanaged state could be stored
> per-interface name, but it's not clear that this is the correct behaviour in
> all use-cases. Maybe it should tie the persistent setting to the MAC
> address? What if you change the hardware or plug it into a different
> location? Also, how to ever clean-up such persistent data if the device
> actually goes away (and how to know, that the device is really gone).
> 
> Of course, a similar problem already exists for
> 
>   - lease files (/var/lib/NetworkManager/*lease)
>   - no-auto-default setting (/var/lib/NetworkManager/no-auto-default.state)
>   - and for profiles' connection timestamps
> (/var/lib/NetworkManager/timestamps)
> 
> We should improve persisting such per-device configuration (or per-profile
> configuration), in particular with respect 
> 
>   - unify the implementation of such persistent settings
>   - device a scheme how the per-device configuration matches to a device
>   - how to garbage collect old configuration for devices that are gone.
> 
> 
> Until this feature is added, you can configured devices persistently by
> editing configuration files or udev rules.

OK, I see, so about how long the feature will be added. before RHEL 9 ?


Note You need to log in before you can comment on or make changes to this bug.