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 955371381F3 for ; Mon, 30 Sep 2013 10:45:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 049FFE0C37; Mon, 30 Sep 2013 10:45:40 +0000 (UTC) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C1FDEE0BF0 for ; Mon, 30 Sep 2013 10:45:38 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so5471526wes.27 for ; Mon, 30 Sep 2013 03:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lt9JHg+07qRtEPQV1vOgxk4daJdqX7XiFoi8dH/law4=; b=ZfNUsX7ZmRbewuyETVDGuFDkcq8jUSH3G5vnnxZjuj9k+ZD7w+Vwhij/0Jb+wkI8ON Jbu+M0i0DfAu8wYYKZCry8p1GnV1SIACc4LDlOSsYaQqvNeMP9hDlovGC17PRWPtFN7p 5V//Snoj936bA2a9RpIQ4959UrN4eY01Hf7+j+Md+O1F94xZA0zU/xQSbfyRPE/SQm2o XEcpGHpVqe5Y5a1BBRtw5CGb37W/70YkElk9cEbpJnUr0mg2qzwKHnrUK0HHOtVeaIbN pi9tYcUp9cOq7B9g9jpIi1gqvMqrcQXUNlj/x2uJnOaKXsQ2iTp7iI5c3Z6pkUyKUyIZ 9wyg== X-Received: by 10.180.73.65 with SMTP id j1mr13390846wiv.10.1380537937443; Mon, 30 Sep 2013 03:45:37 -0700 (PDT) Received: from [10.1.20.197] (dustpuppy.is.co.za. [196.14.169.11]) by mx.google.com with ESMTPSA id fz8sm24717867wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 03:45:37 -0700 (PDT) Message-ID: <52495542.7060609@gmail.com> Date: Mon, 30 Sep 2013 12:41:06 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01 References: <20130928003220.GF23408@server> <20130930041408.GA3849@waltdnes.org> <52492FDC.5080908@gmail.com> <12328492.BGaVIiLfgt@eve> In-Reply-To: <12328492.BGaVIiLfgt@eve> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: a02fec39-ba10-4a32-8cfe-d8735e843209 X-Archives-Hash: 81c7845b64418d3489150aecd957a9cb On 30/09/2013 12:32, Joost Roeleveld wrote: > On Monday 30 September 2013 10:01:32 Alan McKinnon wrote: >> On 30/09/2013 06:14, Walter Dnes wrote: >>> If the udev people had made "net ifnames=0" the default, and allowed >>> >>> the small percentage of multi-nic machine admins to set "net.ifnames=1", >>> this would not have been an issue. Some corner case exotic setups >>> require complex solutions... no ifs/ands/ors/buts. All the complaining >>> you hear is from the other 99% who's setup worked just fine with the >>> simple solution, suddenly finding the complex solution rammed down their >>> throats. >> >> No, that is just plain wrong. >> >> Having interfaces on a multi-nic host come up as ethX where X is a >> mostly random number is just so broken it beggars belief. Trust me, it >> is zero fun when it happens and what makes it even worse if you have no >> warning at all beforehand. > > I trust you, but on my multi-nic systems, I found a better solution :) > As I use Xen to virtualize my systems and as I don't want to have multiple > network cables running side-by-side, I started using VLANs. > > I know have all the NICs names eth1,eth2,...ethn. > I throw them all as a bonded network device: bond0 (the other ends go into a > switch supporting bonding network ports) > then on top of that, I have VLANs with distinctive names (lan, dmz, guest, > vm,...) and link these as required to different Xen-domains. > > When the network names get renamed suddenly to the "non-predictive" scheme, my > system refuses to boot. > Before that, I would use mac-addresses to link ethx devices to names that make > sense to me. (see above for the names) The worst case that comes to mind was a three zone netflow collector plus the first nic on our management range. If you're familiar with old netflow versions you'll know it is UDP from the router and is touchy about addresses. So we had incoming netflow from three ranges each hitting a dedicated nic and this all worked marvellously for years and years. One day after a routine maintenance window the box came up with all 4 nics scrambled and who knows what was now assigned to what. Forget ssh to log in and fix it - nothing was listening. That took very senior sysadmins on site to deal with, the regular maintenance guy was in way over his head. Business were OK with losing 15 minutes billing and stats data in a maintenance window. They were definitely not OK with losing several hours of it because someone thought assigning names on a non-deterministic discovery order was a good idea. One thing about Dell hardware - you always know exactly what each nic is connected to on the motherboard so with that info the new names are predictable (consistent is actually the better term). Using MAC addresses for the same purposes is clunky and unwieldy, the MACs have to be recorded somewhere and you still don't know which MAC goes with which physical socket. With bus numbers you do know. -- Alan McKinnon alan.mckinnon@gmail.com