The following is an example of the recommended way to use local IPS package repositories:
Create a master repository under /var/share/pkg/repositories.
Duplicate the master repository on other systems as necessary, depending on client demand and distance between client locations.
Configure all of these repository locations as publisher origins on every system. IPS automatically selects the repository location with the best connection for each client.
Update the master repository monthly to ensure that security fixes are available to client systems. Update the clone repositories monthly from the master repository.
Follow the best practices described below to maintain repository availability and minimize system update errors.
Include all content from your chosen Oracle Solaris repository source.
Your Oracle Solaris repository source can be any of the following:
The Oracle Solaris release repository: http://pkg.oracle.com/solaris/release/
The Oracle Solaris support repository: https://pkg.oracle.com/solaris/support/
An Oracle Solaris package repository file
Repository files for Oracle Solaris GA releases and Support Repository Update (SRU) releases are available from various Oracle download sites as described in How to Copy a Repository From a zip File.
Do not attempt to select a subset of packages to include in your local repository.
Dependencies. Packages that belong together do not necessarily have the same version numbers or any other common identifier that would enable you to correctly select the required set.
Architecture. Each package includes all content for both SPARC and x86 architectures. Creating a SPARC-only or x86-only repository is not possible.
Do not remove from your repository packages that are delivered by an Oracle publisher. Oracle publishers include, for example, solaris, solarisstudio, and ha-cluster.
Using a subset repository is not a viable way to accomplish any of the following:
Limit the software that users can install. To install or update to a release that is older than the latest release available in the repository, or to otherwise control which software users can install, use one of the solutions described in Updating to a Version Older Than the Newest Version Allowed in Updating Systems and Adding Software in Oracle Solaris 11.4. Solutions described in that documentation include specifying a version constraint on the command line and using a constraint package.
Save disk space. To minimize the amount of software installed on a system, install the solaris-minimal-server package in your initial system installation instead of the solaris-large-server package, and then add other packages that you want. You could create a custom package with just this set of packages as group dependencies. Other packages that are dependencies of the named packages are installed automatically. For information about dependencies and instructions for creating packages, see Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.4.
To minimize the space required for a package repository, use the guidelines in Minimal Required Repository to periodically replace your repository, rather than adding packages with every repository update. See the remove and replace instructions in Step 3 in How to Update a Local IPS Package Repository to update your package repository by replacing the repository rather than simply adding to the repository.
Reduce package search and installation time. Use one of the following strategies to reduce package access time:
Install multiple identical package repositories and configure all of these locations as publisher origins on every system. IPS automatically selects the repository location with the best connection for each client. See Maintaining Multiple Identical Local Repositories.
Use the pkg/depot scalable repository server described in How to Enable Users to Retrieve Packages Using an HTTP Interface.
See also Provide Security and High Availability below.
The Oracle Solaris package repository for each GA release (Oracle Solaris 11 11/11, Oracle Solaris 11.1, Oracle Solaris 11.2, Oracle Solaris 11.3, and Oracle Solaris 11.4) is a complete set of packages for that GA release. The Oracle Solaris package repository for each SRU (for example, Oracle Solaris 11.3 SRU 19) includes only packages for that SRU. See also Oracle Solaris Repository Content.
In general, you do not need to add SRU content to your local repository if you add the content of a later GA release to your local repository. The exception to this general rule is if you are updating from or to that SRU release.
The minimal package repository required to support upgrades to new Oracle Solaris releases is the following content for each system that the repository must support:
The repository content for the currently installed GA release
The repository content for the currently installed SRU, if any
The repository content for the GA release to which you want to update
The repository content for the SRU to which you want to update, if any
If the currently installed GA release is more than one release behind the release to which you want to update, then your local repository must also contain the repository content for each intervening GA release.
If the currently installed release is Oracle Solaris 11 11/11 with no SRU or an SRU lower than SRU 10, then your local repository must also contain the repository content for Oracle Solaris 11 11/11 SRU 10.
For example, to upgrade from Oracle Solaris 11.3 SRU 16 to Oracle Solaris 11.3 SRU 19, your local IPS package repository must include the following repository content:
Oracle Solaris 11.3
Oracle Solaris 11.3 SRU 16
Oracle Solaris 11.3 SRU 19
To upgrade from Oracle Solaris 11 11/11 SRU 7.5 to Oracle Solaris 11.3 SRU 19, your local IPS package repository must include the following repository content:
Oracle Solaris 11 11/11
Oracle Solaris 11 11/11 SRU 7.5
Oracle Solaris 11 11/11 SRU 10.5
Oracle Solaris 11.1
Oracle Solaris 11.2
Oracle Solaris 11.3
Oracle Solaris 11.3 SRU 19
Repository files for Oracle Solaris GA releases and Support Repository Update (SRU) releases are available from various Oracle download sites as described in How to Copy a Repository From a zip File.
Your local repository must contain complete content of the GA and SRU repositories for currently installed software because content from those repositories that is not currently installed might be needed to resolve dependencies for an update.
For more information about keeping your repository as small as possible see the remove and replace instructions in Step 3 in How to Update a Local IPS Package Repository.
If space is not a problem, you can use the svc:/application/pkg/mirror Service Management Facility (SMF) service to automatically update your local package repository from the Oracle Solaris support repository. See How to Automatically Copy a Repository From the Internet for instructions.
An example of a recommended repository location is in a separate ZFS file system in /var/share/pkg/repositories.
Create each repository in its own ZFS file system.
Using a separate ZFS file system enables you to do the following:
Achieve better performance.
Set separate file system characteristics. For example, set atime to off for better performance when updating the repository. The atime property controls whether the access time for files is updated when the files are read. Turning this property off avoids producing write traffic when reading files. Set the compression property to reduce disk space required.
Manage resource use. Specify an appropriate disk quota for each repository dataset to ensure that large repository updates do not consume all the space in the pool. This best practice is especially important if you are performing updates automatically as described in How to Automatically Copy a Repository From the Internet.
Create snapshots.
Create repositories in a shared location.
A shared location is a location that is not in any bootable environment (BE). Everything in rpool/ROOT or pool/ROOT is copied to each new BE and potentially customized in each BE; it is not shared by all BEs. Examples of shared locations include /var/share and /export. Creating a repository in a shared location provides the following benefits:
The repository is available from any existing BE. When you boot to a different BE, including an older BE, the same package repository is still available.
When you create a new BE through upgrading or by cloning an existing BE, you do not waste space by creating multiple copies of the repository.
You do not waste time and I/O resources reapplying repository updates that you have already made in a different BE.
If you are using non-global zones, all locations of publishers configured in non-global zones must be accessible from the global zone even if that publisher is not configured in the global zone.
Create repositories in a persistent location.
Package update or removal usually requires access to a repository that contains the currently installed version of the package. Do not set a publisher origin to a repository in /tmp or other nonpersistent location. Move that content to a persistent, shared location. If you install packages from package archive files (.p5p files), save those package archive files in a persistent, shared location.
Verify every time you update the repository.
Use the pkgrepo verify command whenever you change the content or property values of the repository. The pkgrepo verify command verifies that the following attributes of the repository content are correct:
File digests.
File permissions. The repository files and directories and the path leading to the repository are checked to ensure that the pkg5srv user can read the repository content.
Package manifest permissions.
Package manifest content.
Package signatures.
No dependent packages are missing.
Snapshot every time you update the repository.
Snapshot the repository file system every time you update the repository to gain the following benefits:
Use a previously saved snapshot to roll back to a previous version of the repository.
Minimize user disruption when updating the repository by updating a clone and then replacing the repository with the updated clone.
To secure your local repositories, see Configuring HTTPS Repository Access for instructions.
To provide high availability, use one or more of the following strategies:
Maintain repository clones in different locations and configure all of these repository locations as publisher origins on every system. IPS automatically selects the repository location with the best connection for each client. See Maintaining Multiple Identical Local Repositories for instructions.
To better serve more clients simultaneously, configure repository service properties as described in How to Enable Users to Retrieve Packages Using an HTTP Interface.
Configure your web server for caching, load balancing, and serving multiple repositories. See Running the Package Depot Server Behind a Web Server for information.