(This email is being sent in preparation for putting together a fast track to go together with these CRs.)
In attending to 6236881, we're currently looking at turning svc:/network/ipfilter up into 6 services in order to get the correct level of access via "refresh" and "start"/"stop" methods to managing related data. The new list of services is currently planned to be: svc:/network/ipfilter (milestone) svc:/network/ipfilter/ipf svc:/network/ipfilter/ipmon svc:/network/ipfilter/ippool svc:/network/ipfilter/ipfnat svc:/network/ipfilter/ipfconf An unavoidable part of this change will be that administrators will be expected to change their behaviour from: svcadm enable ipfilter to svcadm enable -r ipfilter but I cannot see any other way around this if the service is to be broken up in a meaningful manner. Because this will change the nature of svc:/network/ipfilter from a service to a milestone, we will need to propogate the "enable"d-ness of this service through to all of the others (above) to correctly reflect previous in the new environment with those settings prior to BFU and/or upgrades. To handle this, it appears necessary to use the file /var/svc/profile/upgrade and establish a contract with PSARC/2002/547, correct? On a seperate note... In putting together the dependency graph, what I would have liked would be to have a link between services that was heavier than "optional_all" but lighter than "require_all". What I was looking for was to be able to say: - start X if Y has started or start X if Y is disabled - wait for Y to finish starting and then start X In this, "svcadm enable X" if Y is disabled does not enable Y nor stop X from reaching online. However, if Y is in maintainence, then "svcadm enable X" should wait until Y is online. Should this be an RFE for SMF or does this expression of a dependency relationship between services raise a red flag to others? As it is, we've opted to use "optional_all" here. For those internal to Sun, if you want to see, in detail, what the current manifest files look like, point your browser at: http://greatwall.prc/~zf203873/cr6236881/ Darren
