From owner-freebsd-questions@FreeBSD.ORG Thu Jan 25 00:20:52 2007 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72DD816A403 for ; Thu, 25 Jan 2007 00:20:52 +0000 (UTC) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (prime.gushi.org [72.9.101.130]) by mx1.freebsd.org (Postfix) with ESMTP id 32E8E13C4D9 for ; Thu, 25 Jan 2007 00:20:52 +0000 (UTC) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (localhost [127.0.0.1]) by prime.gushi.org (8.13.8/8.13.8) with ESMTP id l0P0KnF6049842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jan 2007 19:20:49 -0500 (EST) (envelope-from danm@prime.gushi.org) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=prime.gushi.org; s=primegushiorg; t=1169684449; bh=V2y5Bh47sjRjgOewGZBfAoUTfeE=; h=DomainKey-Signature: Received:Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=d0N/3OIL4eVxQm5ZlSd+3WcaHJ0WAywgrONdM9 0omucxIGHLk/3XD6zpWqYORiMRf+f1PNLX9gBc7NaykfIiLw== DomainKey-Signature: a=rsa-sha1; s=primegushiorg; d=prime.gushi.org; c=nofws; q=dns; h=received:date:from:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=KomUShJPx1Bly/qCLyMqTrPhgb4bZdVP2U+OofZMHa6jpO1Zi6pu8s+R7GTM+GDop hkSNOM+pRBz8cknoTQftg== Received: (from danm@localhost) by prime.gushi.org (8.13.8/8.13.6/Submit) id l0P0Km3B049822; Wed, 24 Jan 2007 19:20:48 -0500 (EST) (envelope-from danm) Date: Wed, 24 Jan 2007 19:20:47 -0500 (EST) From: "Dan Mahoney, System Admin" To: Kevin Kinsey In-Reply-To: <45B7D086.7040400@daleco.biz> Message-ID: <20070124185059.P55095@prime.gushi.org> References: <20070124152310.E82156@prime.gushi.org> <45B7D086.7040400@daleco.biz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: questions@freebsd.org Subject: Re: Problem with "ipfw flush" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 00:20:52 -0000 On Wed, 24 Jan 2007, Kevin Kinsey wrote: > Dan Mahoney, System Admin wrote: >> Hey all. >> >> In trying to tweak my firewall setup I'm using a file called >> /etc/ipfw.rules >> >> However, it seems even though I copy my rules perfectly to that file, the >> system freezes up and locks me out when I do: > > /usr/share/examples/ipfw/change_rules.sh? That is a very cool script, however, it appears as though it calls firewall_script on line 131 with "sh", not with ipfw. nohup sh ${firewall_script} ${firewall_type}.new Whereas, etc/rc.firewall calls ipfw on line 299 via the "ipfw" command: ${fwcmd} ${firewall_flags} ${firewall_type} The difference is that the resulting rules file would not be parseable by "sh" since the lines in the file would not contain the "ipfw" command but only the arguments. As one's in "examples" and the other's in a live startup script, I'd assume the latter to be the correct method. That said, this still does not tell me why a subsequent flush-and-rerun isn't working via ssh. It works totally fine via the command line, but over ssh it gives: Jan 24 19:10:55 ads-bsh-fwa4 sshd[845]: fatal: Write failed: Permission denied on the console (but by that point my connection's already dropped). However, this shouldn't actually stop an already-typed command, should it? Additionally, it doesn't appear that /etc/rc.firewall has the smarts to do this, as the "stop" command it lists only disables the kernel firewall structure via sysctl, but does NOT flush the rules, pipes, counts, or the like, so it's not a true "restart". (the idea being that otherwise, every rule will be added twice -- the flush is a necessary step there). Even if I add the "flush" command directly to /etc/ipfw.rules, and run ipfw -f /etc/ipfw.rules right from the command line, my connection gets dropped and the rest of the commands do not run. In experimenting a bit more, I've found that I can do: nohup ipfw -f /etc/ipfw.rules This allows the rest of the ipfw command to run, but the HUP-on-disconnect still doesn't explain why the command doesn't even finish running. -Dan -- "What's with the server farm down in the basement?" -Spider, Three Skulls Commons at Selden House, 4/15/00 --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------