Darren.Reed at Sun.COM wrote: > Rather than create N different services for IPFilter, we've > gone with keeping the existing service name but allowing > SMF to be used to control what it does at a finer level.
What is the reason for this ? > We're planning on adding the following boolean properties: > configuration/ipf_enabled > configuration/ipnat_enabled > configuration/ippool_enabled > configuration/ipmon_enabled > > By default, all of these will ship "true" so that doing a > "svcadm enable ipfilter" will enable IPFilter with all of the > above active as it does today - no regression. Performing > a disable or enable on the ipfilter service will not cause > a change in any of the above properties. See below I don't think that is the only way to do this. > To manipulate these properties of the ipfilter service, > a new script called "ipfadm" is to be used as follows: > > ipfadm ipf <enable|disable|start|stop|status|restart|refresh> > ipfadm ipnat <enable|disable|start|stop|status|restart|refresh> > ipfadm ippool <enable|disable|start|stop|status|restart> > ipfadm ipmon <enable|disable|start|stop|status|restart|refresh> > ipfadm ipfilter <enable|disable|start|stop|status> Why ? This seems like adding a command for the sake of it to me. I don't see anything that description of ipfadm that you can't to today with svcadm and svcs, if you used a separate service for each of the things that make up IPfilter. If the desire is to be able to restart all of ipfilter in one command then I think you can easily do this by having an ipfilter service that depends on and causes restart off the subservices that represent filtering, nat etc. -- Darren J Moffat
