Re: [DNG] Purpose of an OS: was network device naming
On 03/10/15 20:49, Simon Hobson wrote: poitr pogo wrote: I thought it was stupid for other reasons, but now that you mention it, yeah, naming it after the particular slot into which it's plugged in is stupid, and if you take the box apart and move things around, you can break your OS. no. it is not stupid. it is the most reasonable way. one can replace a part and do not have to touch any system config. And the flip side is that you can't move anything without the name changing. Plug the USB-[ethernet|wifi] adapter into a different orifice and it's now got a different name. Move an ethernet card because you want that slot for something different and it's now got a different name. device by manufactuter name or model name or serial. this is stupid. No more or less stupid than by physical location. Eg, taking the above mentioned USB adapter - if you use it's serial number then it keeps it's name regardless of which socket it's plugged into, vs changing name depending on where it's plugged in. 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. Actually, I think there is a sane solution to this that would provide consistent names for certain devices. Both device hardware id and location are important but either may change without renaming the device - with constraints. The way to do this is to record both the devices hardware identifiers (at least mac address and device type) as well as location. For network cards, if the mac address remains the same and the card is moved then the device shouldn't be renamed. If the device is replaced by another device of the same function (ie; network card) in the same slot then give it the same name as the old card in that slot. Additional rules for usb network interfaces, modems and wifi could be easily created to give consistent documented behaviour. I think this is the key to solving these sorts of gripes. Make the best default behaviours, and document them properly so that anybody that wants/expects different behaviour at least has some chance of working around it or changing the default behaviour. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Didier Kryn writes: > Le 05/10/2015 18:54, Rainer Weikusat a écrit : [...] >> 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. By default, this file doesn't exist. But the udev package contains a /lib/udev/rules.d/75-persistent-net-generator.rules which is responsible for "writing net rules" and creating the /etc file of the same (base-)name overrides that. [...] >> 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. "Once upon a time in the past", I deal with a SoC running Linux (2.4) where the interface MAC addresses had to be programmed into the hardware based on date read from the flash ROM ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Didier Kryn wrote: > Out of curiosity, why are the virtual Ethernet given random addresses? Well they have to have something ! For Xen, they've registered an OUI to get a block of MAC addresses to use. If you don't specify teh MAC address in the VM config then it'll pick one at random, but you can specify a specific address (that's what I do - derived from the IP address) and that will be used. If you specify an address then the machine will behave as though it has a fixed address - but obviously you have to manage the assignment of addresses and ensure uniqueness within your own network. "Interesting" things happen if you get this wrong and start two VMs with the same MAC address :-( I suppose the alternative would be for the virtualisation manager to keep some state - assign random addresses to new VMs, but then store those assignments to make them sticky - only changing them if something else (eg a VM hosted on another host) has taken the same one. Windows HyperV is the same. VMs change MAC addresses every time they are restarted - the difference is that my colleagues can't be bothered setting fixed ones. I know this as I have Nagios setup to monitor the network for rogue devices (or duplicated IP addresses) - and I have to update it's config every time one of the Windows VMs is restarted. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
On Tue, Oct 6, 2015 at 9:44 AM, Didier Kryn wrote: > Le 05/10/2015 18:54, Rainer Weikusat a écrit : > 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. At least with the g_ether driver, you can actually use a fixed MAC through module arguments! A common fixed default wouldn't probably cut it if you need more than one g_ether device at a time, and a system-specific default has been used by Debian to add gratuitous systemd dependencies to Gummiboot ;) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Le 05/10/2015 18:54, Rainer Weikusat a écrit : Didier 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
- Original Message - > From: "Rainer Weikusat" > Didier Kryn writes: >> 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. And if you forgot to create /etc/udev/rules.d/75-persistent-net-generator.rules and have rebooted with your new network card installed, you may have another option. If you only have a single network card, just delete /etc/udev/rules.d/70-persistent-net.rules and reboot. It will be re-created with your single network card defined as eth0. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Didier 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. [...] > 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. > 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). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
On Mon, 05 Oct 2015 12:28:44 +0200 Didier Kryn wrote: > As was remarked already, disks are no longer a problem since > partitions are uniquely identified, so that nobody cares of a random > device name. Some do, when they issue a df command, and the result is a mess of unidentifiable UUIDs. Which is why, after an install, one of the first things I do is to restore /etc/fstab to an understandable format, ridding it of all the UUID crap. And edit etc/default/grub uncommenting the line #GRUB_DISABLE_LINUX_UUID=true then running # update-grub2 So that my / partition gets mounted as /dev/sda1 Cheers, Ron. -- There is no such thing as an ugly woman; there are only the ones who do not know how to make themselves attractive. -- Christian Dior -- http://www.olgiati-in-paraguay.org -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
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. I am not sure numbering wifi interfaces (who uses more than one?) is a problem; which matters is the station they connect to. 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. 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. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
Somon: > k...@aspodata.se wrote: ... > > ... after all, fstab and /dev/-names are just > > for the user space. The kernel mostly only cares about the maj/min > > numbers, or am I wrong? > > That's the case all along. The question is how to map those node > IDs to something human readable. Maybe it's a valid question, but it's not the question I'm posing. When you reconnect the disk it will get a new maj/min number, you might call it the same /dev-name, but for the kernel it's a totally new disk. > > What happens when you unplug your root fs, wait a few seconds till > > the kernel gives up and then plug it in again ? > > I would expect the system to die horribly if you do that - regardless of how > you name things ! So, why is that ? If you disconnect a network cable, serial port, etc., does the system, or even some connection die ? If you connect the disk again and the kernel sees that it is the same fs etc., why not silently make it available again, why should the system have to die ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
On Sun, Oct 04, 2015 at 04:57:15PM +0100, Simon Hobson wrote: > k...@aspodata.se wrote: > > >> This is why you use UUID= or LABEL= in /etc/fstab. > > +1 for that. I use LABEL=, but it's annoying that Debian's grub-install > doesn't handle that (it only has options for device name or UUID). > > > Let's face it, thoose other names of the device is just symlinks > > Does that really matter ? > > If someone is needing to work at the device level, they they should know how > to determine the device name. But from the "system doesn't randomly break > itself" POV it's one way to deal with the issue. > > > ... after all, fstab and /dev/-names are just > > for the user space. The kernel mostly only cares about the maj/min > > numbers, or am I wrong? > > That's the case all along. The question is how to map those node IDs to > something human readable. I seem to remember that a few years ago they started assigning some of the minor number dynamically. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
k...@aspodata.se wrote: >> This is why you use UUID= or LABEL= in /etc/fstab. +1 for that. I use LABEL=, but it's annoying that Debian's grub-install doesn't handle that (it only has options for device name or UUID). > Let's face it, thoose other names of the device is just symlinks Does that really matter ? If someone is needing to work at the device level, they they should know how to determine the device name. But from the "system doesn't randomly break itself" POV it's one way to deal with the issue. > ... after all, fstab and /dev/-names are just > for the user space. The kernel mostly only cares about the maj/min > numbers, or am I wrong? That's the case all along. The question is how to map those node IDs to something human readable. > What happens when you unplug your root fs, wait a few seconds till > the kernel gives up and then plug it in again ? I would expect the system to die horribly if you do that - regardless of how you name things ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
Steve: > On Sun, 4 Oct 2015 00:08:58 +0200 (CEST) > k...@aspodata.se wrote: > > Hendrik: > > > Hendrik Boom wrote: > > > > Can we agree that ww shouldnn't have to change our configurations > > > > if we do not change anything in the hardware? > > > That would be a reasonable base requirement. > > What if I have say 5 disks /dev/sd[a-e]; if someone accidentally > > pulled out /dev/sdc, and oops put it back before anyone noticed; > > should it show up again as /dev/sdc or should it be /dev/sdf ? > This is why you use UUID= or LABEL= in /etc/fstab. Let's face it, thoose other names of the device is just symlinks, do a find /dev/disk/ | xargs ls -ld and you will find only dirs. and softlinks. But if the disk is mounted we are past that stage. So that will only help you when the partition is to be mounted or when you want to unmount it, after all, fstab and /dev/-names are just for the user space. The kernel mostly only cares about the maj/min numbers, or am I wrong? What happens when you unplug your root fs, wait a few seconds till the kernel gives up and then plug it in again ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
On Sun, 4 Oct 2015 00:08:58 +0200 (CEST) k...@aspodata.se wrote: > Hendrik: > > Hendrik Boom wrote: > > > > > Can we agree that ww shouldnn't have to change our configurations > > > if we do not change anything in the hardware? > > > > That would be a reasonable base requirement. > > What if I have say 5 disks /dev/sd[a-e]; if someone accidentally > pulled out /dev/sdc, and oops put it back before anyone noticed; > should it show up again as /dev/sdc or should it be /dev/sdf ? This is why you use UUID= or LABEL= in /etc/fstab. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
Hendrik: > Hendrik Boom wrote: > > > Can we agree that ww shouldnn't have to change our configurations if we > > do not change anything in the hardware? > > That would be a reasonable base requirement. What if I have say 5 disks /dev/sd[a-e]; if someone accidentally pulled out /dev/sdc, and oops put it back before anyone noticed; should it show up again as /dev/sdc or should it be /dev/sdf ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
Hendrik Boom wrote: > Can we agree that ww shouldnn't have to change our configurations if we > do not change anything in the hardware? That would be a reasonable base requirement. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
On Sat, Oct 03, 2015 at 08:49:04AM +0100, Simon Hobson wrote: > poitr pogo wrote: > > > > I thought it was stupid for other reasons, but now that you mention it, > > > > > yeah, naming it after the particular slot into which it's plugged in is > > > stupid, and if you take the box apart and move things around, you can > > > break your OS. > > > > > > > no. it is not stupid. it is the most reasonable way. one can replace a part > > and do not have to touch any system config. > > And the flip side is that you can't move anything without the name changing. > Plug the USB-[ethernet|wifi] adapter into a different orifice and it's now > got a different name. Move an ethernet card because you want that slot for > something different and it's now got a different name. > > > device by manufactuter name or model name or serial. this is stupid. > > No more or less stupid than by physical location. Eg, taking the above > mentioned USB adapter - if you use it's serial number then it keeps it's name > regardless of which socket it's plugged into, vs changing name depending on > where it's plugged in. > > As I've mentioned before, I know that the Windows guys at work have had the > problem where the customer/end user plugs the backup drive into a different > USB port and the backups fail. So I believe we normally tell them to leave > the cable attached to the computer. > > > 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. Can we agree that ww shouldnn't have to change our configurations if we do not change anything in the hardware? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
poitr pogo wrote: > > I thought it was stupid for other reasons, but now that you mention it, > > > yeah, naming it after the particular slot into which it's plugged in is > > stupid, and if you take the box apart and move things around, you can > > break your OS. > > > > no. it is not stupid. it is the most reasonable way. one can replace a part > and do not have to touch any system config. And the flip side is that you can't move anything without the name changing. Plug the USB-[ethernet|wifi] adapter into a different orifice and it's now got a different name. Move an ethernet card because you want that slot for something different and it's now got a different name. > device by manufactuter name or model name or serial. this is stupid. No more or less stupid than by physical location. Eg, taking the above mentioned USB adapter - if you use it's serial number then it keeps it's name regardless of which socket it's plugged into, vs changing name depending on where it's plugged in. As I've mentioned before, I know that the Windows guys at work have had the problem where the customer/end user plugs the backup drive into a different USB port and the backups fail. So I believe we normally tell them to leave the cable attached to the computer. 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. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
29-09-2015 16:48, "Steve Litt" napisał(a): > > I thought it was stupid for other reasons, but now that you mention it, > yeah, naming it after the particular slot into which it's plugged in is > stupid, and if you take the box apart and move things around, you can > break your OS. > no. it is not stupid. it is the most reasonable way. one can replace a part and do not have to touch any system config. but that's too hard to locate a part for common desktop user and we get a user frienfly system which is bound tight to the detsils of the hardware it is using and have to reconfigure itself every time new part is added. even temporary. and finaly another layer of abstraction is invented, dynamic reconfiguration instead. all to speed up boot process. device by manufactuter name or model name or serial. this is stupid. -- piotr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Simon Hobson writes: [...] > However, I am happy with the way Udev does it. Booting a "new" system > results in an initially random device ordering, but once it's created > a rules file the devices stay stable until "something changes". When > changing hardware, or shifting the image to new hardware, new devices > get created and the admin needs to "fix" it - but TBH it's not hard to > do. In order to avoid this on a system using the previous/ traditional/ legacy udev scheme for wreaking havoc on a statically configured system (on Debian), a file named /etc/udev/rules.d/75-persistent-net-generator.rules can be created (may be empty). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Simon Hobson writes: > Steve Litt wrote: >>> The whole point of having 'an operating system' >>> is that it provides an abstract interface userspace software can use >>> to interact with the physical components of a different computer >>> according to the functions they're supposed to be provide, regardless >>> of the way this particular computer happens to be assembled. >> >> Does anyone else agree with me that in the preceding sentence Rainer >> encapsulated the entire philosophy of people desiring simple and >> logical software? Rainer, can I quote your preceding sentence elsewhere? > > It seems a good summary to me. > >>> Considering this, encoding details of the bus layout and current bus >>> configuration in network interface names is just profoundly stupid. >> >> I thought it was stupid for other reasons, but now that you mention it, >> yeah, naming it after the particular slot into which it's plugged in is >> stupid, and if you take the box apart and move things around, you can >> break your OS. > > Unfortunately, I think this is one of those areas with no right answer > - only different levels of suckiness. > > Constraining "the system" to always loads drivers in a specific order, > and hence not randomly rename interfaces at boot time is wrong. Constraining userspace helper applications of very subordinate importance to cooperate with the kernel even if their authors personally disagree with this or that kernel design choice seems perfectly fine to me: The kernel interface naming schemes relies on drivers being initialized in probe order to be useful. Hence, it has to be done in this way. Especially considering that there's nothing to gain by doing it in some other way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
Steve Litt wrote: >> The whole point of having 'an operating system' >> is that it provides an abstract interface userspace software can use >> to interact with the physical components of a different computer >> according to the functions they're supposed to be provide, regardless >> of the way this particular computer happens to be assembled. > > Does anyone else agree with me that in the preceding sentence Rainer > encapsulated the entire philosophy of people desiring simple and > logical software? Rainer, can I quote your preceding sentence elsewhere? It seems a good summary to me. >> Considering this, encoding details of the bus layout and current bus >> configuration in network interface names is just profoundly stupid. > > I thought it was stupid for other reasons, but now that you mention it, > yeah, naming it after the particular slot into which it's plugged in is > stupid, and if you take the box apart and move things around, you can > break your OS. Unfortunately, I think this is one of those areas with no right answer - only different levels of suckiness. Constraining "the system" to always loads drivers in a specific order, and hence not randomly rename interfaces at boot time is wrong. Using stupidly long/complicated device names based on physical location is wrong. Doubly wrong when location can be highly variable (as in USB devices)* Using stupidly long/complicated device names incorporating the device serial number (or MAC) is wrong. Using persistent rules files (as with Udev) is wrong. However, I am happy with the way Udev does it. Booting a "new" system results in an initially random device ordering, but once it's created a rules file the devices stay stable until "something changes". When changing hardware, or shifting the image to new hardware, new devices get created and the admin needs to "fix" it - but TBH it's not hard to do. IMO - the sort of person who cannot edit the system created rules file is also not likely to be running the sort of system where it matters. Eg, they are likely to be the sort of use who plugs a cable into a hole in the back of the computer, and "the system" takes care of enabling it and getting addresses via DHCP/autoconf - the user doesn't care if it's eth0, eth57, flurbleport29, or anything else as long as "the network works". If for some reason they replace a network card, it's not likely to matter to them that eth0 is now called eth1 - as long as "it just works". I don't tend to use ethn anyway on bare metal systems - they all have Udev rules to set meaningful names like ethext, ethlan, ethint, and so on. Different on my Xen VMs (Debian [Sarge** ... Wheezy] as out of the box there doesn't seem to be a Udev rules file created and it's never bugged me enough to figure out why ! * I've only hearsay evidence from the screams of colleagues, but it seems that some Windows stuff (in this context, setting up automated backups) is sensitive to which port the disk is plugged into. As in, if the user plugs the backup disk into the wrong USB port, it gets a different drive letter (how 20th century !) and the backup (which uses drive letter and not anything more sensible) fails. ** Yup. still got one of those running ! There is something of a parallel with filesystems/disks - where the results of "getting it wrong" are more significant. I recall back when I had "a bit less experience" and the problem was fairly new, having issues with a system where disks came up in random order during boot (two different controllers). Now I generally use disk (filesystem) labels - though it's "annoying" that Debian doesn't support filesystem labels for Grub - which have the advantage of having their own persistent storage attached to the device, but the same problems when moving things around. It certainly needs a little care when identifying disks/filesystems by label in Xen VM configs. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
> > The whole point of having 'an operating system' > > is that it provides an abstract interface userspace software can use > > to interact with the physical components of a different computer > > according to the functions they're supposed to be provide, regardless > > of the way this particular computer happens to be assembled. > > Does anyone else agree with me that in the preceding sentence Rainer > encapsulated the entire philosophy of people desiring simple and > logical software? Rainer, can I quote your preceding sentence elsewhere? Sounds more like a (rather accurate) explanation on what's the point of an OS to me. See Windows for an implementation of this idea that does not rely on simple and logical software, so, IMO that isn't implicit to what you quoted. > > Considering this, encoding details of the bus layout and current bus > > configuration in network interface names is just profoundly stupid. > > I thought it was stupid for other reasons, but now that you mention it, > yeah, naming it after the particular slot into which it's plugged in is > stupid, and if you take the box apart and move things around, you can > break your OS. Couldn't agree more. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
