stable and portable "NM_CONTROLLED=no "?

[Marc Herbert <Marc Herbert gmail com>]

Hi,

 I need a device with a known MAC address to be "unmanaged" at all
times. For the moment I am successfully using ifcfg-rh +
NM_CONTROLLED=no, but I am not very comfortable with this dependency on
deprecated configuration files that NM is precisely meant to supersede.

In ArchWiki (a surprisingly rich source of NM information), I found this
alternative solution:

/etc/NetworkManager/nm-system-settings.conf
[keyfile]
unmanaged-devices=/org/freedesktop/Hal/devices/net_00_1f_11_01_06_55;/org/free...

But I also read somewhere that NM has moved away from HAL. So this is
yet another deprecated solution, isn't it?

In brief, what would be the "right way" to unmanage a device? Thanks!

Marc



Dan Williams a écrit :
> On Wed, 2009-05-27 at 10:13 +0100, Marc Herbert wrote:
>> Dan Williams a écrit :
>>> On Tue, 2009-05-26 at 18:53 +0100, Marc Herbert wrote:
>>> If you're just going to have udev map HWADDR -> iface, and then NM
>>> depends on iface, why not just have NM use the HWADDR and avoid the
>>> indirection?
>> Because anyone else but NM still depends on this correct and stable
>> HWADDR->eth1 mapping performed by udev. Exemple: the old ifcfg-eth1
>> system entirely relies on it, as the filename shows.
> 
> Wrong.  The ifcfg file name has *nothing* to do with anything.  I can
> just as well name it "ifcfg-Work" and it will work just fine.  I then
> "ifup Work" and stuff happens.
> 
>>> NM doesn't *duplicate* the HWADDR
>>> mappings, because that's simply not how things work.  
>> If you must have the same HWADDR->eth1 mapping configured in both
>> ifcfg-eth1 and udev, then it is duplicated. This is just fact.
> 
> Again, no.  They are using the same base information, the MAC address.
> Nothing is being duplicated here; NM and udev operate on the same level:
> 
> .--------------------------.    .-----------------.
> |          NM              | <- |      udev       |
> `--------------------------'    `-----------------'
>                /|\                 /|\
>                 |                   |
>                \|/                 \|/
>               .-`-------------------`----.
>               |       hardware           |
>               `--------------------------'
> 
> Udev provides some nice device manipulation properties, and can gather
> information about devices and provide that to other devices.  But NM
> doesn't really operate on top of udev.
> 
> You don't even need DEVICE= in the ifcfg file if you don't want to.
> ifup will complain, but NM will not.  NM doesn't "map" HWADDR to
> anything, let alone interface.  Interface is there for your enjoyment,
> but is informational only, not critical.  You can change the interface
> name of the device at any time, but the MAC is much less likely to
> change.
> 
>> I think one issue here is that, despite all your efforts, NM still
>> indirectly relies on the device name, since "NM_CONTROLLED=no" is read
>> in a file unfortunately named "ifcfg-eth1".
> 
> Could be named "ifcfg-Work".  Doesn't have to have any relation to the
> device name.  In fact, when there isn't an associated device (ie with
> PPP or other types) it doesn't get named 'ifcfg-ppp0' necessarily.
> 
>> So if instead you make NM read the "NM_CONTROLLED=no" flag in some other
>> "/etc/NetworkManager/HWADDR" configuration item (NOT referencing the
>> device name in anyway), then the duplicate mapping problem goes
>> away. This would make NetworkManager really ethX-agnostic, isolated
>> from this major ifcfg design flaw (duplicating udev).
> 
> Yes, that could be a clearer solution.  When using the 'keyfile' plugin
> instead of ifcfg-rh, unmanaged devices are actually stored
> in /etc/NetworkManager/nm-system-settings.conf and referenced roughly by
> MAC address.  (well, HAL udi, but that is generated from the MAC address
> so the effect is the same).
> 
>>> But the difference here is that the device name is irrelevant in the
>>> end, because both NM and udev are using the same base data: the
>>> unique MAC address of the card.
>> The device name is relevant to every network configuration file, tool
>> or script ever written (except NM?). It is also what every system
>> administrator is used to deal with. I understand that NetworkManager
>> laudable goal is to get rid of all of these, making the "eth1" device
>> name truly irrelevant, but this it not going to happen overnight.
> 
> It was a problem before NetworkManager was created, and a problem long
> after as well.  Udev makes the situation somewhat better by trying to
> map device names via MAC address, but sometimes that is still wrong or
> not possible to do.  NM simply makes the problem clear: that device
> names are *not* relevant across boots, because they are not stable
> across boots.
> 
> Dan
>