Skip Navigation Links | |
Exit Print View | |
Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
1. IPS Design Goals, Concepts, and Terminology
2. Packaging Software With IPS
3. Installing, Removing, and Updating Software Packages
4. Specifying Package Dependencies
6. Modifying Package Manifests Programmatically
7. Automating System Change as Part of Package Installation
8. Advanced Topics For Package Updating
Packaging Considerations for Non-Global Zones
Does the Package Cross the Global, Non-Global Zone Boundary?
How Much of a Package Should Be Installed in a Non-Global Zone?
Troubleshooting Package Installations in Non-Global Zones
This section discusses problems that users might encounter when attempting to install a package in a non-global zone.
If you encounter a problem installing a package in a non-global zone, ensure that the following services are online in the global zone:
svc:/application/pkg/zones-proxyd:default svc:/application/pkg/system-repository:default
Ensure that the following service is online in the non-global zone:
svc:/application/pkg/zones-proxy-client:default
These three services provide publisher configuration to the non-global zone and a communication channel that the non-global zone can use to make requests to the repositories assigned to the system publishers served from the global zone.
You cannot update the package in the non-global zone, since it has a parent dependency on itself. Initiate the update from the global zone; pkg updates the non-global zone along with the global zone.
Once the package is installed in the non-global zone, test the functionality of the package.
If the package does not have a parent dependency on itself, then you do not need to configure the publisher in the global zone, and you should not install the package in the global zone. Updating the package in the global zone will not update the package in the non-global zone. In this case, updating the package in the global zone can cause unexpected results when testing the older non-global zone package.
The simplest solution in this situation is to make the publisher available to the non-global zone, and install and update the package from within the non-global zone.
If the zone cannot access the publisher's repositories, configuring the publisher in the global zone enables the zones-proxy-client and system-repository services to proxy access to the publisher for the non-global zone. Then install and update the package in the non-global zone.