Hi, On Thu, 2018-10-25 at 20:35 +0200, Thomas HUMMEL wrote:
On 10/18/2018 11:30 PM, Thomas Haller wrote: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,Hello again, another use case I'm still wrapping my head around (even with the precious knowledge acquired thanks to your help!) Let's say I've got this setup : - eth0 NM_CONTROLLED=no - eth1 NM_UNMANAGED=1 via udev (and suppose eth1 in no-auto-default.state) here's what I'm testing - about NM_CONTROLLED=no : # nmcli connection show NAME UUID TYPE DEVICE # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show GENERAL.DEVICE: eth0 GENERAL.STATE: 10 (unmanaged) GENERAL.DEVICE: eth1 GENERAL.STATE: 10 (unmanaged) GENERAL.DEVICE: lo GENERAL.STATE: 10 (unmanaged) # nmcli device set eth0 managed yes # echo $? 0 # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show GENERAL.DEVICE: eth0 GENERAL.STATE: 10 (unmanaged) -> as you explained, unmanaging a device this way is definite, but is the 0 return value legit here ?
The return value of the nmcli command is odd, maybe a bug. It returns success, because it successfully flagged the device that the user wishes to manage it. However, there may still be other (stronger) reasons, why the device stays unmanaged (NM_CONTROLLED=no). Ah, there is also `nmcli -f GENERAL.NM-MANAGED device show eth0 `, but this just returns (state != "unmanaged"). Optimally, there would be a nother flag which is the opposite of `nmcli device set $DEV managed $VALUE`. So, when you issue device-set, it would succeed and would toggle this flag, but that alone may not be sufficient to make the device (fully) GENERAL.NM-MANAGED yet.
- about the following sentence in man regarding NM_UNMANAGED : "You will still be able to attach a connection to the device manually or observe externally added configuration such as addresses or routes."
I think this part of the manual should be improved. https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=085b769729e9c623cc60bb0f88df36d1843cd22b
# nmcli device set eth1 managed yes # echo $? 0 # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show GENERAL.DEVICE: eth1 GENERAL.STATE: 20 (unavailable)
state "unavailable", looks like the device has no cable plugged in (no carrier). You'd also see that with `ip link show eth1` saying "NO- CARRIER".
-> it's not unmanaged anymore, so it's managed # nmcli connection show NAME UUID TYPE DEVICE -> still no connection, seems normal to me
I agree. A connection would only be created via the "auto-default" mechanism, which depends on main.no-auto-default setting and /var/lib/NetworkManager/no-auto-default.state. Not sure whether that's the case, or because the device state is still unavailable... either way, this doesn't seem wrong here (without knowing all the details).
# nmcli device connect eth1 Error: Failed to add/activate new connection: Connection 'eth1' is not available on the device eth1 at this time.
Here, (I think), first nmcli tried to activate a profile on the device. That failed, because no profile exists. Then it tried to create a new profile (with ipv4.method=auto). Activation of the created profile then probably fails, because the device has no carrier (which is required for successful DHCP).
-> ok, seems normal to as well since auto profile creation must not work under NM_UNMANAGED conditions
no, I think this part of the manual is misleading. A device is either "unmanaged" or not. Udev's NM_UNMANAGED is a way to configure the device as unmanaged, and `nmcli device set $DEV managed yes` can overrule that. Aterwards, there is no further difference between other managed devices.
# nmcli connection add type ethernet con-name managed-eth1 ifname eth1 Connection 'managed-eth1' (41727fca-d424-40d9-91e7-55197ff9a962) successfully added. # nmcli connection show NAME UUID TYPE DEVICE managed-eth1 41727fca-d424-40d9-91e7-55197ff9a962 ethernet -- -> ok I managed to create a connection somehow linked to eth1 device. It's not active which also seems normal to me
It didn't autoactivate, because the device's state is "unavailable" If you'd create a profile with ipv4.method=manual, you could also activate it on a device with cabel unplugged.
But then I cannon neither connect the eth1 device nor activate the newly created profile -> what's happening here ?
best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part