Quoth Kacheong Poon on Fri, Oct 06, 2006 at 05:41:01PM +0800:
> David Bustos wrote:
> > You are correct; a plain svcadm will take precedence over all NWAM
> > profiles, so it will last forever, like it does today.  I am planning on
> > adding an option which will allow a user to specify that the change
> > should be made to a specific profile (-P profilename).  NWAM shouldn't
> > have to worry about anything in this area.
> 
> Suppose a user does not specify a particular profile, does
> it mean that the change will be applied to all profiles?
> Or does it mean that the service is now "outside" the control
> of any profile?

The latter.  See http://opensolaris.org/os/project/smf-profiles/Design .

>                  I ask because it is still not clear to me
> how things work.  In the current draft, network services
> are enabled/disabled by the NWAM framework explicitly at the
> "right" time.  If enabling a service manually means that the
> service is now outside the control of any profile, that service
> may not be started at the "right" time by NWAM.  If enabling/
> disabling a network service without specifying a particular
> profile just means that the change is applied to all network
> profiles, I guess it should be fine.

You are correct.  The ideal behavior in the new model is clashing with
a hard requirement.  On the one hand, it seems likely that most people
using svcadm will only mean for the effect to last while the current
profile is in effect, and if NWAM changes the profile, it would be ok to
reverse the setting if the profile calls for it.  On the other hand, on
Solaris 10, svcadm changes last forever.  Since we have to retain the
latter behavior for backwards compatibility, it means people in the
former situation will be confused.

So first we have to allow the user to express the intention "I want this
to last as long as the current profile is in effect".  That's what -P
will be for.  Second we have to do our best to mitigate the confusion of
a user expecting plain svcadm to operate on the current profile.  One
way to do so would be to add logic to svcadm -v to say "Warning: this
setting will override the settings you have in profiles X, Y, and Z",
and encourage people to use svcadm -v interactively.  (I think this
probably points to a mistake in svcadm: we should have made optionless
svcadm interactive, and forced scripts to use svcadm -q.  But now users
may have scripts which use optionless svcadm, so we can't provide any
informative feedback to the user.)  Another way would be write NWAM so
that when it activates a profile, it can tell whether any of its
properties are overridden, and it can warn the user.  If the user isn't
logged in, though, that would imply that we'd have to send email or
something, which seems weird.


David

Reply via email to