Re: [gentoo-dev] Re: call for testers: udev predictable network interface names
but again it appears that simple cases are being made complex, just to allow for someone else's complex cases. Which is faulty logic. It's a welcome option but an important question seems to be; Why wasn't this picked up in the dev cycle?. This reminds me of udisks 8 months ago losing features for multi-seat costing me time to replace it with udev and scripts which I still prefer. Is it coincidence that Redhat wanted complex multiseat at all costs for udisks and Redhat want fast boot at all cost for cloud services? p.s. I am very glad of RedHats contributions and respect their position of giving coders freedom but I just think that if they are able to fund coders to look after a corner full-time or completely then they need to manage that corner or atleast have some ground rules to cover any case of my way or the high way. The kernel wouldn't tolerate this kind of breakage and I really hope I never see linux userland as dependent on IPC as minix is or as broken without IPC as windows is without RPC. I take the unarguably more secure well setup sudoers and useful small tools anyone can use or take code from over polkit anyday. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-dev] Re: call for testers: udev predictable network interface names
On Sat, Jan 12, 2013 at 02:11:43AM +, Steven J. Long wrote: Christopher Head wrote: William Hubbs willi...@gentoo.org wrote: There is a way for users to opt out if we default this to on, but I think the new naming scheme has advantages over the traditional eth* wlan* etc names. I think it should be taken with a grain of salt. The page mentions how it lets you replace a failed NIC without losing its name. But given a simple computer with just one NIC, if the NIC fails and is replaced (perhaps by a different type of NIC in a different slot, or perhaps an onboard NIC disabled in the BIOS and replaced by an add-in), the name could change, while the kernel’s automatically assigned name will not: eth0 (this also applies to a computer with one Ethernet NIC and one wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki page, even though it applies to a heck of a lot of systems. Perhaps something to include when the Gentoo docs are put together, as part of the balance of reasons to choose one way or the other? That's a very good point. For the vast majority of users all these desktop changes are supposed to help, it's not at all relevant. Obviously it's good to have the functionality should you need it, but again it appears that simple cases are being made complex, just to allow for someone else's complex cases. Which is faulty logic. While many packages have default configurations, changing the default setup for base system packages in the absence of any configuration is not generally a good idea, unless you know for a fact it's not going to mess anything up (which is a big ask given that you're distributing source.) Especially given the arguments presented as a motivation, that all this has serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names. Isn't this the very definition of the kernel-based names? if you do not have a persistent net rules file, you are subject to the kernel's naming order, and I have heard of situations in the past when people upgrade their kernels, etc, and when they reboot their interface names are changed around. If you're certain that every user with a current simple setup, who uses the kernel default names, and has such a firewall setup isn't going to suddenly find their interface name changed when they reboot, fair play to you. If not, allow the admin to opt-in, rather than force them to opt-out when something breaks. The following is taken from the wiki: I don't like this, how do I disable this? You basically have three options: 1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules 2. You create your own manual naming scheme, for example by naming your interfaces internet0, dmz0 or lan0. For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it /etc/udev/rules.d/70-my-net-names.rules 3. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules, then edit the file there and change the lines as necessary. If you have upgraded your udev, you see that you have the file /etc/udev/rules.d/80-net-name-slot.rules. This file is only created *once*, when you upgrade from a version of udev lower than 197. This means when this version of udev goes stable, new installs will not have this file created. If you have a file that fits the requirements of option 2 (which 70-persistent-net.rules does) in your /etc/udev/rules.d, you can rm 80-net-name-slot.rules and you will not be affected. If you do not have a file in /etc/udev/rules.d that fits the requirements of option 2 and you remove 80-net-name-slot.rules, your interface names will change on your next reboot, so you should be prepared for that. The created version of /etc/udev/rules.d/80-net-name-slot.rules has comments explaining how to get the new names of your network interfaces before the reboot so you can reconfigure. William pgpMtpCUzc0Sn.pgp Description: PGP signature
Re: [gentoo-dev] Re: call for testers: udev predictable network interface names
On Fri, Jan 11, 2013 at 6:11 PM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: Christopher Head wrote: William Hubbs willi...@gentoo.org wrote: There is a way for users to opt out if we default this to on, but I think the new naming scheme has advantages over the traditional eth* wlan* etc names. I think it should be taken with a grain of salt. The page mentions how it lets you replace a failed NIC without losing its name. But given a simple computer with just one NIC, if the NIC fails and is replaced (perhaps by a different type of NIC in a different slot, or perhaps an onboard NIC disabled in the BIOS and replaced by an add-in), the name could change, while the kernel’s automatically assigned name will not: eth0 (this also applies to a computer with one Ethernet NIC and one wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki page, even though it applies to a heck of a lot of systems. Perhaps something to include when the Gentoo docs are put together, as part of the balance of reasons to choose one way or the other? That's a very good point. For the vast majority of users all these desktop changes are supposed to help, it's not at all relevant. Obviously it's good to have the functionality should you need it, but again it appears that simple cases are being made complex, just to allow for someone else's complex cases. Which is faulty logic. I think the wiki page explains the motivations well. They are similar to the disk changes that were made years ago (porting apps to use UUIDs to ensure you have the correct disk, even when disk order changes.) The MAC address is obviously the first UUID one thinks of; however they talk about why they did not end up choosing the MAC address as the UUID for network devices. As an example; I have a server with two ethernet ports. One is onboard (driverA) and the other is a pci-express card (driverB.) It turns out driverB doesn't work, but sometimes driverB gets put as eth0. Then the machine cannot get on the network. We work around this by blacklisting driverB (so it is never loaded as an ethernet device) but it might be saner to adopt this new udev and simply configure the network to use driverA always. While many packages have default configurations, changing the default setup for base system packages in the absence of any configuration is not generally a good idea, unless you know for a fact it's not going to mess anything up (which is a big ask given that you're distributing source.) Especially given the arguments presented as a motivation, that all this has serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names. If you're certain that every user with a current simple setup, who uses the kernel default names, and has such a firewall setup isn't going to suddenly find their interface name changed when they reboot, fair play to you. If not, allow the admin to opt-in, rather than force them to opt-out when something breaks. That's the usual manner to introduce something new or changed, and for good reason. After all, those who are aware of it and interested, already know to configure it, or are looking for help to do so. Most other users don't care, and don't want the maintenance headache. I agree it is one way to introduce something new; I wouldn't say it is the only way (or even the 'usual' way.) -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: call for testers: udev predictable network interface names
Christopher Head wrote: William Hubbs willi...@gentoo.org wrote: There is a way for users to opt out if we default this to on, but I think the new naming scheme has advantages over the traditional eth* wlan* etc names. I think it should be taken with a grain of salt. The page mentions how it lets you replace a failed NIC without losing its name. But given a simple computer with just one NIC, if the NIC fails and is replaced (perhaps by a different type of NIC in a different slot, or perhaps an onboard NIC disabled in the BIOS and replaced by an add-in), the name could change, while the kernel’s automatically assigned name will not: eth0 (this also applies to a computer with one Ethernet NIC and one wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki page, even though it applies to a heck of a lot of systems. Perhaps something to include when the Gentoo docs are put together, as part of the balance of reasons to choose one way or the other? That's a very good point. For the vast majority of users all these desktop changes are supposed to help, it's not at all relevant. Obviously it's good to have the functionality should you need it, but again it appears that simple cases are being made complex, just to allow for someone else's complex cases. Which is faulty logic. While many packages have default configurations, changing the default setup for base system packages in the absence of any configuration is not generally a good idea, unless you know for a fact it's not going to mess anything up (which is a big ask given that you're distributing source.) Especially given the arguments presented as a motivation, that all this has serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names. If you're certain that every user with a current simple setup, who uses the kernel default names, and has such a firewall setup isn't going to suddenly find their interface name changed when they reboot, fair play to you. If not, allow the admin to opt-in, rather than force them to opt-out when something breaks. That's the usual manner to introduce something new or changed, and for good reason. After all, those who are aware of it and interested, already know to configure it, or are looking for help to do so. Most other users don't care, and don't want the maintenance headache. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: call for testers: udev predictable network interface names
On 2013-01-10, Daniel Campbell wrote: On 01/09/2013 04:13 PM, William Hubbs wrote: All, as you probably know by now, udev-197 has hit the tree. This new version implements a new feature called predictable network interface names [1], which I have currently turned off for live systems, because it will require migration on the part of the user. When you upgrade to this new version of udev, you will find a file /etc/udev/rules.d/80-net-name-slot.rules on your system. It currently has comments explaining what is happening. As long as this file is in place, this feature is not activated. That is why there is not a news item. If you do nothing, nothing changes. What I would like to do is find some people who are willing to migrate and report any issues they find. I would like this to be the default for everyone at some point, so I want to document the migration process and find out if there are any bugs in tools because they expect the eth* names. Thoughts? William [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames So long as users retain the choice of keeping eth* or wlan*, no complaints from me. I (and others) came to Gentoo to get away from systemd, and this smells of a systemd-ism. Will eudev be pursuing this as well? This sounds like an udev feature, completely unrelated to systemd. It's a bit hard for me to understand why do you even relate this to systemd, when udev has done this kind of device name management for *ages*. I mean, I think udev has been bundled with *persistent* rules for some months now... Playing with NIC device names is not something exclusive to udev, it has always been fun with wireless drivers who roam between eth*, wlan*, ath*... -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
