On Mon, Dec 08, 2008 at 01:30:18PM -0500, James Carlson wrote: > 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).
Ah, OK. > 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. Right. And my proposal is that services like svc:/network/nfs/server, which cannot run in NGZs should simply log and disable themselves if started in an NGZ. I.e., let the zone configuration here happen lazily. The main rationale for doing that is that it's easier to do that at runtime than at configuration time. Not only is looking into such a zone's SMF repository hard, but so is looking into its packaging (besides, the switch to IPS will make that even more obnoxious: code that needs to be thrown out later). Of course, it may be harder to fix all such services to self-disable in NGZs. > > 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. I wasn't proposing that it be made to be zone aware (though I gather that'd be nice). > 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." Indeed. _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
