Simplify zone administration using the global zone: Patches



The global zone rules. It sees everything. It is all knowing. Among other things, the global zone is responsible for non-global zone (aka: local zone) lifecycle management. That includes create, install, boot, halt, destroy and everything in between. The global zone has access to everything a local zone has access to. The file system. Network interfaces. Users. Packages. Patches. Everything.

Since the global zone has access to everything a local zone has access to, how can we leverage the global zone to simplify administration of the whole server? Note, use "server" loosely as Solaris may be installed in a dynamic system domain or VMWare instance for example. From an administration perspective, zones provide a unique balance between application isolation and shared administration when compared with other virtualization technologies. One example covered earlier was leveraging the global zone to audit local zones using BART.

The next topic is operating system patches. Most virtualization technologies, such as VMWare, \*PARS and Dynamic System Domains, each running instance of the operating system must be patched individually. If, for example, you have 10 domains/VMWare OS images, then a patch is applied 10 times. It's no surprise that tools exist to address patch management across many servers. Keep in mind that zones are complementary to Dynamic System Domains and VMWare.

With zones, administrative flexibility exists with how patches are applied. Patches can be applied on a zone-by-zone basis, or to all zones in one fell swoop. For example, I installed an Sun Application Server 8.1 patch the other day in just one of 3 potential zones. On the other hand, I wanted the Fault Manager patch to apply to all zones, so I simply installed it in the global zone and all zones were patched automagically (example below). There are exceptions, such as a kernel or device driver patches, which are applied to the global zone and more likely than not require a reboot to take effect.

Below is an example of installing the fault manager patch in the global zone and having the patch apply to the global zone and to all non-global zones as well. All in one fell swoop. The zones have been renamed to protect the innocent. The fact that the server has a mix of sparse and whole root zones is accurate. However, since the sparse root zones loopback mount the fault manager files, no files are actually installed in the sparse root zones. However, the patch database in the sparse root zone is updated. Patching the fault manager isn't the best example as the fault manager daemon runs only in the global zone, but hey, that's the patch I needed :) Any other patch is applied in a similar manner.

root@globalzone:~> # Download Patch
root@globalzone:~> smpatch download -i 118344-13
root@globalzone:~> 
root@globalzone:~>
root@globalzone:~> # Add patch. This patch defaults to installing in all zones.
root@globalzone:~> ####################
root@globalzone:~> smpatch add -i 118344-13
add patch 118344-13
Validating patches...
Loading patches installed on the system...
Done!
Loading patches requested to install.
Done!
Checking patches that you specified for installation.
Done!
Approved patches will be installed in this order:
118344-13
Preparing checklist for non-global zone check...
Checking non-global zones...
Restoring state for non-global zone sparsezone1...
Restoring state for non-global zone sparsezone2...
This patch passes the non-global zone check.
118344-13
Summary for zones:
Zone wholezone1
Rejected patches:
None.
Patches that passed the dependency check:
118344-13
Zone sparsezone1
Rejected patches:
None.
Patches that passed the dependency check:
118344-13
Zone sparsezone2
Rejected patches:
None.
Patches that passed the dependency check:
118344-13
Zone sparsezone3
Rejected patches:
None.
Patches that passed the dependency check:
118344-13
Zone wholezone2
Rejected patches:
None.
Patches that passed the dependency check:
118344-13
Zone wholezone3
Rejected patches:
None.
Patches that passed the dependency check:
118344-13
Patching global zone
Adding patches...
Temporarily disabling fmd(1M)
Patch 118344-13 has been successfully installed.
Re-enabling fmd(1M)
Done!
Patching non-global zones...
Patching zone wholezone1
Adding patches...
Patch 118344-13 has been successfully installed.
Done!
Patching zone sparsezone1
Booting non-global zone sparsezone1 for patching...
Adding patches...
Patch 118344-13 has been successfully installed.
Done!
Restoring state for non-global zone sparsezone1...
Patching zone sparsezone2
Booting non-global zone sparsezone2 for patching...
Adding patches...
Patch 118344-13 has been successfully installed.
Done!
Restoring state for non-global zone sparsezone2...
Patching zone sparsezone3
Adding patches...
Patch 118344-13 has been successfully installed.
Done!
Patching zone wholezone2
Adding patches...
Patch 118344-13 has been successfully installed.
Done!
Patching zone wholezone3
Adding patches...
Patch 118344-13 has been successfully installed.
Done!
root@globalzone:~>

Here's a collection of resources on Solaris 10 patching you may find useful:

Comments:

John,
We should do a joint post regarding accessing zones from a Sun Ray Server. Most folks know that Sun Ray Server is only supported in the global zone, but that does not mean you couldn't do a remote graphical login to a different zone. Of course the devices would not be there, but for testing and isolation, it's a neat solution.

-CB

Posted by ThinGuy on September 12, 2006 at 11:48 AM PDT #

Yeah, we should. Ironically, I am typing this comment from a tarantella session, running in a zone, on my X2100 server on the 'Net. That is one means of accessing a graphical zone :)

Posted by John Clingan on September 12, 2006 at 12:55 PM PDT #

I will add that I am currently investigating zones, BrandZ and UCE (formerly Aduva OnStage). I believe that there is potential for interaction/joint posting in that respect as well.

Posted by Arieh Markel on September 12, 2006 at 08:12 PM PDT #

Running your login session inside a zone actually does make a lot of sense. Since the early days of the zones project, that's how I've actually run my desktop and have left the global zone to running the X server and the OS framework pieces. It's easy to do this using either dtlogin's remote login facility or through gdm.

Posted by David Comay on September 13, 2006 at 06:27 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

John Clingan

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today