Re: [PATCH] Make ifcfg-eth* NM_CONTROLLED=no work without HWADDR by matching on device name

[Dan Williams <dcbw redhat com>]

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