> 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 on. 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 limitations. 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. Bob _______________________________________________ zones-discuss mailing list firstname.lastname@example.org