Thank you Bob for taking your time and going over this, I greatly do appreciate your help.
On Fri, 30 May 2008, Bob Netherton wrote: > 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. 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. > > 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! yes, that would rock for sure... >> * 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. 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. > >> > 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). 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... :) > 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 :-) 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... > 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 :-) > Once again Bob thank you so much for this info. _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
