I know someone who is willing to substantially revise the install
process, BUT:
That's too much of a BUT. :)
1)They will want to keep it proprietary for commercial
use for a period of at least a year, and that would
Which is why it wouldn't be FreeBSD. FreeBSD is free and that
On Thu, Oct 26, 2000 at 03:10:35PM -0700, David O'Brien wrote:
So one doesn't have to change the source, would you be willing to add
WANT_foo logic so one could just set it in /etc/make.conf? Or add
${IPFIREWALL_OPTS} to CFLAGS and then IPFIREWALL_OPTS could be set in
/etc/make.conf?
I've also sent out numerous appeals to the various mailing lists for
someone, anyone, to come up with something better than sysinstall
which was somehow less grandiose than my own follow-on designs or,
failing that, to significantly revamp sysinstall itself. The fact
that nobody has stepped
On Thu, Oct 26, 2000 at 01:31:03PM -0700, Glen Gross wrote:
I built a 4.1.1 kernel, and the module was built, but when I load the ipfw
module with
#kldload ipfw
it defaults to a deny_all policy, even though I have default_to_accept in my
kernel configuration.
This makes it difficult
Thanks, I suppose I should have been able to figure that one out... if I could
log in! I will fix it when I get home. :-)
On Thursday, October 26, 2000 1:32 PM, Bill Fumerola [SMTP:[EMAIL PROTECTED]]
wrote:
On Thu, Oct 26, 2000 at 01:31:03PM -0700, Glen Gross wrote:
I built a 4.1.1
On Thu, Oct 26, 2000 at 01:36:40PM -0700, Glen Gross wrote:
Thanks, I suppose I should have been able to figure that one out... if I could
log in! I will fix it when I get home. :-)
Playing with firewalls without out-of-band (serial console, nocmonkey, etc) is
dangerous.
--
Bill Fumerola
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
On Thu, Oct 26, 2000 at 04:31:57PM -0400, Bill Fumerola wrote:
#If you want it verbose
#CFLAGS+= -DIPFIREWALL_VERBOSE
#CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100
#
#If you want it to pass all packets by default
#CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT
So one doesn't have to change the source,
On 26-Oct-00 David O'Brien wrote:
On Thu, Oct 26, 2000 at 04:31:57PM -0400, Bill Fumerola wrote:
#If you want it verbose
#CFLAGS+= -DIPFIREWALL_VERBOSE
#CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100
#
#If you want it to pass all packets by default
#CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT
So
On Thu, Oct 26, 2000 at 03:18:55PM -0700, John Baldwin wrote:
Ugh, no. Peter's forthcoming config(8) changes will allow you to
specify kernel options to use when building modules (actually, it
builds modules in the same environment as the kernel) to properly
handle this. Just be patient
On 26-Oct-00 David O'Brien wrote:
On Thu, Oct 26, 2000 at 03:18:55PM -0700, John Baldwin wrote:
Ugh, no. Peter's forthcoming config(8) changes will allow you to
specify kernel options to use when building modules (actually, it
builds modules in the same environment as the kernel) to
I disagree. Vaporware (example Son of Sysinstall) has kept us from
improving things until the fabled newstuff arrives.
That's actually a bad example since just a brief glance at the cvs
commit logs for sysinstall will show that a number of fingers have
dived into it over the years and
On Thu, Oct 26, 2000 at 08:47:35PM -0700, Jordan Hubbard wrote:
G. Hot button. :)
Quite sorry, didn't mean to push any buttons. But once again I just got
hit by having a anchient /stand/sysinstall not be able to find any
devices when I wanted to use it's Fdisk editor. Way back when I
13 matches
Mail list logo
