From owner-freebsd-bugs Sun Jun 13 13: 1: 2 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from veda.is (veda.is [193.4.230.1]) by hub.freebsd.org (Postfix) with ESMTP id 747CF14C12; Sun, 13 Jun 1999 13:01:00 -0700 (PDT) (envelope-from adam@veda.is) Received: (from adam@localhost) by veda.is (8.9.0/8.9.2) id UAA15624; Sun, 13 Jun 1999 20:00:58 GMT (envelope-from adam) From: Adam David Message-Id: <199906132000.UAA15624@veda.is> Subject: Re: kern/3244: ipfw flush closes connections In-Reply-To: from Dag-Erling Smorgrav at "Jun 13, 99 05:16:35 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Sun, 13 Jun 1999 20:00:57 +0000 (GMT) Cc: ru@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > writes: > > State-Changed-From-To: feedback->closed > > State-Changed-By: ru > > State-Changed-When: Fri Jun 11 03:19:08 PDT 1999 > > State-Changed-Why: > > Can't reproduce; originator doesn't respond. oops... I saw the feedback state message as it happens, it was an extraordinarily busy week here. > The correct reply is: this is perfectly normal behaviour. Even if you > background your firewall script, it will produce tons of output. > telnetd / sshd will attempt to send you that output, and will fail > since the firewall rules needed to let that output through aren't yet > installed. Depending on what shell you use, the script may continue to > run in the background (in which case you can just wait a few seconds > and log back in), or the shell may kill it when the telnet / ssh > session closes. The only safe way to avoid this is to redirect output > to a file (or /dev/null), or to disown the process (your shell will > still die, but not the script): > > # sh /etc/firewall >ipfw.out 2>&1 > > or > > # (sh /etc/firewall &) I think the latter works, and there was once a time when it did not. > In any case, you should not do stuff like that over a remote > connection. There's a good chance of locking yourself out. You should > instead to manual incremental changes: if you want to remove a rule, > remove it. If you want to add a rule, add it. If you want to change a > rule, add the correct version with a *higher* number than the > incorrect version, *then* remove the incorrect version. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no Good advice, and still requiring full attention to avoid lockout. -- Adam David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message