|
Replies:
19
-
Last Post:
Jun 6, 2007 11:58 AM
by: carlsonj
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
updating a zone when attaching
Posted:
Jun 4, 2007 5:54 AM
|
|
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, 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.
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.
We will ensure that we will only update a zone to a host running the same
or later version of the dependent pkgs. For example, if the new host has
a mix of higher and lower version patches as compared to the source host
then we will not allow an update during the attach.
By default the zone will not be updated during attach. Instead, the
existing output listing the pkgs that are out of sync will continue to
be printed. We will add a new option (-u) to the 'zoneadm attach'
subcommand. When this option is used then zoneadm will update the
necessary pkgs during the attach (assuming there are any to update).
Because the zone has previously booted and run on the source host it is
possible that there could be security issues with directly accessing the
zone's filesystem to remove and add pkgs to the zone. To protect against
this the pkg operations will be performed within the scratch zone [4]. The
scratch zone was defined to address this specific issue for upgrading
zones.
We cannot use the pkgrm(1M) and pkgadd(1M) commands to update the zone
while running within the scratch zone. Those commands explicitly
disallow removing or adding a pkg with the SUNW_ALLZONES attribute set
unless running in the global zone. Instead we will use the
/usr/sadm/install/bin/pkgremove and /usr/sadm/install/bin/pkginstall
commands directly. The pkgrm and pkgadd commands are wrappers to those
commands. Those commands were formerly part of the ON consolidation but
moved to the Install consolidation as part of [5]. That case documents man
pages for pkgremove and pkginstall but no such man pages exist. No
stability level is documented for these two commands so we're assuming
these are consolidation private and a contract is needed to directly use
these commands. The command line options being used are:
/usr/sadm/install/bin/pkgremove:
-a same as public pkgrm option
-F private - used by upgrade to suppress
actual removal of files delivered by
the pkg
-M same as public pkgrm option
-n same as public pkgrm option
-O inherited-filesystem={IPD} private - used to specify
the zone's inherited-pkg-dir
entries
-R same as public pkgrm option
/usr/sadm/install/bin/pkginstall:
-a same as public pkgrm option
-C private - disable checksums since files
are installed via a separate copy from
the global zone
-h private - enable hollow pkg support
-N pkgadd private - error msgs use use the name
"pkgadd" instead of "pkginstall"
-n same as public pkgrm option
-O addzonename private - error msgs include zonename
-O inherited-filesystem={IPD} private - used to specify
the zone's inherited-pkg-dir
entries
-R same as public pkgrm option
-S private - suppress copyright output
-t private - suppress spooled pkg creation
-z private - install zone pkg data from
spooled pkg data
EXPORTED INTERFACES
zoneadm attach option
[-u] Evolving
IMPORTED INTERFACES
pkgremove, pkginstall and
their options described in
this case Contracted Consolidation Private
REFERENCES
1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
2. RFE: zoneadm attach should patch/update the zone to the new hosts level
Bugid 6480464 http://bugs.opensolaris.org/view_bug.do?bug_id=6480464
3. PSARC/2006/030 Zone migration
4. PSARC/2005/474 Zones Upgrade
5. PSARC/2002/274 Move SVr4 Packaging from ON to ADMIN
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: updating a zone when attaching
Posted:
Jun 4, 2007 6:28 AM
in response to: gjelinek
|
|
Jerry Jelinek writes:
> 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.
This document describes in detail how the packaging bits will be taken
care of. But how are patches re-run to update the zone on attach? We
don't have copies of the patch metadata (the scripts) around in usable
form, do we? Do we just 'assume' that those patches never do anything
useful to any non-global zone?
> commands. Those commands were formerly part of the ON consolidation but
> moved to the Install consolidation as part of [5]. That case documents man
> pages for pkgremove and pkginstall but no such man pages exist. No
> stability level is documented for these two commands so we're assuming
> these are consolidation private and a contract is needed to directly use
> these commands. The command line options being used are:
Indeed; they're private implementation details of the Install
consolidation.
One alternative would be to modify pkgadd/pkgrm (or deliver new bits
from Install) to expose the features you need. I assume that the
reason you're not doing this is that delivery of Install updates on
which this new feature depends would be more difficult. Is that
right?
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
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
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: updating a zone when attaching
Posted:
Jun 4, 2007 9:07 AM
in response to: carlsonj
|
|
James,
James Carlson wrote:
> Jerry Jelinek writes:
>> 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.
>
> This document describes in detail how the packaging bits will be taken
> care of. But how are patches re-run to update the zone on attach? We
> don't have copies of the patch metadata (the scripts) around in usable
> form, do we? Do we just 'assume' that those patches never do anything
> useful to any non-global zone?
The patch bits are handled in the same way that they are currently handled
for a freshly installed zone. That is, those changes are already merged
into the bits as well as the spooled pkg data that we have in the global
zone. When we install a new zone the bits from the global zone are copied
into the zone and the spooled pkg is used to update the editable
and volatile files as well as the metadata for the pkg that is stored in
the zone.
>> commands. Those commands were formerly part of the ON consolidation but
>> moved to the Install consolidation as part of [5]. That case documents man
>> pages for pkgremove and pkginstall but no such man pages exist. No
>> stability level is documented for these two commands so we're assuming
>> these are consolidation private and a contract is needed to directly use
>> these commands. The command line options being used are:
>
> Indeed; they're private implementation details of the Install
> consolidation.
>
> One alternative would be to modify pkgadd/pkgrm (or deliver new bits
> from Install) to expose the features you need. I assume that the
> reason you're not doing this is that delivery of Install updates on
> which this new feature depends would be more difficult. Is that
> right?
Yes, thats right. Plus, I am hoping this is a relatively short-term
solution and that as the longer term caiman project evolves this
kind of feature will move back into the core install capability.
Thanks,
Jerry
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: updating a zone when attaching
Posted:
Jun 4, 2007 10:55 AM
in response to: gjelinek
|
|
Jerry Jelinek writes:
> > This document describes in detail how the packaging bits will be taken
> > care of. But how are patches re-run to update the zone on attach? We
> > don't have copies of the patch metadata (the scripts) around in usable
> > form, do we? Do we just 'assume' that those patches never do anything
> > useful to any non-global zone?
>
> The patch bits are handled in the same way that they are currently handled
> for a freshly installed zone. That is, those changes are already merged
> into the bits as well as the spooled pkg data that we have in the global
> zone.
Yep; I know. I was asking more about the patch-related scripting.
> When we install a new zone the bits from the global zone are copied
> into the zone and the spooled pkg is used to update the editable
> and volatile files as well as the metadata for the pkg that is stored in
> the zone.
This is actually a different case. With the usual patch install
scenario, one may need to worry about the zones on the system today
and the zones that are yet to be installed in the future. This
project introduces a new case: new un-upgraded zones may now show up
in the future, long after the patch scripts have run.
I think the assumption needs to be that we'll just never have a patch
script that needs to muck about in existing zones. Right?
> > One alternative would be to modify pkgadd/pkgrm (or deliver new bits
> > from Install) to expose the features you need. I assume that the
> > reason you're not doing this is that delivery of Install updates on
> > which this new feature depends would be more difficult. Is that
> > right?
>
> Yes, thats right. Plus, I am hoping this is a relatively short-term
> solution and that as the longer term caiman project evolves this
> kind of feature will move back into the core install capability.
I didn't see it on that roadmap, but ok ...
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
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
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: updating a zone when attaching
Posted:
Jun 4, 2007 11:16 AM
in response to: carlsonj
|
|
James Carlson wrote:
> Jerry Jelinek writes:
>>> This document describes in detail how the packaging bits will be taken
>>> care of. But how are patches re-run to update the zone on attach? We
>>> don't have copies of the patch metadata (the scripts) around in usable
>>> form, do we? Do we just 'assume' that those patches never do anything
>>> useful to any non-global zone?
>> The patch bits are handled in the same way that they are currently handled
>> for a freshly installed zone. That is, those changes are already merged
>> into the bits as well as the spooled pkg data that we have in the global
>> zone.
>
> Yep; I know. I was asking more about the patch-related scripting.
>
>> When we install a new zone the bits from the global zone are copied
>> into the zone and the spooled pkg is used to update the editable
>> and volatile files as well as the metadata for the pkg that is stored in
>> the zone.
>
> This is actually a different case. With the usual patch install
> scenario, one may need to worry about the zones on the system today
> and the zones that are yet to be installed in the future. This
> project introduces a new case: new un-upgraded zones may now show up
> in the future, long after the patch scripts have run.
>
> I think the assumption needs to be that we'll just never have a patch
> script that needs to muck about in existing zones. Right?
James,
OK, sorry for misunderstanding your point. Actually, I think the
assumption is different. I think the assumption is that patching
leaves the bits and spooled pkgs on the system in a state that is
suitable for installing the pkg into a zone. And, what is a new use
case now, is that this has to apply not only to fresh zones, but to
zones that have been previously installed.
However, I am not sure this is really anything new. When we are upgrading
a system from one Solaris update to the next, I believe the pkgs we are
installing are in this state. That is, a Solaris upgrade from one update
to the next does not install the patches as a separate step, it expects
the pkgs to be pre-patched. Is that your understanding as well? So maybe
there could be an issue if we had a patch that was not suitable for use in
a Solaris update but that was issued asynchronously? I will add some material
explaining this assumption to the proposal.
Thanks,
Jerry
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: updating a zone when attaching
Posted:
Jun 4, 2007 11:39 AM
in response to: gjelinek
|
|
Jerry Jelinek writes:
> OK, sorry for misunderstanding your point. Actually, I think the
> assumption is different. I think the assumption is that patching
> leaves the bits and spooled pkgs on the system in a state that is
> suitable for installing the pkg into a zone. And, what is a new use
> case now, is that this has to apply not only to fresh zones, but to
> zones that have been previously installed.
Yes; that's exactly what I'm asking about.
> However, I am not sure this is really anything new. When we are upgrading
> a system from one Solaris update to the next, I believe the pkgs we are
> installing are in this state. That is, a Solaris upgrade from one update
> to the next does not install the patches as a separate step, it expects
> the pkgs to be pre-patched.
Yes.
> Is that your understanding as well? So maybe
> there could be an issue if we had a patch that was not suitable for use in
> a Solaris update but that was issued asynchronously?
... or that was just handled differently in the update. I know we've
done some special things in patches outside of the updates, especially
with zones and outside of ON. I'd suggest asking Enda O'Connor about
these, so that (if it is a problem) you can at least detect it and
fail out.
> I will add some material
> explaining this assumption to the proposal.
OK.
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
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
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: updating a zone when attaching
Posted:
Jun 4, 2007 11:39 AM
in response to: carlsonj
|
|
James Carlson wrote:
>> Is that your understanding as well? So maybe
>> there could be an issue if we had a patch that was not suitable for use in
>> a Solaris update but that was issued asynchronously?
>
> ... or that was just handled differently in the update. I know we've
> done some special things in patches outside of the updates, especially
> with zones and outside of ON. I'd suggest asking Enda O'Connor about
> these, so that (if it is a problem) you can at least detect it and
> fail out.
James,
Good suggestion. I'll fire this off to Enda.
Thanks,
Jerry
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
EndaO'Connor
Enda.Oconnor@Sun.COM
|
|
|
|
Re: [zones-discuss] Re: updating a zone when
attaching
Posted:
Jun 4, 2007 1:35 PM
in response to: gjelinek
|
|
Jerry Jelinek wrote:
> James Carlson wrote:
>
>>> Is that your understanding as well? So maybe
>>> there could be an issue if we had a patch that was not suitable for
>>> use in
>>> a Solaris update but that was issued asynchronously?
>>
>>
>> ... or that was just handled differently in the update. I know we've
>> done some special things in patches outside of the updates, especially
>> with zones and outside of ON. I'd suggest asking Enda O'Connor about
>> these, so that (if it is a problem) you can at least detect it and
>> fail out.
>
>
> James,
>
> Good suggestion. I'll fire this off to Enda.
need to think about this one alright,
in general I'd be concerned about the likes of application patches more
than ON patches which in general tend to be more structured.
Application patches, such as JES can be very script orientated and very
specific tin how the patch gets installed.
ON patches that use scripting should be ok ( even the worse cases like
KU's, would in general be ok once the bits are on the system )
But patches outside ON can be very case specific, ie the install
instructions woudl be very specific in relation to how the patch gets
installed.
I'll ask people more familiar with non ON patching to get their opinion.
Enda
>
> Thanks,
> Jerry
> _______________________________________________
> zones-discuss mailing list
> zones-discuss at opensolaris dot org
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,262
From:
US
Registered:
8/5/05
|
|
|
|
Re: updating a zone when attaching
Posted:
Jun 4, 2007 4:17 PM
in response to: carlsonj
|
|
On 6/4/07, James Carlson <james dot d dot carlson at sun dot com> wrote:
> Jerry Jelinek writes:
> > 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.
>
> This document describes in detail how the packaging bits will be taken
> care of. But how are patches re-run to update the zone on attach? We
> don't have copies of the patch metadata (the scripts) around in usable
> form, do we? Do we just 'assume' that those patches never do anything
> useful to any non-global zone?
Does the equation change at all if relevant scripts were copied to
/var/sadm/patch/<patchid> when the patch is installed? It would be
the responsibility of patchadd (or related behind the scenes tool) to
put the scripts there. Presumably a flag saying "no scripts are
required" would be helpful to distinguish between systems that were
installed before and after this mechanism was implemented.
It would also be useful to be able to "fix" an existing system to set
the aforementioned flags or copy the scripts into place. This could
be done either through looking at the unapplied patches or through a
web service that just provides the required scripts. A web service
may be a lot of work for what should be a relatively short term
problem.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
43
From:
California
Registered:
5/14/06
|
|
|
|
Re: [zones-discuss] updating a zone when attaching
Posted:
Jun 4, 2007 6:48 AM
in response to: gjelinek
|
|
Hi Jerry,
This proposal mentions "native" zones.
Please ensure that the "cluster" brand is treated
as a "native" brand, as noted in PSARC 2007/304.
By the way PSARC 2007/304 was approved last week.
The changes are now in Nevada. We have been working
with the ON & Install gate C-teams. The changes will
go into the S10u4 gates once we receive notification of what date
they want the putback to occur. After the changes
get into both S10u4 gates, I will return to discuss the
long-term solution for S10u5.
Regards,
Ellard
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, 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.
>
> 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.
>
> We will ensure that we will only update a zone to a host running the
> same
> or later version of the dependent pkgs. For example, if the new
> host has
> a mix of higher and lower version patches as compared to the source
> host
> then we will not allow an update during the attach.
>
> By default the zone will not be updated during attach. Instead, the
> existing output listing the pkgs that are out of sync will continue to
> be printed. We will add a new option (-u) to the 'zoneadm attach'
> subcommand. When this option is used then zoneadm will update the
> necessary pkgs during the attach (assuming there are any to update).
>
> Because the zone has previously booted and run on the source host it is
> possible that there could be security issues with directly accessing
> the
> zone's filesystem to remove and add pkgs to the zone. To protect
> against
> this the pkg operations will be performed within the scratch zone
> [4]. The
> scratch zone was defined to address this specific issue for upgrading
> zones.
>
> We cannot use the pkgrm(1M) and pkgadd(1M) commands to update the zone
> while running within the scratch zone. Those commands explicitly
> disallow removing or adding a pkg with the SUNW_ALLZONES attribute set
> unless running in the global zone. Instead we will use the
> /usr/sadm/install/bin/pkgremove and /usr/sadm/install/bin/pkginstall
> commands directly. The pkgrm and pkgadd commands are wrappers to those
> commands. Those commands were formerly part of the ON consolidation
> but
> moved to the Install consolidation as part of [5]. That case
> documents man
> pages for pkgremove and pkginstall but no such man pages exist. No
> stability level is documented for these two commands so we're assuming
> these are consolidation private and a contract is needed to directly
> use
> these commands. The command line options being used are:
>
> /usr/sadm/install/bin/pkgremove:
> -a same as public pkgrm option
> -F private - used by upgrade to
> suppress
> actual removal of files
> delivered by
> the pkg
> -M same as public pkgrm option
> -n same as public pkgrm option
> -O inherited-filesystem={IPD} private - used to specify
> the zone's
> inherited-pkg-dir
> entries
> -R same as public pkgrm option
>
> /usr/sadm/install/bin/pkginstall:
> -a same as public pkgrm option
> -C private - disable checksums
> since files
> are installed via a separate
> copy from
> the global zone
> -h private - enable hollow pkg support
> -N pkgadd private - error msgs use use the
> name
> "pkgadd" instead of "pkginstall"
> -n same as public pkgrm option
> -O addzonename private - error msgs include
> zonename
> -O inherited-filesystem={IPD} private - used to specify
> the zone's
> inherited-pkg-dir
> entries
> -R same as public pkgrm option
> -S private - suppress copyright output
> -t private - suppress spooled pkg
> creation
> -z private - install zone pkg data
> from
> spooled pkg data
>
> EXPORTED INTERFACES
>
> zoneadm attach option
> [-u] Evolving
>
> IMPORTED INTERFACES
>
> pkgremove, pkginstall and
> their options described in
> this case Contracted Consolidation Private
>
> REFERENCES
>
> 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
> 2. RFE: zoneadm attach should patch/update the zone to the new hosts level
> Bugid 6480464 http://bugs.opensolaris.org/view_bug.do?bug_id=6480464
> 3. PSARC/2006/030 Zone migration
> 4. PSARC/2005/474 Zones Upgrade
> 5. PSARC/2002/274 Move SVr4 Packaging from ON to ADMIN
> _______________________________________________
> zones-discuss mailing list
> zones-discuss at opensolaris dot org
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: [zones-discuss] updating a zone when attaching
Posted:
Jun 4, 2007 9:07 AM
in response to: roush
|
|
roush wrote:
> Hi Jerry,
>
> This proposal mentions "native" zones.
> Please ensure that the "cluster" brand is treated
> as a "native" brand, as noted in PSARC 2007/304.
Ellard,
Will do.
Thanks,
Jerry
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,262
From:
US
Registered:
8/5/05
|
|
|
|
Re: Re: [zones-discuss] updating a zone when
attaching
Posted:
Jun 4, 2007 4:35 PM
in response to: roush
|
|
On 6/4/07, roush <Ellard dot Roush at sun dot com> wrote:
> Hi Jerry,
>
> This proposal mentions "native" zones.
> Please ensure that the "cluster" brand is treated
> as a "native" brand, as noted in PSARC 2007/304.
Any details on what this is? The case doesn't seem to be available on
opensolaris.org and the mercurial change log is not terribly
revealing.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: [zones-discuss] updating a zone when
attaching
Posted:
Jun 5, 2007 5:41 AM
in response to: mgerdts
|
|
Mike Gerdts writes:
> On 6/4/07, roush <Ellard dot Roush at sun dot com> wrote:
> > Hi Jerry,
> >
> > This proposal mentions "native" zones.
> > Please ensure that the "cluster" brand is treated
> > as a "native" brand, as noted in PSARC 2007/304.
>
> Any details on what this is? The case doesn't seem to be available on
> opensolaris.org and the mercurial change log is not terribly
> revealing.
It's an open case, so everything ought to be there. I'll drop a line
to the ARC discuss list.
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
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
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
43
From:
California
Registered:
5/14/06
|
|
|
|
Re: Re: [zones-discuss] updating a zone when
attaching
Posted:
Jun 6, 2007 11:13 AM
in response to: carlsonj
|
|
Hi James,
PSARC 2007/304 is open.
Anything in that case is available for the public.
The Solaris Cluster product line is not Open Source at
this time. The cluster management knows of the direction
that Sun Microsystems is going with respect to open source
and has a plan. Nothing has been publicly announced at this
time, and I cannot make any announcements.
So at this time, our work in Solaris follows the open source
model, while our work in Solaris Cluster does not.
Regards,
Ellard
James Carlson wrote:
> Mike Gerdts writes:
>> On 6/4/07, roush <Ellard dot Roush at sun dot com> wrote:
>>> Hi Jerry,
>>>
>>> This proposal mentions "native" zones.
>>> Please ensure that the "cluster" brand is treated
>>> as a "native" brand, as noted in PSARC 2007/304.
>> Any details on what this is? The case doesn't seem to be available on
>> opensolaris.org and the mercurial change log is not terribly
>> revealing.
>
> It's an open case, so everything ought to be there. I'll drop a line
> to the ARC discuss list.
>
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: [zones-discuss] updating a zone when
attaching
Posted:
Jun 6, 2007 11:58 AM
in response to: roush
|
|
Ellard Roush writes:
> PSARC 2007/304 is open.
> Anything in that case is available for the public.
It looks like someone has recently fixed the link. I wasn't talking
about the Sun Cluster code. I was talking about this link, which was
(when I sent that message) not working:
http://www.opensolaris.org/os/community/arc/caselog/2007/304/
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
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
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
409
From:
Registered:
6/16/05
|
|
|
|
Re: [zones-discuss] updating a zone when attaching
Posted:
Jun 4, 2007 8:49 AM
in response to: gjelinek
|
|
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
--------------------------------------------------------------------------
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: [zones-discuss] updating a zone when attaching
Posted:
Jun 4, 2007 9:13 AM
in response to: jeffv
|
|
Jeff,
I trimmed most of the original email.
Jeff Victor wrote:
> 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?
Yes, this seems orthogonal to my current proposal so we should just
handle this idea with a seperate RFE.
>> 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
I will rewrite this paragraph to try to be clearer. I do intend
to sync up when there are missing dependent pkgs. It will not be
just for the exact same pkgs as were originally there. I was trying
to capture the key point that I don't want to "dowgrade" the zone and
I don't want to allow this update if the new host is in a "mixed state"
as compared to the original host.
Thanks,
Jerry
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
95
From:
Registered:
2/27/06
|
|
|
|
Re: [zones-discuss] updating a zone when attaching
Posted:
Jun 5, 2007 2:53 AM
in response to: gjelinek
To: Communities » install » discuss
|
|
hello gerald,
can you explain why you don't want a "downgrade" of a zone ? the process of "remove the obsolete versions of those pkgs and install the up-to-date
version from the pkg data spooled in the global zone" should also be usable for the downgrade path or is this impossible ?
the ability to bring the zone pkgs in sync with the versions from the new host and allow a safe attach, independent of a "mixed state" would be a great flexibility.
mario
|
|
|
|
|
Posts:
1,262
From:
US
Registered:
8/5/05
|
|
|
|
Re: [zones-discuss] updating a zone when attaching
Posted:
Jun 4, 2007 4:29 PM
in response to: gjelinek
|
|
On 6/4/07, Jerry Jelinek <Gerald dot Jelinek at sun dot com> wrote:
> 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.
This seems to imply I can do something along the lines of:
lucreate -n newbe ...
for zone in $allzones ; do
zoneadm -z $zone halt
zoneadm -z $zone detach
done
luupgrade -t -n newbe -s /tmp/10_Recommended ...
luactivate newbe
init 6
for zone in $allzones ; do
zoneadm -z $zone attach -u
zoneadm -z $zone boot
done
But S10u4 adds support for live upgrade of zones, right? It doesn't
do it if I have ZFS in the mix. Since there is no mention of timeline
for live upgrade on a system with zones on ZFS (significant pain
point) this looks very promising.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: [zones-discuss] updating a zone when attaching
Posted:
Jun 5, 2007 5:35 AM
in response to: mgerdts
|
|
Mike,
Mike Gerdts wrote:
> This seems to imply I can do something along the lines of:
>
> lucreate -n newbe ...
>
> for zone in $allzones ; do
> zoneadm -z $zone halt
> zoneadm -z $zone detach
> done
>
> luupgrade -t -n newbe -s /tmp/10_Recommended ...
> luactivate newbe
> init 6
>
> for zone in $allzones ; do
> zoneadm -z $zone attach -u
> zoneadm -z $zone boot
> done
Yes, it enables things like this. I actually started working
on this because I want to implement a p2v (physical to virtual)
capability for putting an existing system into a zone but
it was obvious that the current limitations on attach would get
in the way. I do want to stress that updating on attach is
not the same as a full upgrade since I propose to only update
the dependent pkgs whereas upgrade might do more stuff.
> But S10u4 adds support for live upgrade of zones, right? It doesn't
> do it if I have ZFS in the mix. Since there is no mention of timeline
> for live upgrade on a system with zones on ZFS (significant pain
> point) this looks very promising.
Yes, this works on zfs. That happens to be the configuration I am
using for most of my testing.
Thanks,
Jerry
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
