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.
> 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 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.
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
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 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.
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 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 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.
>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 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.
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: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
ipfw question.
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. Regards, 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