From owner-freebsd-current Thu Oct 26 13:47:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn253.dh.casema.net [212.64.31.253]) by hub.freebsd.org (Postfix) with ESMTP id C492337B4C5 for ; Thu, 26 Oct 2000 13:47:20 -0700 (PDT) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.9.3/8.9.3) with ESMTP id WAA36891; Thu, 26 Oct 2000 22:58:58 +0200 (CEST) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20001026224731.00beec00@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Oct 2000 22:55:31 +0200 To: "ggross@symark.com" From: "Rogier R. Mulhuijzen" Subject: Re: ipfw question. Cc: freebsd-current@freebsd.org In-Reply-To: <01C03F50.FD62AD50.ggross@symark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >This makes it difficult to configure remotely without getting locked out >of the >system. >Is there a way to cause the ipfw module to default to a different policy upon >loading? I'm not sure about influencing modules with options in kernel config, I'll leave that to the pro's but you could as a workaround use: echo kldload ipfw > load_ipfw.sh echo ipfw add 65000 allow all from any to any >> load_ipfw.sh nohup sh load_ipfw.sh I vaguely remember stuffing them both on one commandline fails because the shell dies due to the block before the ipfw command is executed. Hence the nohup. >For now it appears that I am locked out, until I can access the console. That's what all the warnings about doing ipfw stuff remotely are for =) Doc "I have shot myself in the foot doing ipfw remotely too" Wilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message