Copying and Creating Package Repositories in Oracle® Solaris 11.2

Exit Print View

Updated: September 2014

Best Practices for Creating and Using Local IPS Package Repositories

Employ the following best practices to maintain repository availability and minimize errors.

Include all content of all Support Repository Updates (SRUs).

Keep local repositories updated with all support updates. Support updates contain security updates and other important fixes. Each minor release and update of the Oracle Solaris OS package repository is released as a full set of packages. SRUs are released as a sparse update of just the changed packages.

  • Do not add a subset of packages from a support update to your repository. Add all of the content of the support update to your local repository.

  • Do not skip a support update. Accumulate all applicable support updates in each repository.

  • Do not remove packages that are delivered by an Oracle publisher.

  • Use the svc:/application/pkg/mirror Service Management Facility (SMF) service to automatically update the local master repository from the Oracle support repository. See How to Automatically Copy a Repository From the Internet for instructions.

Users can update to a version earlier than the latest version in the repository by specifying the version of the entire incorporation package to install. See Chapter 4, Updating or Upgrading an Oracle Solaris Image, in Adding and Updating Software in Oracle Solaris 11.2 .

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 checksums.

  • 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.

Create repositories in a shared location.

A shared location is a location that is not in any bootable environment (BE). Examples of shared locations include /var/share and /export. Creating a repository in a shared location provides the following benefits:

  • The repository is easily available from other existing BEs.

  • When you create a new BE through upgrading or by cloning an existing BE, you do not waste space by having multiple copies of a 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 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.

  • 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.

Snapshot every time you update the repository.

Snapshot the repository file system every time you update the repository to gain the following benefits:

  • Roll back to a previous version of the repository from a snapshot.

  • Update the repository from a snapshot to minimize user disruption.

Provide high availability.
Secure your local repositories.

See Configuring HTTPS Repository Access for instructions.