On 8/29/06, Darren Reed <Darren.Reed at sun.com> wrote: > (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 could you rename ipfiler to ipfile.base or main, then use ipfilter without the -r to restart all of the subcomponents, and retain backware compatibility?
James Dickens uadmin.blogspot.com > > 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 > > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org >
