Re: stable and portable "NM_CONTROLLED=no "?
- From: Dan Williams <dcbw redhat com>
- To: Marc Herbert <Marc Herbert gmail com>
- Cc: networkmanager-list gnome org
- Subject: Re: stable and portable "NM_CONTROLLED=no "?
- Date: Thu, 04 Mar 2010 09:04:41 -0800
On Wed, 2010-03-03 at 09:49 +0000, Marc Herbert wrote:
> 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
For your system, the recommended way of unmanaging a device is to use
NM_CONTROLLED=no and HWADDR in an ifcfg file.
> In ArchWiki (a surprisingly rich source of NM information), I found this
> alternative solution:
> 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!
> 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
] [Thread Prev