Le 05/10/2015 18:54, Rainer Weikusat a écrit :
> Didier Kryn <kryn@???> 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
::
Re: [DNG] Purpose of an OS: was net…
