Jeff, I trimmed most of the original email.
Jeff Victor wrote: > This is probably out of scope for this project, but "software delivery > via zones" creates a potential security risk: software delivered via > this method could have a limitpriv setting which is inappropriate in > certain environments. > > "Zone migration best practices" should include "after 'zoneadm -z ... > attach', review the limitpriv setting with 'zonecfg -z ... info'". > Should we also warn the user who just attached a zone that has a > non-default limitpriv setting? > > A different approach would be a mechanism to inspect the > SUNWdetached.xml file and list its zonecfg-related contents *before* > performing the attach. This would satisfy those organizations which are > concerned by the possible omission of the "review zone's limitpriv" step. > > Should either of those be include in a separate CR? Yes, this seems orthogonal to my current proposal so we should just handle this idea with a seperate RFE. >> Instead what we want to do is similar to what happens when a zone is >> initially installed. The spooled pkg data and global zone files are >> the source for installing the zone. In this way the zone is installed >> with the >> correct pkg versions along with any patches that have been applied to >> those >> pkgs. > > Just looking for a clarification: if the intent is for the resultant > zone to have the same set of pkgs as a newly created zone, will this > method add any pkgs which: > 1) do not exist in the detached zone > 2) would be in newly created zones I will rewrite this paragraph to try to be clearer. I do intend to sync up when there are missing dependent pkgs. It will not be just for the exact same pkgs as were originally there. I was trying to capture the key point that I don't want to "dowgrade" the zone and I don't want to allow this update if the new host is in a "mixed state" as compared to the original host. Thanks, Jerry
