RE: Patching zones.
We use the recommended patch clusters as well we only apply them to the global
zone. This in turn patches the zones on the system (either small or big). I
don't think it make sense to apply the recommended patch cluster to the global
AND the zones.
When I have tried to patch small zones I generally get an error saying it
doesn't apply to small zones and it must be applied to the global zone.
I have had some trouble with patches in the past (global v's zone mismatches)
and it is _definitely_ best to manage patches from the global. The only time I
have applied patches to big zones it for specific applications that are only
installed on that zone.
Your questions -- >
>Global Zone
>---
>patchadd -G
>---
>Installs only those patches that affect the global zone only, not the
>read-only
>filesystems of the zones. This includes any kernel patch.
patchadd -G wouldn't install kernel patches and this patch has many package
with SUNW_PKG_ALLZONES set to true so it must be applied to all zones. This is
how I understand it anyway.
>patchadd
>
>Install all types of patches including kernel patches on both the global and
>all the
>local zones in their read-only file systems
>
>Question 1: Do the local zones need to be shutdown to perform just a patchadd?
By default patchadd will try to apply patches to all zones, if the zones are
not up they will be brought up (to single user?) for patching.
>Question 2: Can the the local zones be running if you use patchadd -G
I would say yes. (Of course if the package you are patching has the
SUNW_PKG_ALLZONES set to true the patch wont install with the -G option anyway )
>small zone
>--
> Installs patches only on the local zone excluding kernel patches
>
>Question 1: If a patch cluster contains a kernel patch, will the patchadd
>command > ignore its installation.
Yes patchadd will error if you try to add a kernal patch to a small zone but as
I mentioned I would not even try installing a cluster in a zone:)
> Question 2: What are the issues with a big zone (no inherited filesystems)
> versus a shared zone when using patchadd?
There are many (more) patches that can't be installed in a small zone, see
answer to Q1:)
> Question 3: Does patchadd on inherited zone update the read-only filesystems
> (e.g. /sbin) or is this ignored in the patch process. Is this different with
> a "big
>zone".
No it doesn't update the read-only FS and the patchadd will fail. On a big
zone patches are able to update these filesystem (/sbin, /lib) but many patches
may still be marked with SUNW_PKG_ALLZONES=true (so they wont install on a big
zone)
> big zone
>
> Installs patches only on the local zone excluding kernel patches
>
> Question 1: If a patch cluster contains a kernel patch, will the patchadd
> command ignore its installation.
Yes patchadd will error if you try to add a kernal patch to a big zone but as
before I would not even try installing a cluster in a zone:)
> Question 2: What are the issues with a big zone (no inherited filesystems)
> versus a shared zone when using patchadd?
See above?
> Question 3: Does patchadd on inherited zone update the read-only filesystems
> (e.g. /sbin) or is this ignored in the patch process. Is this different with
> a "big
> zone".
see above?
My advise/summary with patching using recommended patch clusters would be to
add the cluster to the global (and only the global) and let it do it's thing.
It helps to keep all the zones on a global patched the same as well (for
Solaris patches anway).
I haven't done the patching for a few months now but I think what I wrote it
fairly accurate, hope it helps.
SMM
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
