В Wed, 18 Feb 2015 21:48:48 +0100 Tom Gundersen <[email protected]> пишет:
> On Wed, Feb 18, 2015 at 9:36 PM, Reindl Harald <[email protected]> wrote: > > Am 18.02.2015 um 21:29 schrieb Giancarlo Razzolini: > >> It is my perception that if you are using predictable network interface > >> naming, which is the current default, you can safely make your network > >> configuration use the changed interfaces names to be sure they'll get > >> the desired interface. This applies to network configuration, firewall > >> rules, whatever > > > > predictable? go away! > > I think you know he was referring to: > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > Maybe you disagree with the use of the word 'predictable', but that's > what the scheme is called, so let's just stick to that (maybe thinking > of it as 'deterministic' would make it more palatable). > What's wrong with renaming it if we agree that name was chosen badly^Wsuboptimal? Unless this is deliberate marketing decision of course. > > on any machine i know running network.service (the old style) > > ethX is predictable and the new "predictable" changed multiple times and > > frankly there are configurations re-used on a dozens of machines where i > > know in case of *all of them* that eth1 is *always* the WAN interface > > Good. Then disable the logic. But please understand that in general it > is not possible to know whether eth0/eth1 will be switched between > reboots. Our default logic must work in general, not only on specific > machines, which is why it is the way it is. > Come on, persistent interface names, including topology based name assignment, was possible and in use long before this new scheme was invented. New scheme is not about "predictability" but about removing need to rename interfaces. The only real justification is "trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace". From user point of view it sounds "we (developers) were not able to solve this problem so we decided to make it your (users) problem". _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
