> would I be able to export and import zones from one server to another if I 
> have 
> different pkg's in local zone from what it is in global? What is the subject 
> to 
> the resrtictions of PKG_ALL_ZONES? I am not sure if I do undesrtand this part.

The short answer is yes.  Since most of your packages exist inside your
zoneroot, when you attach you are able to resolve the package/patch
requirements with the software you already have.

See the man page for pkginfo(4) and read the description of the
SUN_PKG_ALLZONES (sorry, I mispelled it earlier - that might have led
to the confusion).  Specifically

- The SUNW_PKG_ALLZONES attribute controls whether a package must be installed
 in all zones (and must be the same in all zones) when it is installed.

This applies to both sparse and whole root zones.   The idea here is
that there is some dependency such that we all have to agree to the same
version of the software.   I'll make up an example to illustrate my
point.  Let's say that there is a dependency between the serial device
driver and uucp.   So I'll mark the package with the serial driver as
SUNW_PKG_ALLZONES so that we all get the same one or none of us get it. 
This will prevent you from installing a different version of uucp in
your zone.   This would give you flexibility of installing uucp or
not, but if you do choose to install uucp then it has to be the one
that matches the serial driver that we have all agreed to standardize

Now this example is not real, but I couldn't think of an example that
was simple enough to describe in a paragraph :-)

> I do understand this, but nowdays disk space is quite inexpensive. days where 
> 4.5 or 9GB SCSI or FC drives were available is gone, now all my new servers 
> do 
> come with 73gb or 142gb disk sizes so I am not concerned about disk space at 
> all at this moment.

But you should :-)  Add Live Upgrade to the conversation.   And if you
using zones, PLEASE PLEASE PLEASE use Live Upgrade.  Please :-)

So you have this large disk, or a couple of them (mirrored of course).
If your zoneroots are small (lets say like for sparse zones) you could
quite easily tuck them into the root filesystem.  Now please do this on
a test system before running this into production and make sure this
doesn't cause too much disk contention - watch the service times using
iostat.  But assuming that this doesn't cause too much contention for
the root device, Live Upgrade becomes simple.  When you set up your
alternate boot environments you don't have to worry about where you are
going to put all of your alternate zoneroots, they will be safely
tucked inside of your alternate boot environment.   Makes for a very
clean configuration.

> yeah but I would not like my sysadmins training in a production environment, 
> test env is quite different story but thank you for that suggestion... :)

Oooo - sorry I shifted focus on you for that part.  I was referring to
trojan horse attacks on a test system to teach new sysadmins 
lesson :-)   Never on production !   I used to do things like that to
new hires to teach them valuable lessons.   Maybe that's why I'm not a
manager any more ;-)

> yeah but if my zone is on SAN then this is not an issue as I can just present 
> my 
> zone from one server to another in the matter of seconds...

That's true, and for SAN configuration that is a good solution.  I can
see many applications (web servers, compute servers) that might be able
to run off internal disks if the disk requirements were small enough.
Said a different way, I'd hate for the duplication of redundant system
files forcing you into a SAN solution unnecessarily.

In my zones class we close with the point that Edna made.  The default
situation should be sparse root zones and use whole root zones for the
corner case.  The benefits of sparse root zones outweigh the

And the corner cases are

- package minimization
- software writes all over /usr

And none of this really changes when we get zoneroots on ZFS (we have 
them in OpenSolaris today).  It makes whole root zones more acceptable,
but I really really like the security aspects of not being able to
write into /usr.   But used to manage a large network of diskless
workstations and sparse root non-global zones are exactly the same
thing, but with better control of privileges.


zones-discuss mailing list

Reply via email to