Enrico Perla wrote:
>
> Anyway, as Tony explained in previous emails, the aim here is a Solaris
> tool, not a generic management tool, so probably all the discussion doesn't
> really apply. [1]
>
I don't think that point is sufficient to dismiss the lack of
abstraction for services manifest contents. Only the policy above and
bellow services can be a private API between ipfilter and vpanels.
Needing something in every network service is creating a public API and
the syntax and reasons for such a burden both have to be fully considered.
If we do remote attestation to network status (see
www.trustedcomputinggroup.org) or we give 3rd party firewalls equal
access (see www.checkpoint.com) we have situations where we want to know
the same things as ipfilter about the relation between services and the
network, but ipfilter is not an intermediary and we would not want to
parse its syntax.
I think a service manifest should describe network use very plainly
in terms of transport ports, RPC service, etc, and the intended locality
(i.e. loopback, subnet, org, global) and perhaps have smf turn this into
a new network form of FMRI. A bonus would be letting the service
register a mechanism for finding the subset of specific peers and other
micro-state for the network FMRIs it registered.
If it is just ipfilter specific data then I think the burden is on
vpanels/ipfilter to figure out and maintain a (probably eternally out of
sync) database of service FMRI to ipfilter rule constructs.
Even with the entirely private interface, I think ipf_methods of
arbitrary ipf syntax will probably be a burden to vpanels/ipfilter
compared to more abstract data. For example what happens if we decide
it needs to support per service NAT, will random ipf(4) syntax fit
neatly in the ipnat(4) rules or do we now need a separate ipnat_method
with very similar information?
-Will
