Michael Shapiro wrote: > ... > >Again, I'm not the expert on your thing, but if you want more input think >about what you're proposing from this perspective and write it down (you'll >need this for ARC anyway) and send it out. At first glance, it looks to me >like you're exporting way too much of your internal machinery as opposed to >the administrative concepts of "I have not asked for IP filtering" or >"I want IP filtering with the following configuration options" or >"IP filtering failed to be be configured and now needs to be fixed". >
Yes, I think you're right. It didn't dawn on me until I read the comments from yourself and Jim that perhaps I wasn't seeing the forest for the trees here. What I thought was the right thing to do was to bring out all of the old interaction with the init script into discrete services, without thinking about what the real problem was: - an administration interface issue. What I think would be of better benefit would be a front end program (or shell script) that provided the means to: - reload ipfilter/NAT/pool information; - flush internal tables. Change the service to: - restart the ipmon daemon if it fails; - provide some service knobs, such as ipf_enabled, ipnat_enabled that the startup method can use as a guide for what to start up; - continue to stop/start all of the respective components (as it does today). This preserves the current administration model of having a single service to use with svcadm but increases its flexibility. The only questionable part of this model is if someone wanted to disable the ipmon daemon but leave the other parts active. What I think is being called for here is something along the lines of an interface like this: ipfadm firewall start ipfadm nat reload ipfadm ipmon stop ipfadm status and use ipfadm as an interface to the components that make up the IPFilter service that is enabled/disabled by SMF. Darren
