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