次のベストプラクティスを利用して、リポジトリの可用性を維持し、エラーを最小限にします。
Oracle Solaris リリースまたはサポートリポジトリからすべての内容を含めます。
リポジトリに含めるパッケージのサブセットを選択しようとしないでください。solaris、solarisstudio、ha-cluster など、Oracle パブリッシャーによって提供されるリポジトリパッケージから削除しないでください。サブセットリポジトリを作成することは、ユーザーがインストールできるソフトウェアを制限したり、ディスク容量を節約したり、パッケージの検索およびインストールの時間を短縮したりするために実行可能な方法ではありません。サブセットリポジトリからのインストールと更新はサポートされていません。
リポジトリ内の使用可能な最新リリースよりも古いリリースをインストールするかそのリリースに更新するか、またはユーザーがインストールできるソフトウェアを制御するには、Oracle Solaris 11.3 ソフトウェアの追加と更新 の 第 4 章, Oracle Solaris イメージの更新またはアップグレードで説明されているいずれかの解決方法を使用します。この章で説明されている解決方法には、バージョン制約の指定と、カスタムの incorporation パッケージの作成が含まれます。
システムにインストールされるソフトウェアの量を最小限に抑えるには、まず solaris-minimal-server パッケージをインストールしてから、必要なその他のパッケージを追加します。このパッケージセットのみが依存関係として含まれるカスタムパッケージを作成できます。指定されたパッケージの依存関係であるほかのパッケージは自動的にインストールされます。パッケージを作成するための依存関係および手順については、Oracle Solaris 11.3 でのImage Packaging System を使用したソフトウェアのパッケージ化と配布を参照してください。
パッケージの検索およびインストールの時間を短縮するには、複数の同一のパッケージリポジトリをインストールして、これらのすべての場所をすべてのシステム上の起点として構成します。IPS では、最適な接続を持つ場所が自動的に選択されます。次の「高可用性を提供します」を参照してください。
すべての Support Repository Update (SRU) のすべての内容を含めます。
ローカルリポジトリをすべてのサポート更新で常に最新にします。サポート更新には、セキュリティー更新およびその他の重要な修正が含まれています。Oracle Solaris OS のパッケージリポジトリの各マイナーリリースおよび更新は、フルセットのパッケージとしてリリースされます。SRU は、変更されたパッケージのみの疎アップデートとしてリリースされます。詳細については、Oracle Solaris リポジトリの内容を参照してください。
パッケージのサブセットをサポート更新からリポジトリに追加しないでください。サポート更新のすべての内容をローカルリポジトリに追加します。
サポート更新をスキップしないでください。適用可能なすべてのサポート更新を各リポジトリに適用してください。
Oracle パブリッシャーによって配布されたパッケージを削除しないでください。
svc:/application/pkg/mirror サービス管理機能 (SMF) サービスを使用して、Oracle サポートリポジトリからローカルのマスターリポジトリを自動的に更新します。手順については、インターネットからリポジトリを自動的にコピーする方法を参照してください。
リポジトリ内の最新のバージョンより古いバージョンに更新するには、インストールする entire incorporation パッケージのバージョンを指定します。Oracle Solaris 11.3 ソフトウェアの追加と更新 の 第 4 章, Oracle Solaris イメージの更新またはアップグレードを参照してください。
リポジトリを可能なかぎり小さく維持することに関する詳細については、Oracle Solaris IPS パッケージリポジトリのサイズを最小にする方法に関するドキュメントを参照してください。
リポジトリの内容またはプロパティーの値を変更するたびに、pkgrepo verify コマンドを使用します。pkgrepo verify コマンドは、リポジトリの内容の次の属性が正しいことを検証します。
ファイルのチェックサム。
ファイルのアクセス権。pkg5srv ユーザーがリポジトリの内容を読み取ることができるように、リポジトリファイル、ディレクトリ、およびリポジトリへのパスがチェックされます。
パッケージマニフェストのアクセス権。
パッケージマニフェストの内容。
パッケージ署名。
共有の場所とは、どのブート可能環境 (BE) にも含まれていない場所です。共有の場所の例として、/var/share および /export があります。リポジトリを共有の場所に作成すると、次の利点があります。
リポジトリをほかの既存の BE から簡単に利用できます。
アップグレードまたは既存の BE をクローニングして新しい BE を作成した場合、リポジトリに複数のコピーがあることによって領域が無駄に使用されることはありません。
ほかの BE に適用したリポジトリ更新を再適用するために、時間と入出力リソースを浪費することはありません。
非大域ゾーンを使用している場合、非大域ゾーンに構成されているパブリッシャーのすべての場所は、そのパブリッシャーが大域ゾーンに構成されていなくても、大域ゾーンからアクセスできる必要があります。
各リポジトリを独自の ZFS ファイルシステムに作成します。
別個の ZFS ファイルシステムを使用すると、次のことが可能になります。
高いパフォーマンスの達成。
異なるファイルシステム特性の設定。たとえば、リポジトリを更新する場合、パフォーマンスの改善のために atime を off に設定します。atime プロパティーは、ファイルが読み取られるときにファイルのアクセス時間が更新されるかどうかを制御します。このプロパティーをオフにすると、ファイルを読み取るときに書き込みトラフィックが生成されなくなります。
リソースの使用量の管理。大型のリポジトリの更新によってプール内のすべての領域が消費されないように、各リポジトリデータセットに適切なディスク割り当てを指定します。このベストプラクティスは、インターネットからリポジトリを自動的にコピーする方法に記述されているように更新を自動的に実行している場合に特に重要です。
スナップショットの作成。
次の利点を得られるように、リポジトリを更新するたびにリポジトリのファイルシステムのスナップショットを作成します。
スナップショットから以前のバージョンのリポジトリにロールバックします。
ユーザーへの影響を最小化するために、スナップショットからリポジトリを更新します。
リポジトリのクローンを別の場所に保持します。手順については、複数の同一のローカルリポジトリの保守を参照してください。
キャッシュ、負荷分散、および複数リポジトリの提供を実行する Web サーバーを構成します。詳細については、Web サーバーの背後での集積サーバーの実行を参照してください。
手順については、HTTPS でのリポジトリアクセスの構成を参照してください。