Jerry,
This is very valuable because it would remove the most significant obstacle to
"software delivery via zones."
A couple of questions inline.
Jerry Jelinek wrote:
Enclosed is a draft of an ARC fast-track proposal I have been working on
recently, in-between a few other things. I would like to submit this for
ARC review shortly but I wanted to send this out to see if anybody had any
comments before I do that. I have cc-ed the install-discuss alias as well,
since there is some overlap, although this is probably most interesting to
zones folks.
One additional comment. I believe this proposal should also address the
recurring question about being able to migrate a zone from sun4u to sun4v
(and back).
Please send me any comments or questions.
Thanks, Jerry
---
SUMMARY:
This fast-track enhances the Solaris Zones [1] subsystem to address an
existing RFE [2] requesting the ability to update a non-global zone when
migrating from one machine to another.
Currently when we migrate a zone we validate that the destination host has
the same pkg versions and patches for the zone-dependent packages as were
installed on the source host. This is described in the zone migration ARC
case [3]. While this is safe and ensures that the new host is capable of
properly supporting the zone, it is also very restrictive. With this
enhancement, if the new host has higher versions of the zone-dependent
pkgs,
This is probably out of scope for this project, but "software delivery via
zones" creates a potential security risk: software delivered via this method
could have a limitpriv setting which is inappropriate in certain environments.
"Zone migration best practices" should include "after 'zoneadm -z ... attach',
review the limitpriv setting with 'zonecfg -z ... info'". Should we also
warn the user who just attached a zone that has a non-default limitpriv setting?
A different approach would be a mechanism to inspect the SUNWdetached.xml file
and list its zonecfg-related contents *before* performing the attach. This
would satisfy those organizations which are concerned by the possible omission
of the "review zone's limitpriv" step.
Should either of those be include in a separate CR?
or higher versions of patches for those pkgs, then when we attach the
zone to the new host we will enable an update of the pkgs in the zone to
match the new host.
Patch binding is requested for this "update on attach" capability. The
stability of these interfaces is documented in the interface table below.
DETAILS:
"Update on attach" is different from a traditional zone upgrade. In the
traditional upgrade all native zones are upgraded as part of upgrading the
base system using a standard Solaris media image as the source for the pkgs
to upgrade to. Pkg operations on pkgs with the SUNW_ALLZONES attribute
set must be run from the global zone, the operation will be performed on
all native zones, and this behavior is built-in to the pkg commands.
With "update on attach" we are only updating a single zone. We cannot
depend on the basic pkg behavior which updates all zones when a pkg is
installed in the global zone. We cannot use standard Solaris media since
the host can have a variety of patches installed which have updated the
base system pkgs beyond any specific Solaris release.
Instead what we want to do is similar to what happens when a zone is
initially installed. The spooled pkg data and global zone files are the
source for installing the zone. In this way the zone is installed with the
correct pkg versions along with any patches that have been applied to those
pkgs.
Just looking for a clarification: if the intent is for the resultant zone to
have the same set of pkgs as a newly created zone, will this method add any
pkgs which:
1) do not exist in the detached zone
2) would be in newly created zones
We can do something similar for "update on attach". The zone 'attach'
validation already generates a list of mismatched pkg versions and patches.
We can use this information to determine which dependent pkgs need to be
updated so that the zone can run properly on the new host. We will remove
the obsolete versions of those pkgs and install the up-to-date version from
the pkg data spooled in the global zone. This procedure will preserve any
editable or volatile files that are delivered by these pkgs. The normal pkg
install scripts and class action scripts are run as part of this process so
any updates performed by these scripts will take place. As described in
[3] the dependent pkgs are those that have the SUNW_PKG_ALLZONES=true pkg
attribute as well as any pkgs installed in an inherited-pkg-dir. Only
these pkgs will be updated to match the new host.
--------------------------------------------------------------------------
Jeff VICTOR Sun Microsystems jeff.victor @ sun.com
OS Ambassador Sr. Technical Specialist
Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq
--------------------------------------------------------------------------
_______________________________________________
zones-discuss mailing list
[email protected]
