From owner-freebsd-stable@FreeBSD.ORG Mon Feb 12 23:26:40 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 838AA16A402 for ; Mon, 12 Feb 2007 23:26:40 +0000 (UTC) (envelope-from kevin@insidesystems.net) Received: from imap.insidesystems.net (imap.insidesystems.net [206.216.149.56]) by mx1.freebsd.org (Postfix) with ESMTP id 63A6F13C494 for ; Mon, 12 Feb 2007 23:26:40 +0000 (UTC) (envelope-from kevin@insidesystems.net) Received: from [68.32.227.193] (helo=[127.0.0.1]) by imap.insidesystems.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HGkZ2-000OhX-5v; Mon, 12 Feb 2007 17:26:28 -0600 Message-ID: <45D0F785.1040805@insidesystems.net> Date: Mon, 12 Feb 2007 18:25:57 -0500 From: Kevin Way Organization: InsideSystems, Inc. User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, olli@lurza.secnetix.de References: <200702121809.l1CI9rBq065457@lurza.secnetix.de> In-Reply-To: <200702121809.l1CI9rBq065457@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Desired behaviour of "ifconfig -alias" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2007 23:26:40 -0000 Oliver Fromme wrote: > But you called it "confusing". That's just your personal > perception. It doesn't mean it is confusing to everybody. > If asked what -alias does, would you really reply "it removes the primary IP, while leaving the alias?" Be honest here. > Also note that it doesn't hurt anybody. If you run RELENG_6_2, and a jail fails to start, this command is called. And instead of unaliasing the jail's alias, it (because of a bug in the shipped rc.d scripts), it removes the primary IP. So that is a real life, non-third-party incident, where a machine was knocked off-line unexpectedly, because of this behavior. Sure, it didn't *hurt* me, but knocking a machine off-line is a pretty serious side effect, especially when it isn't documented. Errors in the other direction are more likely to result in a machine remaining reachable. Fortunately, it appears that a fairly strong consensus is appearing in support of an eventual refinement of this behavior. Best Regards, Kevin Way