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