Dan Williams wrote, On 05/26/2009 04:29 PM:
On Tue, 2009-05-26 at 11:54 +0200, Mads Kiilerich wrote:Make ifcfg-eth* NM_CONTROLLED=no work without HWADDR by matching on device name IMHO this should work because the "old" network system uses the mac addresses to ensure stable device names anyway. The existing match on mac addresses could perhaps be removed instead. The patch applies to the 0.7.1 branch.MAC addresses are used because there are no other unique identifiers. MAC is the only unique identifier, and therefore that's what must be used to match devices. Device names change, and therefore are not stable, and therefore cannot be used to provide any type of stable naming. Yes, udev rules can be used to work around some of this problem, but they certainly don't fix everything, and sometimes get it wrong, because there is no possible way for them to get it right 100% of the time. Besides, they use MAC addresses anyway, which means the MAC must be valid for a stable device name provided by udev to exist.
Without grokking all the details I think I agree that NM is right thing when it doesn't use device names but MAC addresses. And yes, the old Red Hat-ish ifcfg-eth* files and shell scripts depends on device names and thus sucks in some ways for some purposes - that is why we need NM.
I would reason slightly different:As far as I understands it NM intends to co-exist with ifcfg-eth* devices. If they have NM_CONTROLLED=no then NM shouldn't manage or touch that device. So I would expect that: If an ifcfg works without NM, then it should work exactly the same with NM and NM_CONTROLLED=no.
The key to ifcfg-eth* files are the device names; it is in the file name, and AFAIK DEVICE is the only mandatory "field" inside the file. Having ifcfg-eth* files without HWADDR might be a bad idea and bad design, but it happens, it works (for what it does), it has "always" worked, and IMHO NM should be able to co-exist with that too. Yes, device names are irrelevant for a program like NM, but when NM_CONTROLLED=no is specified in a file which basically has the device name as key then NM should use the device name for that purpose - and converting to MAC ASAP is probably fine.
The semantics of a ifcfg file with just DEVICE=eth0 and NM_CONTROLLED=no is pretty clear: NM shouldn't touch eth0, whatever it is, and NM can look eth0 up in HAL to get its MAC and UDI so that it can avoid it. Whether the MAC address is specified or "random" isn't relevant for NM.
So, as far as I can see, it would be better if NM used DEVICE instead of HWADDR for listing devices not to control. In which cases would that fail? (There might be other good reasons for reading HWADDR - I can't tell.)
(My specific use case is an appliance where I use NM for wireless but don't want it to control eth0. Obviously the eth0 MAC address varies, and storing it in ifcfg is problematic.)
/Mads
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature