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
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
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
> 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