> Whole Root Zones > * Each zone is assigned its own root file system and cannot see that of others
Each zone has it's own root directory, regardless of sparse, whole, native or branded. And you cannot see outside of your root directory tree unless you have a grossly misconfigured system. So this is the same for all types of zones. > A zone can be created as a whole-rootzone > > The zone gets its own writable copy of all Solaris 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. > > portabilit /opt is not a part of a sparse root zone by default. I use the term hypersparse to indicate when a zone has more than the default 4 directories (/usr /lib /sbin and /platform) inherited from the global zone. And the real use case here is when a software package expects to write into several /usr locations, so many that it is not feasible to work around it. Something that writes a little bit in /usr/bin and something in /usr/lib. If an application writes in a single place in /usr then it can be dealt with using a lofs or symbolic link. Same is true for hypersparse (my term) zones with an inherited /opt. Some examples that don't force you into a whole root zone would be your own private /usr/local that you want to write to. A separate version of Java in /usr/java. Both of these cases are self-contained (although the merit of a different version of Java in /usr/java is a point of debate) and don't require whole root zones. I would add that whole root zones enable minimizing your global zone. Install only the packages you need to in the global zone (a pretty small subset of the possible packages) and then create whole root zones with the packages you need for the application. You are still subject to the restrictions of PKG_ALL_ZONES, but you can tailor your zones to what they need and not bring along a lot of extra baggage. Add to this conversation that zones on ZFS will enable very efficient cloning of whole root zones (both in space and time). I wish we had a file level dedupe for ZFS as this would make this combination absolutely rock! > Sparse Zones > > The default file system configuration is called a sparse-rootzone > > The zone contains its own writable /etc, /var, /proc, /dev Actually /dev isn't writable in the way you might think. You can't do mknods. /dev is populated at zone installation time by the LU process and again at boot time by zoneadmd (based on the contents of the zone configuration file in /etc/zones). > > Inherited file systems (/usr, /lib, /platform, /sbin) are read-only > mounted via a loopback file system (LOFS) Add to this definition that the packing and patching system understands that writes to inherited-pkg-dir will fail and that doesn't cause the patch or packing tools to emit an error. That's the difference between an inherited-pkg-dir and a read-only LOFS mount. > > /opt is a good candidate for inheriting In cases where you have lots of packages that are common across all of your zones and the zones do not need to write in /opt, absolutely. A great use case for this is the Blastwave repository. /opt/sfw can get pretty large. > * Advantages of a sparse root zone > > Faster patching and installation due to inheritance of /usr and /lib Potentially much smaller disk footprint. For a SUNWcxall metacluster, Solaris can be about 3GB. Throw in the software companion or a reasonable set of packages from Blastwave and it's another 2 or 3GB. So a whole root zone will cost you 6 GB per zone in this case. A sparse root zone maybe only 70 or so MB, growing to 200 perhaps to take into consideration logging in /var. > > Read-only access prevents trojan horse attacks against other zones Actually, it's a trojan horse attack against the current zone. If you can't write into /usr then it's pretty hard to leave an infection behind in a place like /usr/bin where someone may trip over it (good opportunity for sysadmin training - the hard way). > > Libraries shared across all zones reducing VM footprint That is true. Unless you have a very memory constrained system, you probably won't notice this unless you have many many zones. I would also add that sparse root zones are easier to migrate since the zoneroot payload is potentially much smaller. I suppose you could argue that that are actually harder to migrate since the global zone has to match more packages and patches. I'd rather rcp 75MB than 6GB :-) So my short summary of why I recommend sparse zones - smaller disk footprint - better security since /usr and /lib are not writable - faster to create and patch - easier to migrate I like whole root zones when - apps have to write all over /usr (not just /usr/java or /usr/local) - I practice security though package minimization - when I can put the zoneroots on ZFS :-) Bob _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
