On 7/20/06, James Dickens <[EMAIL PROTECTED]> wrote:
On 7/20/06, James Carlson <[EMAIL PROTECTED]> wrote:
> James Dickens writes:
> > The interface would be
> >
> >
> > #zoneadm –z zonename lock
> >
> > With the zone locked no changes in the global zone effects the
> > non-global zones.
> I'd suggest using a less general term ("pkg-lock", maybe?) and
> consider using zonecfg instead.
> So what happens with the default sparse-root zones?  If I have a zone
> locked and I try to remove a package from the global zone, what
> happens?  The bits are going to disappear from the non-global zone
> (because it's just using lofs mounts), but the packaging data won't be
> removed.  It'll be a phantom.  Similarly, adding packages becomes a
> bit strange.  Is this feature available only with whole-root zones?
I think if a package is removed from the global zone, its removed from
all zones. The lock would have no effect. Any thing else leaves too
much of a mess behind.

> What happens when the lock is disabled?  If I add another package to
> the global zone that depends on things that were added while the lock
> was enabled, does that work?  Do I get a flood of things hauled into
> the now-unlocked non-global zone by dependency, or does the pkgadd
> just fail?  The system is in a funny state at this point.

dependency managment has allways been left to the system
administrator, it would be up to them to deal with them now. Perhaps
we could add a command that would add a package installed in the
global into a non-global zone.

> What happens when a package has system-wide effects?  For example, if
> I remove a package containing a device driver from the global zone,
> there's no way that package can still exist in any non-global zone, is
> there?  It doesn't matter whether that lock flag is set -- because
> kernel modules exist only in the global zone, if that package is
> removed, the non-global zone (even a whole-root zone) will have to
> lose the device.

I think that package removes from the global zone should effect all
zones reguadless of lock state in a non-global zone.

> Otherwise, it looks like a fairly reasonable RFE to me, though I'd be
> a bit worried about the long-term administrative effects.  What
> distinguishes a pkgadd done for the purpose of adding new application
> software from a pkgadd done for the purpose of maintaining the system
> itself seems like a bit of a grey area.  (You mention patches, but
> patches likely aren't the only issue here.)
> Are you looking for someone to file the RFE, or are you planning to
> visit bugs.opensolaris.org?
I filed an RFE, haven't recieved my email with a bug number yet. But
will post the number to the list since apparently a few are interested
in this.



here are the RFE number, details if you want to take a look or add
your name to the list, its not on  bugs.opensolaris.org yet, and below
link is internal sun only apparently.

[Fwd: CR 6451092 Created P5 opensolaris/triage-queue add lock to
packages in non-global zones]   Inbox

*Synopsis*: add lock to packages in  non-global zones

*Change Request ID*: 6451092

> --
> James Carlson, KISS Network                    <[EMAIL PROTECTED]>
> Sun Microsystems / 1 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