2525N/A Chapter 12, Dealing with Zones, describes how IPS handles zones
2525N/A and discusses those cases where package developers should be
2562N/ADeveloping packages which work consistently with zones often involves little to
2562N/Ano additional work but a few situations call for close attention from
2562N/Adevelopers. When considering zones and packaging there are two questions which
2562N/A1) Does anything in my package have an interface which crosses the boundary
2562N/Abetween the global zone and non-global zones?
2562N/A2) How much of my package should be installed in the non-global zone?
2562N/AIf the answer to question one is yes, then it's important to place a parent
2562N/Adependency in the package being developed. If a single package delivers both
2562N/Asides of the interface then a parent dependency on
2562N/Anon-global zones contain the same version of the package, preventing version
2562N/Askew across the interface. The dependency will also ensure that if the package
2562N/Ais in a non-global zone, it is present in the global zone. If the interface
2562N/Aspans multiple packages, then the package containing the non-global zone side of
2562N/Athe interface must contain a parent dependency on the package which delivers the
2562N/Aglobal zone side of the interface. For more details on the parent dependency,
2562N/AIf the answer to question two is "all of it" (and that's typically the case)
2562N/Athen nothing needs to be done to the package to enable it to function properly.
2562N/AFor consumers of the package though, it can be reassuring to see that the
2562N/Apackager properly considered zone installation and decided that this package can
2562N/Afunction in one. For that reason, we encourage package developers to explicitly
2562N/Astate their package functions in both global and non-global zones. This is done
2562N/Aby adding the following action to the manifest:
2562N/AIf the answer to question to is "none of it" (for example a package which only
2562N/Adelivers kernel modules or drivers), then the package should specify that it
2562N/Acannot be installed in a zone. This is done by adding the following action to
2562N/AIf the answer to question to is "some of it", then things get slightly more
2562N/Acomplicated. The first step is to state that the package can be installed in
2562N/Aboth global and non-global zones. Again, the action that states this is:
2562N/AThe next step is to identify those actions which are only relevant in either the
2562N/Aglobal or non-global zone. The global-zone-only actions should have the
2562N/Awhich only apply in non-global zones.
2562N/AIf a package has a parent dependency or has pieces which are different in global
2562N/Aand non-global zones, it's important to test that the package works as expected
2562N/Ain the non-global zone as well as the global zone. If the package has a parent
2562N/Adependency on itself, then the global zone should configure the repository which
2562N/Adelivers the package as one of its origins. The package should be installed in
2562N/Athe global zone, then in the non-global zone for testing. Occasionally problems
2562N/Amay be encountered when trying to install the package in the non-global zone.
2562N/ATypically the first steps to take to attack the problem are to ensure that the
2562N/Azoneproxy service is online in both the non-global zone and the global zone and
2562N/Athat the system-repository service is online in the global zone. These three
2562N/Aservices provide publisher configuration to the non-global zone and a
2562N/Acommunication channel the non-global zone can use to make requests to the system
2562N/Apublishers. Remember that you won't be able to update the package in the
2562N/Anon-global zone, since it has a parent dependency on itself. Initiating the
2562N/Aupdate from the global zone and allowing pkg's linked image code to update the
2562N/Anon-global zone is the right solution. Once the package is installed in the
2562N/Anon-global zone, testing it's functionality can begin.
2562N/AIf the package does not have a parent dependency on itself, then it's not
2562N/Anecessary to configure the publisher in the global zone nor install the package
2562N/Athere. Further, updating the package in the global zone will not update it in
2562N/Athe non-global zone, causing potentially unexpected results when testing the
2562N/Aolder non-global zone package. The simplest solution in this situation is to
2562N/Amake the publisher available to the non-global zone and install and update the
2562N/Apackage from within the zone. If the zone cannot access the publisher, then
2562N/Aconfiguring it in the global zone will work. In that case, it's still best to
2562N/Ainstall and update the package in the non-global zone.