dual boot kernels (pf and ipfw)

D

doughyi8u

I'm trying to boot between two different kernels (one with ipfw and the other with pf). The problem is I don't want to worry about switching rc.conf entires to accomadate what kernel I'm starting.

I've been wondering if there's a way to write a shell script or something to make rc.conf fit what kernel I'm using (i.e. firewall_enable="YES").

if I want pf to work then firewall_enable="YES" should be:
#firewall_enable=YES *uses comment

if this can be done where should I put the shell script to do this?
 
As rc.conf is shell script itself, you could check value of [cmd=""]uname -i[/cmd] or [cmd=""]kldstat -v | grep ipfw[/cmd](if you have firewalls built in kernel) and use appropriate enable in there.
 
Hm, /etc/rc.conf is a shell script, but it is not really executed as such (i.e. to perform system actions). It is called upon to set 'sourced variables'. As such, I don't believe a simple command-line instruction will succeed because of the context in which it is called. It would be if it were /etc/rc.local. but that's likely too late in the process.
 
bummer. I just realized myself that rc.conf isn't executed/run from earlier enough in the boot process to matter. uname failed right after the drive was mounted.

Is there any other way of doing this?

Thanks for the help.
 
I was just wondering: if kernel 1 has pf in it, and not ipfw, and kernel 2 has ipfw in it, and not pf, won't using settings for both in /etc/rc.conf simply lead to the irrelevant settings being ignored?

I'm not sure whether something like pf_enable="YES" in /etc/rc.conf will prevent kernel 2 (without pf in it) from booting, vice versa.

It may throw some errors ("No support for pf found in kernel" or something similar), but it should not impede the boot process. Of course you must make sure that they're not kld-loaded as modules -- they must exist in the kernel only!

Something to try out, I guess.
 
DutchDaemon said:
I was just wondering: if kernel 1 has pf in it, and not ipfw, and kernel 2 has ipfw in it, and not pf, won't using settings for both in /etc/rc.conf simply lead to the irrelevant settings being ignored?

I'm not sure whether something like pf_enable="YES" in /etc/rc.conf will prevent kernel 2 (without pf in it) from booting, vice versa.
Click to expand...
It will just load module then :)
It may throw some errors ("No support for pf found in kernel" or something similar), but it should not impede the boot process. Of course you must make sure that they're not kld-loaded as modules -- they must exist in the kernel only!

Something to try out, I guess.
Click to expand...

And I understand that my idea of using rc.conf for this isn't too correct, sorry. I'm always forgetting that rc.conf is used far more than once. :(
 
I didn't know pf could be compiled into the kernel. What is the option for that?

I'm also concerned with the rules loading at boot time. As it is right now, there's some confusion. The rules were loading at boot time when I booted into kernel.ipfw but now I have to run /etc/netstart to get the rules to load.
 
I figured out why the rules weren't being loaded at boot time. I didn't include the full path to the ruleset (/etc/rc.firewall).

I'm still worried about how to boot between kernels without there being any confusion.
 
doughyi8u said:
I didn't know pf could be compiled into the kernel. What is the option for that?
Click to expand...

See LINT (# make LINT):

Code: 
device          pf
device          pflog
device          pfsync
 
what file reads rc.conf to set firewall ruleset files etc? The way it is now, even if I start up under the kernel.pf (not kernel.ipfw) the ipfw ruleset file (rc.firewall and rc.firewall6) are loaded.

Is it possible to find the script that reads in the firewallscript from rc.conf and make that file start the rulesets from files according to the output of uname -i as previously mentioned?

I'm really just afraid of making my system unbootable but have thought of modifying netstart under /etc.

Thanks again for the help.
 
I just looked in the netstart script and it says it's obseleted and not called anymore because all scripts are run in rc.d.

Would it be safe to modify pf and ipfw to set the firewall rules etc?
 
Did you disable the pf and ipfw modules? Because even if you have only pf in the kernel, if the ipfw module can be loaded and /etc/rc.conf says it should be, it will be. I don't know what happens when /etc/rc.conf calls for ipfw and it's not in the kernel and not available as a module, but that was the test I was talking about.
 
Why use two separate kernels? Why not build a kernel without either of pf or ipfw, and then just use /etc/rc.conf to select between them (the one with enable=yes gets used and the kernel modules loaded)?

If you must use two separate kernels, then you can write your own RC script that will edit /etc/rc.conf.local to set/comment the correct variables based on the output of kldstat -v|grep <module>.

For example, you could have an rc.conf.template like so (using whatever the correct RC variables are for PF and IPFW -- I use custom scripts for firewalling, so don't know what they are):
Code: 
%%PF%%pf_enable="YES"
%%IPFW%%ipfirewall_enable="whatever"

In the script, check the output of [cmd=""]kldstat -v | grep pf[/cmd]. If it's there, then run
Code: 
sed "s|%%PF%%||" /etc/rc.conf.template > /etc/rc.conf.local
sed "s|%%IPFW%%|#|" /etc/rc.conf.template >> /etc/rc.conf.loca

And do the reverse for IPFW.

Put the RC script into /usr/local/etc/rc.d/, and set it to run BEFORE NETWORKING.

See the Handbook and Porter's Handbook for information on writing RC scripts.
 
I got it figured out. I added some code to the /etc/rc.d/ipfw /etc/rc.d/ip6fw and /etc/rc.d/pf scripts that test uname -i and exits if the kernel in question not loaded. Thanks for your help :)
 
You must log in or register to reply here.
Back
Top