> > ...
> >
> >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.

Fair enough: keep in mind that you can use properties for this, too.
e.g. you might have one service but this daemon may or may not start
based upon a configurable property.

> 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

Sounds reasonable: I would continue working at that level, generalizing
out to the list of administrative tasks you need to support, and then work
back to the services once you've got that part done.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

Reply via email to