Re: stable and portable "NM_CONTROLLED=no "?

[Dan Williams <dcbw redhat com>]

On Wed, 2010-03-03 at 09:49 +0000, Marc Herbert wrote:
> 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.

On Fedora/RHEL systems, ifcfg files are not obsolete.  We decided it was
pointless to obsolete a format that system administrators know well and
that many tools already handle well.  Thus, we're trying to make sure
that the ifcfg-rh settings plugin reads and writes ifcfg files as well
as possible.

For your system, the recommended way of unmanaging a device is to use
NM_CONTROLLED=no and HWADDR in an ifcfg file.

Dan

> 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
> > 
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list