Go to main content

Creating Package Repositories in Oracle® Solaris 11.4

Exit Print View

Updated: November 2018
 
 

Best Practices for Creating and Using Local IPS Package Repositories

The following is an example of the recommended way to use local IPS package repositories:

  1. Create a master repository under /var/share/pkg/repositories.

  2. Duplicate the master repository on other systems as necessary, depending on client demand and distance between client locations.

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

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

Do Not Subset Repository Content

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:

Minimal Required Repository

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.

Most Complete 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.

Create Repositories in a Separate ZFS File System in a Shared, Persistent Location

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 and Snapshot the Repository

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.

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

Provide Security and High Availability

To secure your local repositories, see Configuring HTTPS Repository Access for instructions.

To provide high availability, use one or more of the following strategies: