From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BBF69138435 for ; Sat, 12 Jan 2013 20:37:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 790CB21C07E; Sat, 12 Jan 2013 20:37:00 +0000 (UTC) Received: from mail-ia0-f169.google.com (mail-ia0-f169.google.com [209.85.210.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 58DB521C018 for ; Sat, 12 Jan 2013 20:35:58 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id j5so423275iaf.28 for ; Sat, 12 Jan 2013 12:35:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=6h4gyd+mR1zVwb8hwlZ/NEBRnB6HLVA1x49n/mmMnLo=; b=Z7QehFjnWHK8hcf+E8uMtEijwWy3uQ2YH3R9UVu7n12faQIydQ3wvs/nR98TKTn9yp flhK0lFBatKE3pZ5PE70CXCQ0+Wr7aCCvbLoE+IK7DIHCGKMzJotcYalnSnTbQlQuaT2 r2H4/OjMPo/v8oOog8A0z1el4F7cqd4LfjLl8Gn2PqSbk7a4BDgYEJNqmK7LtOAIKnJZ zvKYd17Nho2nULIBTnSkLTEBKFibkFvTU93Tuqv7jgQobCNLr25Aw8/LqbLLFAw2zIft H6A/4a5ZbEXdc0tLIHwsONkvVKo8UmYPUoMoezMVwQMYNFmeSaQLyPSw2RaUL6wKSQ79 HJtw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.50.56.232 with SMTP id d8mr2601425igq.112.1358013324106; Sat, 12 Jan 2013 09:55:24 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.64.29.76 with HTTP; Sat, 12 Jan 2013 09:55:23 -0800 (PST) X-Originating-IP: [75.147.136.182] In-Reply-To: <20130112021143.GA4547@rathaus.eclipse.co.uk> References: <20130109221310.GA1749@linux1> <20130109145910.09fda2de@ritchie.cs.ubc.ca> <20130110001321.GA1971@linux1> <20130109164607.17fffc26@ritchie.cs.ubc.ca> <20130112021143.GA4547@rathaus.eclipse.co.uk> Date: Sat, 12 Jan 2013 09:55:23 -0800 X-Google-Sender-Auth: 3N4_bNH6J6JCHTU20SLQxECgCS8 Message-ID: Subject: Re: [gentoo-dev] Re: call for testers: udev predictable network interface names From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmAMMdr4xvqo6otZix6lChzEr2ynh8gyW3vVN6BCuRjHFYWq7K+fg6JJ36nPYCMBHwwL6hu X-Archives-Salt: badd5294-2627-425d-9539-1d083275a63d X-Archives-Hash: 43f9589ba5f3c4b2ea95020aa15c5d60 On Fri, Jan 11, 2013 at 6:11 PM, Steven J. Long wrote: > Christopher Head wrote: >> William Hubbs 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=E2=80=99s automatically assigned name wil= l 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 ;-) >