> > In addition to Zhijun's email, I hope the description above > has answered this? > > Darren >
Let me replay Zhijun's summary before replying to this: > "ipf" is responsible for checking whether pfil is plumbed on NICs, and > restart pfild. > It is the basic service which all other services depend on. > "ipfconf" is responsible for flushing the filter rules and loading rules > from ipf.conf > "ipfnat" is responsible for flushing NAT rules and loading rules from > ipnat.conf > "ippool" is responsible for flushing ippool and loading rules from > ippool.conf > "ipmon" is responsible for managing ipmon daemon > and "ipfilter", is to be made a milestone I think it's important to understand that the purpose of having separate service instances is really to achieve two objectives: - To create appropriate failure boundaries in the system (i.e. if a s/w or h/w error occurs in a process, what is the boundary for restart or what is the boundary containing the thing which is broken). - To give administrators and system integrators discrete control over an object which more closely resembles their semantic intent (e.g. "disable NFS server functionality" as opposed to "I know that NFS server functionality current includes two daemons statd and lockd"). Service FMRI are not the 1:1 with processes, nor are they the same as discrete functional subcomponents of a service. In other words, if in order to start service S1 I need to complete steps A, B, and C, where B depends on A and A depends on B, that doesn't mean that A B and C should be distinct FMRIs. In particular because doing so may contradict one or both principles above. I'm not an ipfilter expert, but it appears to me that some of what you propose above is exporting a bunch of bootstrapping steps as separate services. For example, what does it mean for ipfconf and ipfnat to fail independently of one another? Isn't that just part of starting this thing? Are these things which need to be discretely disabled by the administrator as actual services or failure boundaries? i.e. what does it mean for someone to individually disable each of these things? Remember that you can also offer properties or the presence/absence of configuration files to determine the behavior of something (e.g. if I have a NAT rule set then load it). 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". -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
