Le 05/10/2015 18:54, Rainer Weikusat a écrit :
Didier Kryn <k...@in2p3.fr> writes:
Le 03/10/2015 09:49, Simon Hobson a écrit :
Lets face it - there is no "right" answer to this other than a system
with enough intelligence to read the user/admin's mind and work out
what they intend to happen - and I think we're a bit off that yet !
Looking back, I think I've "moved" something at least as often as
I've replaced it with a different something in the same location -
probably more in fact.
This is exactly the point. But let's consider which devices are a
concern.
As was remarked already, disks are no longer a problem since
partitions are uniquely identified, so that nobody cares of a random
device name. And even symlinks are created in /media, named after the
labels of the partitions.
All of these 'UUID' and 'partition labeling' is the exact same kind of
workaround for the exact same kind of "udev design strangeness" as for
the ethernet interfaces and I'm not using that anywhere except on a 'USB
install disk' where the intended root partition needs to be found by the
booting kernel and OS regardless of which mass storage devices may be
found as part of the computer the system is booting on. Which is how
these things should work: Use the more complicated solution for the more
complicated case, don't just use it for the simple cases because it can
also handle them.
[...]
Yes this is all workaround. There is a need to put order in a world
which is disordered by nature. Currently we are discussing three ways to
denote identical things:
1) call them after the order in which they are discovered (sda,
sdb, sdc, eth0 eth1...)
2) give them a unique name (uuid, label, MAC address)
3) call them after the place where they are
I think the second method is the most stable, in general.
When you boot your computer from a rescue disk, your hard drive is
going to be named sdb instead of sda. Your life is going to be simpler
if you use labels of uuids in your fstab: you can chroot and mount -a.
The pitty is there are uuids and labels for partitions but not for
disks (eg in the partition table), which implies you must still call
them sd[a-z] when invoking parted or cfdisk.
Ethernet interfaces are maybe the only issue, which explains why
distros have implemented a solution by the means of udev rules. The
way it is implemented is secure: every new ethernet device is given a
new device name (ethX) and no entry is created in
/etc/network/interfaces; therefore the interface isn't connected
without an action of the admin. If it is a replacement, then the admin
should just edit the MAC address in
/etc/udev/rules.d/70-persistent-net.rules. Not a big deal, compared to
replacing the hardware.
As I already wrote: A file
/etc/udev/rules.d/75-persistent-net-generator.rules
can be created (on Debian up to wheezy at least) to avoid this "install
the system to new hardware and get a whole bunch of new ethN instead of
the onese which aren't available anymore" mess altogether.
This logic was implemented in older versions of Debian by the mean
of the file you say, but this file is not installed on my Debian Wheezy;
therefore I am afraid they have implemented the same logic in some
hidden place.
The new policy Poettering et al are enforcing means to relieve the
admin from this little and rare work, at the cost of a nightmare for
all the rest.
It's not that simple as MAC addresses are neither necessarily persistent
nor necessarily unique. Eg, by default, so-called "virtual ethernet pair
interface" (used to connect containers to physical interfaces via bridge
interfaces) use random MAC addresses. It's also often/ usually possible
to change the MAC address of an interface. That's just something the
people who came up with the previous less-than-bright idea didn't think/
know about at the time they did come up with it (according to the 'code
comment' documenting the new scheme).
Yes, changing the MAC address of a real network interface can be
done to fool a DHCP server (I don't see any other reason), but this is
done in user space, after the kernel has registered it. Out of
curiosity, why are the virtual Ethernet given random addresses? It
looks like a means to increase disorder with no reason. I bet it's not
your choice.
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
