On Fri, Dec 12, 2008 at 04:45:22PM -0800, Liane Praza wrote: > Renee Danson wrote: >> The original problem we were trying to solve with the network/location >> service (and the reason it's an smf service) was how to cause all the >> services which have configuration that's updated when a new location is >> activated (I'll call these location-related services) to notice this >> change. We could have nwamd walk through and refresh or restart each >> one in turn; or we could take advantage of the "restart_on" dependency >> that the smf framework offers. If each of the location-related services >> has the appropriate restart_on refresh dependency on the network/location >> service, all we need to do is refresh that service, and the changes will >> ripple out to all the other location-related services. > > What if I just gave you a simplified profiles implementation which took a > profile of service properties, applied them, and did a refresh? I could do > that quite quickly if it would avoid all of this. > > You'd then set the alternate configuration file as a property in the > *profile*, rather than copying files around. Most services support the > alternate config file (which Jim also suggested) nicely, and it'd be > trivial to add to ones that didn't bother yet. The move to Enhanced > Profiles will be very easy then too.
I'll need to think about it a bit more; but at first blush, I think that would be extremely helpful. How soon is "quite quickly"? We definitely try to use service properties where possible (setting an alternate config file path, for example); adding that to the ones that don't currently was a direction we wanted to move in, as well. However, other things we're installing aren't related to a service at all--which might be one fly in the Enhanced Profiles ointment. -renee
