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