Nicolas Williams writes: > On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote: > > I suppose it'd be possible to look through the SMF 'privileges' for > > the services that are still enabled, and then attempt to union those > > into the zone privileges ... but it's unclear if that's really the > > right approach, particularly for services that might be aware enough > > of zones to work in some other fashion when restricted by the > > environment. > > Shouldn't changes to privileges be backwards compatible? I can't quite > tell if privilege names and semantics are intended to be Committed or > not.
I'm not sure what you're talking about here, but I'm not referring to any sort of version-related compatibility issue. I'm explicitly assuming that all such issues are dealt with by the upgrade-on-attach feature (and that we're not yet addressing the S10-in-a-zone-on-OSOL issue). Instead, I'm talking about the required privileges in order to enable a given service inside a non-global zone. If a service is defined to be run inside the zone (based on the archive presented), then someone or something must make sure that the required privileges are granted to the zone, or the service is going to fail. It's a zone configuration issue. Currently, there's a default set of privileges that are granted to non-global zones. It's possible to modify that set (up to a point) with 'limitpriv'. There are some that can never be granted, and if those are needed, then enabling the service just isn't going to work at all. (Unless, somehow, the service itself detects this case dynamically and falls back to some smaller set of zone-friendly features.) > NGZs disabling themselves, and services that can be configured > differently to run in zones either disabling themselves or changing > their configuration (as in your NL7C example, though why shouldn't NL7C > be available in NGZs?). I don't think anyone's bothered to make it zone-aware. The reason I mentioned that one is because it's an interesting example of an edge case: "it could be in the archive being imported, but isn't actually required for normal operation, so you can ignore it if you don't know how to import it." -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org