> 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 tha
> 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 ste
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?
Ha
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 w
> 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 "impro
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 p
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 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_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 so
>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 a
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 Fumerol
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: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 d
13 matches
Mail list logo
