Andrew Gabriel wrote: > Tony Nguyen wrote: >> Andrew Gabriel wrote: >>> 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? > > No. The manpage is for the ipf(1M) command, and it makes no sense to > remove the example usage of the very command the manpage is describing. > I think that an "advanced user" is likely to start ipfilter with SMF, > and manipulate it dynamically with the ipf(1M) and/or ipnat(1M) commands > thereafter (at least, I do).
I see. > > It would make sense to add the SMF command example too, and a > description of when you should use one or the other. The ipf(1M) and > ipnat(1M) commands are much more fully featured than you can access via > SMF, so SMF isn't a replacement for them, except in the most simple of > cases. (Strangely, the ipfilter SMF method script contains other useful > functions such as reipf and reipnat, but SMF has no mechanism for > calling them.) I agree that ipf command features can't be replaced by the current SMF. In this specific example, the three ipf commands can be replaced by a single svcadm restart command so it was really tempting :) > Alternatively, you could take the view that the ipf(1M) and ipnat(1M) > (and ippool(1M)?) manpages are only appropriate for "advanced users" > anyway. You could move all the detailed ipfilter SMF instructions to the > ipfilter(5) manpage, and then include only an appropriate cross > reference from each of the "advanced user" command manpages. I think > that makes most sense. How about leaving the example intact and add the boilerplate phrase to ipfilter(5) which says ipfilter is managed by SMF under network/ipfilter and administrative actions should be done via svcadm? > > However, my main concern was that you aren't proposing to change or > disable or decommit/obsolete the direct use of ipf(1M) and ipnat(1M) > commands, which it looks like you aren't, so that's OK. > Correct, we are not obsoleting direct use of ipf. Much appreciated, tony
