Sparse are the way to go if you can get your software to run in a sparse
Failing that then whole-root, else you can use an in between one, ie
only inherit /platform /sbin & /lib and leave /usr writable.
The patch/packaging tools are not hard coded in this respect, so won't
care which dirs are inherited or not.
but you'll need to determine what apps need which dirs writable, and
also what priviledges etc these apps require, see previous links I sent
on, in this regard.
But in my experience most apps should run in one form or another, ie
oracle will run fine in a sparse zone for instance.
> I was just wondering of why someone might choose Sparse vs. Whole Root
> what are the benefits of one over the other, I need to decide in my new data
> center which one should I be using since there is no easy way to switching
> between them after they are created at least from Sun's support perspective.
> when I set my standard of creating zones I have to make sure that I have no
> to going from the one that is selected into the other if such would be
> required... So in other words I wanted to cover all benefits for both and
> best alternative for my standards.
> On Fri, 30 May 2008, Enda O'Connor wrote:
>> Krzys wrote:
>>> I am not sure if this question was already asked or not, but can you please
>>> tell me or point me to links where I can find what are the benefits or
>>> problems to have Sparse vs. Whole Root Zones?
>>> Here is what I have so far, please correct me if I'm wron on any of them.
>>> Whole Root Zones
>>> * Each zone is assigned its own root file system and cannot see that of
>> the bit about "cannot see that of others" applies to any type of zone (
>> sparse branded etc )
>>> * A zone can be created as a whole-rootzone
>>> > The zone gets its own writable copy of all Solaris file systems
>> it gets it's own writable copies of /usr /platform /sbin /lib to be percise,
>> along with all the otehr file systems.
>>> * Advantages of a whole root zone
>>> > installation of software such as WebSphere MQ v6.0 is easily
>>> acomplished since MQ must be installed into an environment where /opt and
>>> /usr are writable.
>>> > portability
>> yes, some software does require writable /usr
>>> Sparse Zones
>>> > The default file system configuration is called a sparse-rootzone
>>> > The zone contains its own writable /etc, /var, /proc, /dev
>> these are writable in any zone type assuming default install.
>>> > Inherited file systems (/usr, /lib, /platform, /sbin) are read-only
>>> mounted via a loopback file system (LOFS)
>>> > /opt is a good candidate for inheriting
>> possibly, but depends really on whether you want your zone to be able to
>> write to /opt or not.
>>> * Advantages of a sparse root zone
>>> > Faster patching and installation due to inheritance of /usr and /lib
>>> > Read-only access prevents trojan horse attacks against other zones
>> not really applicable as such in my opinion, each sparse root zone will see
>> the global zone's /usr for instance. But cannot modify /usr in any way.
>>> > Libraries shared across all zones reducing VM footprint
>> yes, but not really an issue unless you run a massive amount of zones and
>> don't have resources to cope.
>> BTW if you just want /usr writable, then you could leave the other file
>> systems such as /lib /platform and /sbin as inherited.
>> But it depends on what software you are trying to install ( and where it
>> wants to write to )
>>> zones-discuss mailing list
> zones-discuss mailing list
zones-discuss mailing list