On 6/4/07, Wee Yeh Tan <[EMAIL PROTECTED]> wrote:
On 6/5/07, Mike Gerdts <[EMAIL PROTECTED]> wrote:
> With hundreds of zones in production today, it is feeling like later
> is already here. Worst case patching is well over 24 hours in single
> user mode. (I have developed my own workarounds to
Mike Gerdts wrote:
On 6/4/07, Jeff Victor <[EMAIL PROTECTED]> wrote:
Wee Yeh Tan wrote:
> I'll be grateful if you can share that. Patching zones is extremely
> painful due to the downtime you mentioned.
With S10 U4, Zulu will allow LU of zoned systems and minimize downtime to
"reboot time".
On 6/4/07, Jeff Victor <[EMAIL PROTECTED]> wrote:
Wee Yeh Tan wrote:
> On 6/5/07, Mike Gerdts <[EMAIL PROTECTED]> wrote:
>> With hundreds of zones in production today, it is feeling like later
>> is already here. Worst case patching is well over 24 hours in single
>> user mode. (I have develope
Wee Yeh Tan wrote:
On 6/5/07, Mike Gerdts <[EMAIL PROTECTED]> wrote:
With hundreds of zones in production today, it is feeling like later
is already here. Worst case patching is well over 24 hours in single
user mode. (I have developed my own workarounds to make each zone
only add about 10 min
Ellis, Mike wrote:
I like your eaxample... Good way to go if you can't swing the zones over to
some other server for import/attach/upgrade.
How would you envision backing out of the newbe environment if (after doing
the zoneimport +upgrade) you decide you want to back out and boot to the
pre-lu
On 6/5/07, Mike Gerdts <[EMAIL PROTECTED]> wrote:
With hundreds of zones in production today, it is feeling like later
is already here. Worst case patching is well over 24 hours in single
user mode. (I have developed my own workarounds to make each zone
only add about 10 minutes to total outage
On 6/4/07, Ellis, Mike <[EMAIL PROTECTED]> wrote:
I like your eaxample... Good way to go if you can't swing the zones over to
some other server for import/attach/upgrade.
In reality, this is how I think I would do this.
How would you envision backing out of the newbe environment if (after do
I like your eaxample... Good way to go if you can't swing the zones over to
some other server for import/attach/upgrade.
How would you envision backing out of the newbe environment if (after doing the
zoneimport +upgrade) you decide you want to back out and boot to the pre-lu
root-environment?
On 6/4/07, roush <[EMAIL PROTECTED]> 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 mercuri
On 6/4/07, Jerry Jelinek <[EMAIL PROTECTED]> 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 updat
On 6/4/07, James Carlson <[EMAIL PROTECTED]> 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 pk
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
do
F.V.(Phil)Porcella wrote:
***Im getting some strange errors from zoneadmin install
bash-3.00# zoneadm -z CIS2 install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <213> files to the zone.
Initializing zone product registry.
ERROR: Read-only file system
F.V.(Phil)Porcella writes:
> ERROR: Read-only file system: cannot create zone product registry text
> database file
[...]
> add inherit-pkg-dir
> set dir=/var
> end
I don't think that /var can be an inherit-pkg-dir, as this is where
the private per-zone packaging database will live, among other
F.V.(Phil)Porcella wrote:
***Im getting some strange errors from zoneadmin install
bash-3.00# zoneadm -z CIS2 install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <213> files to the zone.
Initializing zone product registry.
ERROR: Read-only file system:
***Im getting some strange errors from zoneadmin install
bash-3.00# zoneadm -z CIS2 install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <213> files to the zone.
Initializing zone product registry.
ERROR: Read-only file system: cannot create zone product
***Im getting some strange errors from zoneadmin install
bash-3.00# zoneadm -z CIS2 install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <213> files to the zone.
Initializing zone product registry.
ERROR: Read-only file system: cannot create zone product
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 p
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
>
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 t
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 pat
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
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
___
zones-discuss mailing list
zones-discuss@opensolaris
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.
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 l
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 change
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
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,
28 matches
Mail list logo
