Re: ipfw question.
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 includes sysinstall and the pkg_install tools, a situation that parallels this one since Walnut Creek CDROM essentially paid me to write them. If WC had turned pointy-haired about this and decided not to allow me to release them, however, we'd still be using shell script installers (or an installer from somebody with less pointy-haired bosses) since that would have been completely unacceptable. 2)They will want to call their stuff FreeBSD, but that .. and which is why they couldn't call their stuff FreeBSD. You can't have your cake and eat it too. I know you said FWIW, but I just wanted to point out that it was actually worth very little. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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?
Having read the rest of this thread my position is "willing, able, but
unsure if its needed". I'll talk with Peter when he's back on this
side of the Pacific.
--
Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
[EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 up to the plate has, I feel, nothing to do with vaporware, it has to do with certain problems simply being icky and unpleasant to deal with. If such was not the case, you'd think one of the other *BSDs would have done it if not us. Let's also not forget that Caldera had to PAY Trolltech to do their fancy installer and then Red Hat came along and substantially pinched off of that one, so even the vastly better-funded and staffed Linux projects haven't really managed to crack the nut just on volunteer labor alone. FWIW: I know someone who is willing to substantially revise the install process, BUT: 1) They will want to keep it proprietary for commercial use for a period of at least a year, and that would mean probably keeping it out of the official source tree for that period of time. As you note, it is icky and unpleasent to deal with, and they will expect to recoup their investment. 2) They will want to call their stuff FreeBSD, but that has historically been vetoed, unless the installation images are exactly the same as what you can download of the net or buy from Walnut Creek. During that year, they wouldn't be. Obviously, #1 would potentially cannibalize the WC CDROM market for FreeBSD CDROMs, assuming they do a decent job of things. Obviously, #2 means that they people willing to do the work are interested in a "RedHat FreeBSD"-like play, which may not be in everyones interest. As I said: FWIW. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 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?
For now it appears that I am locked out, until I can access the console.
Your kernel configuration has ABSOLUTLY NOTHING to do with your module builds.
[hawk-billf] /usr/src cat sys/modules/ipfw/Makefile
# $FreeBSD: src/sys/modules/ipfw/Makefile,v 1.13 2000/05/27 01:13:50 peter Exp $
.PATH: ${.CURDIR}/../../netinet
KMOD= ipfw
SRCS= ip_fw.c
NOMAN=
CFLAGS+= -DIPFIREWALL
#
#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
#
Guess what you should uncomment
--
Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
[EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: ipfw question.
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 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 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?
For now it appears that I am locked out, until I can access the console.
Your kernel configuration has ABSOLUTLY NOTHING to do with your module
builds.
[hawk-billf] /usr/src cat sys/modules/ipfw/Makefile
# $FreeBSD: src/sys/modules/ipfw/Makefile,v 1.13 2000/05/27 01:13:50 peter
Exp
$
.PATH: ${.CURDIR}/../../netinet
KMOD= ipfw
SRCS= ip_fw.c
NOMAN=
CFLAGS+= -DIPFIREWALL
#
#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
#
Guess what you should uncomment
--
Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Glen M. Gross
Unix Technical Support Specialist
Symark Software
5716 Corsa Avenue, Suite 200
Westlake Village, CA 91362
http://www.symark.com
[EMAIL PROTECTED]
Main: 800-234-9072 or 818-865-6100
Main fax: 818-889-1894
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 - Network Architect, BOFH / Chimes, Inc. [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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, 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?
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 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?
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 until we have the right solution
finished and in the tree.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 until we have the right solution finished and in the tree. I disagree. Vaporware (example Son of Sysinstall) has kept us from improving things until the fabled newstuff arrives. Unless you have a strong commitment from Peter on a time frame, we need to offer an easy way to control the functionality of the ipfw module. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 properly handle this. Just be patient until we have the right solution finished and in the tree. I disagree. Vaporware (example Son of Sysinstall) has kept us from improving things until the fabled newstuff arrives. Code that is in his tree != vaporware (yes, I have seen an actual modified src tree with it in there) Unless you have a strong commitment from Peter on a time frame, we need to offer an easy way to control the functionality of the ipfw module. a) This is current. 5.0-release isn't next week, so we have time to get this done right. b) Any hacks we add now we have to then be backward compatibile with later on which increases the maintenance load. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 "improved" it (sometimes to the point of unusability! :). 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 up to the plate has, I feel, nothing to do with vaporware, it has to do with certain problems simply being icky and unpleasant to deal with. If such was not the case, you'd think one of the other *BSDs would have done it if not us. Let's also not forget that Caldera had to PAY Trolltech to do their fancy installer and then Red Hat came along and substantially pinched off of that one, so even the vastly better-funded and staffed Linux projects haven't really managed to crack the nut just on volunteer labor alone. G. Hot button. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw question.
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 wanted to hook both sysinstall and the instalation of its manpage into `make world', you said not to bother because it was going to be OBE'ed soon. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
