Andrew Gabriel wrote:
> I've looked through the new spec.
> 
> I have some questions about how the current method of configuring 
> IPfilter will continue to work in the new framework. (I have programs 
> which build ipf.conf and reapply it dynamically as needed, and I don't 
> have any interest in automatically allowing/denying access based on SMF 
> service states. I guess that makes me an "advanced user" in your 
> terminology.)
> 
> So, if I understand correctly, to enable current mode of operation, I 
> would issue the commands:
> 
> svccfg -s svc:/network/ipfilter: setprop firewall_config_default/policy 
> = custom
> svcadm enable svc:/network/ipfilter

Andrew,

We also need to specify the rules file:

svccfg -s svc:/network/ipfilter: setprop firewall_config_default/policy
= astring: "/foo/bar.conf"


> This needs clearly stating as an example on a manpage (ipf(1M) and/or 
> ipf(4)).

will do.

> 
> What happens on upgrade of a system with an existing ipf.conf file and 
> IPfilter enabled? Will you automatically do this? If not, how do you 
> handle upgrade?

Good catch, I almost missed this. Yes, we need to set the above values 
appropriate on upgrade, most likely via a profile/upgrade script.

> In the ipf(1M) manpage, you have removed the ipf and ipnat command 
> examples. This is incorrect -- these are still used and required for 
> current method of operation. You perhaps just need to add a comment that 
> these wouldn't be used if using the SMF framework to automatically build 
> firewall rules. You have also effectively removed the instructions for 
> changing filter rules without either rebooting or disabling IPfilter. It 
> is an important feature of IPfilter that it allows rules to be changed 
> dynamically without disabling it or rebooting the system, and this needs 
> to remain on the manpage. ipf(1M) is a committed interface and a key 
> part of the access to important features of IPfilter.
> 

Actually, I removed that section for correctness and consistency, 
independently of firewall. IPfilter is an SMF service and should really 
be managed via SMF commands, in this case:

"svcadm restart ipfilter" for "ipf -E"
"svcadm refresh ipfilter" for "ipf -f ipf.conf; ipf -f nat.conf"

The argument here is choices for the customer but it can also be a 
little confusing to have the man page shows starting network/ipfilter 
with SMF command and restart/refresh actions are done with non-SMF 
commands.  Does it make sense?

Thanks,
tony

Reply via email to