Jerry Jelinek writes:
> > Can a user predict what these automatic changes will be?  After
> > import, is there a log of the changes or "adjustments" made?
> I assume you really mean which SMF services will be off, since
> the other changes are listed here in the case?


>  We can describe which
> SMF services will be deleted or disabled in general terms, but we
> really want this to be driven by the pkg metadata itself.  We'll probably
> also have a list of some well-known 3rd party services that don't work
> inside a zone, such as vxvm, which we'll turn off.  As with the S8 and
> S9 brands, there may need to be some manual tweaking of the services
> as part of the p2v process, although we've generally had good results
> with the S8 and S9 brands without a lot of manual work.

I can understand that some tweaking would end up being necessary, but
at least an outline of what's affected (if known) would probably be
good to include with the case materials.

> There will also be a log file for this p2v process.  I'll add that info to
> the case.


> > S10 has a number of new features over S8 and S9.  How do these factor
> > in?  For instance, what happens to the privileges required in order to
> > run the services contained in an archive?  (The user might need to
> > configure the zone so that the right set of non-default privileges are
> > granted.  Is there some new way to do this, or does the user need to
> > trouble-shoot failing services?)
> I am not planning on making any automated changes to the privileges available
> to the zone.  If this turns out to be an important issue, then we could
> look at that as a possible future enhancement.  The problem I see is that
> we don't have any data to automatically drive which services and apps need
> which privs.

Right; that's what I was getting at.  We don't carry that sort of
metadata around in any convenient form.

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

There are other things that work like this, such as ZFS delegations or
in network configuration, so there might be a broader issue here in
configuring the zone so that it can properly accept the archive.  I'm
not saying that I think it's unusable, but rather that there may be
non-trivial cases here where a good bit is left to the user's

(Then there are other cases, such as NL7C.  You might possibly want to
use that if you're in the global zone, but since you can't use it in a
non-global zone, and since the web server itself is perfectly
serviceable _without_ NL7C, translating over means simply removing
that from the configuration.  I'm guessing that sort of thing is a
manual operation.)

> >>      -a {path} - specifies a path to an archive to unpack into the zone
> >>      -d {path} - specifies a path to a tree of files as the source for the
> >>                  installation.
> > 
> > Just for clarification: does that '-d {path}' option point to a system
> > root?  Could I use "lumount" to mount up an inactive BE and turn it
> > into a zone?
> Yes, -d points to a system root, so your idea of turning a BE
> into a zone should work just fine.

OK; should point out that this is intended to be a system root.  (I
know, it should be "obvious," but since I had to ask anyway ...)

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

Reply via email to