Darren J Moffat wrote: > I'm still not convinced that there shouldn't be multiple different > services here. There are as far as I can tell different fault > boundaries and the need to restart independently between filter, nat > and ipmon. So why should they be a single service under SMF with > a new ipfadm command that does make the distinction that you can > restart them. > > I'm really not getting it, sorry.
What you don't see, at present, is the implicit relationship between the "sub-services" within IPFilter. If the these "sub-services" are extracted out, then the new services need to be defined such that the relationship between them remains correct. I'm not sure that the current definitions available within the SMF schema allow for an adequate map to be formed to represent this. On top of this comes the question of whether it is beneficial to expose this level of detail about a single service to administrators, not to mention that it is no longer possible to have both more fine grained control as well as preserving the simple "svcadm enable ipfilter" that people use today. Taking the position of we need to be able to manage each specific fault boundary, individually, then almost every daemon/command requires its own SMF service as each may fail or need managing in its own manner. I don't think this scales well - it buries the important service boundaries and definitions with layers of obscurity. For example, what today comprises the complete set of services required to enable an NFS server? The dependency map shows you what is needed to start nfs/server, but what is the set of services that define an NFS server operating? To extend this to ipfilter, if we break up network/ipfilter into network/ipnat, network/ipmon and network/ipfilter, observing whether or not ipfilter is enabled, at the SMF level, becomes more difficult. Reading this thread and the NFS thread, it is becoming clearer to me that we need to think about expanding the depth of what SMF can provide, so that maybe we can have (for example) both major and minor fault boundaries. Darren
