From owner-freebsd-current Mon Dec 16 11: 4:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 720A737B401; Mon, 16 Dec 2002 11:04:51 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C552D43E4A; Mon, 16 Dec 2002 11:04:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id gBGJ4oOM067830; Mon, 16 Dec 2002 11:04:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id gBGJ4oVX067829; Mon, 16 Dec 2002 11:04:50 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Dec 2002 11:04:50 -0800 (PST) From: Matthew Dillon Message-Id: <200212161904.gBGJ4oVX067829@apollo.backplane.com> To: Ruslan Ermilov Cc: "David O'Brien" , current@FreeBSD.ORG Subject: Re: ipfw userland breaks again. References: <200212142025.aa99706@salmon.maths.tcd.ie> <200212142038.gBEKcDVv029924@apollo.backplane.com> <20021214204426.GA62058@dragon.nuxi.com> <200212142209.gBEM9D8p002479@apollo.backplane.com> <20021216174117.GB34320@sunbay.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :How this could be helpful in a remote upgrade scenario that has :IPFW ABI incompatibility issues? : :One alternative approach would be to not compile IPFW into a :kernel but rather have it loaded as a module. Then, you :install new kernel, edit out ipfw_enable=3D"YES" for the time :being, reboot with the new kernel, installworld, edit :ipfw_enable=3D"YES" back in, reboot, and you're done. : : :Cheers, :--=20 :Ruslan Ermilov Sysadmin and DBA, Well, the basic problem is that you don't actually know when the IPFW API is going to break. I do incremental upgrades most of the time and IPFW breaks maybe once every 5 upgrades. So for a manual upgrade it can be a severe inconvenience to have to deal with the possibility every time you upgrade. For an automated upgrade one can always automate and 'ipfw unbreak' (or 'ipfw open' as John just suggested to me) is not needed. What this patch does is allow you to upgrade via a serial console normally, without having to pay particular attention to IPFW, and if the IPFW API happens to break you can then simply 'ipfw unbreak' to get access to the network and then fix whatever broke. The only viable alternative that I've heard so far on the lists, other then 'Matt should rewrite the API so it doesn't break' is to have the installkernel and installworld targets check for ipfw incompatibility and install the new ipfw. Of course, this doesn't help if you have to revert the kernel. I still prefer the failsafe my solution supplies. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message