http://defect.opensolaris.org/bz/show_bug.cgi?id=11561
--- Comment #6 from tonyn <truong.q.nguyen at sun.com> 2009-09-24 21:39:06 UTC --- (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > [...] > > > > If the desired state is disabled, then disable then refresh is > > > > preferred since > > > > we'll avoid the costly rule generation operation. > > > > > > That won't happen when it is ultimately enabled again? > > > > > > How is 'disable ; refresh ; enable' different from 'disable ; enable'? > > > > The rules are dynamic and generated on each refresh or enable. > > Great. So the two are equivalent. > > > > > My point was to save the time it takes to generate rules if we know the > > service > > is going to be disabled. If the service should be enabled, then you can > > simply > > run svcadm refresh. > > Understood. There was disagreement in a technical discussion this morning > with > the majority thinking that 'disable ; enable' didn't update the running copy > and therefore 'disable ; refresh ; enable' was different from 'disable ; > enable'. That seemed counterintuitive to me. I wanted to understand the > possible solutions better. We had already (fuzzily) figured out that waiting > to do the refresh saved us the time we were wasting on the refresh before > disable. Ah, we should probably see that firewall configuration (repository running snapshot values) and IPFilter rules as slightly two different things though repository running snapshot values are used to generate IPFilter rules. Enabled services always use the running snapshot values as the active configuration. Thus, a refresh is necessary to update the running snapshot with new values, regardless of whether the service is enabled, so that the service will have the new configuration in its running snapshot. -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
