IPS は、Oracle Solaris の顧客、開発者、保守管理者、および ISV にとって重大な問題を引き起こしている以前のソフトウェア配布、インストール、および保守メカニズムに関する長期にわたる問題を取り除くために設計されたものです。
IPS の主な設計目標には次が含まれます。
計画されたダウンタイムを最小限に抑えるには、マシンの稼働中にソフトウェア更新を可能にします。
計画外のダウンタイムを最小限に抑えるには、既知の作業用ソフトウェア構成への高速リブートをサポートします。
新しいソフトウェアと、既存ソフトウェアへの更新のインストールをできるだけ自動化します。
増え続けるソフトウェアサイズと限られた配布メディア容量の問題を解消します。
パッケージの作成者 (パブリッシャー) によって定義されたとおりにパッケージが正しくインストールされるかどうかを確認できるようにしてください。このようなチェックはスプーフィング可能でないようにしてください。
さまざまなレベル (特にゾーンを使用するレベル) で Oracle Solaris の簡単な仮想化を可能にするメカニズムを取り入れます。
既存のシステム用のパッチまたはアップグレードを生成するために必要な労力を減らします。
ほかのソフトウェアパブリッシャー (ISV やエンドユーザー自身) が Oracle Solaris のパッケージを簡単に作成および発行できるようにします。
これらの目標は、次の考えにつながりました。
ZFS スナップショットおよびクローン機能を活用して、ブート環境を必要に応じて動的に作成します。
Oracle Solaris 11 ではルートファイルシステムとして ZFS が必要であるため、ゾーンファイルシステムも ZFS 上にある必要があります。
ユーザーはブート環境を必要な数だけ作成できます。
IPS は、実行中のシステムを変更する前のバックアップの目的で、または新しいバージョンの OS のインストールのために、ブート環境を必要に応じて自動的に作成できます。
インストール、パッチ、および更新に使用する、重複したメカニズムとコードを削除します。
この考えによって、Oracle Solaris の保守方法に、次の重要な例を含む、いくつかの重大な変更が加えられました。
OS ソフトウェアの更新とパッチの適用はすべて IPS で直接行われます。
新しいパッケージがインストールされるときはいつでも、それはすでに正確に正しいバージョンになっています。
パッケージインストールでスプーフィング不可能な検証が要求される結果、次の結論に達します。
パッケージを複数の方法でインストールできるようにする必要がある場合は、検証プロセスでこれが考慮に入れられるように開発者がそれらの方法を指定する必要があります。
パッケージシステムではスクリプト作成者の意図を判断できないため、スクリプト作成は本質的に検証不可能です。これは、後述する他の問題とともに、パッケージ化の操作中のスクリプト作成の除去につながりました。
そのあとの検証が不可能なため、パッケージにそれ自身のマニフェストを編集するメカニズムを含めることはできません。
管理者が元のパブリッシャーの定義と互換性のない方法でパッケージをインストールする場合は、管理者の変更の範囲がアップグレードにより失われることなく明確で、元のパッケージと同じ方法で検証できるように、パッケージシステムでは管理者が変更するパッケージを簡単に再発行できるようにするべきです。
サイズ制限を回避する必要性は、いくつかの異なる方法を使用してアクセスされるソフトウェアリポジトリモデルにつながりました。さまざまなリポジトリソースを複合して完全なパッケージセットを提供できるので、複数のリポジトリを 1 つのファイルとして配布できます。この方法では、使用可能なすべてのソフトウェアを含めるために単一のメディアは必要ありません。切断状態での操作またはファイアウォールで保護された操作をサポートするために、リポジトリをコピーしてマージするためのツールが用意されています。
複数の (場合によっては競合する) ソフトウェアパブリッシャーを有効にしたいという願いは、すべてのパッケージメタデータをパッケージそのものに格納する決定につながりました: すべてのパッケージや依存関係などの情報のためのマスターデータベースは存在しません。ソフトウェアパブリッシャーからの使用可能パッケージのカタログは、パフォーマンスの理由でリポジトリの一部になっていますが、パッケージに含まれるデータからそのカタログを再生成することもできます。