tito via Dng <dng@lists.dyne.org> wrote: > I wonder why instead of predictable names they didn't choose > prefix+mac_address at least for initial setup of names and leave it > to user to name the interfaces they way he likes. This would have > guaranteed (almost) unique persistent names and by using standard > prefixes would have identified easily the class of network device.
As suggested already, this is Freedesktop.org - so logic and simplicity are not allowed. Far better to force admins to keep changing a miriad of configs whenever IF names change and break things than to allow a sensible and reliable mechanism to have things stable. It's a variation of Apple's "you're holding it wrong" attitude to user expectations. FWIW, there's a different but related issue with DHCP. With DHCP for IPv4, an identifier included in packets is the MAC address - more technically, Client Interface Address as non-ethernet interfaces are also supported (e.g. token ring). And many workflows rely on this as a stable client identifier - even though it can change. For whatever reasons that may have made sense at the time, with DHCP for IPv6 this was explicitly not done "because MAC addresses can change". Instead, a DUID (DHCP Unique Identifier) was created to be the sole identifier for a node - note node, not interface, the DUID would be the same for all interfaces on a node. Result ? The DUID changes a lot more than the MAC address ever did ! Absent any standardised way of storing it in the machine on typical hardware, any re-install or change of environment can change the DUID unless the admin takes steps to preserve it. And I've had a problem with this. Built a new VM, found it kept changing address on every boot and my reserved lease for it was ignored. I find that for some reason I can't figure, when it starts up it doesn't have a DUID and so creates a new one - so to the server it's a different node and gets a new address. By the time the system mounts the real /var from disk (where the stable DUID is stored), the network is already configured - a manual ifdown-ifup cycle will get it it's correct address. I think the client leases file (which contains the client DUID) should be included in the initram image but doesn't get used. Interestingly, I tried adding some debugging to the network scripts - and the timing changes they produced changed this behaviour ! Simon _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
