この章では、パッケージのオプション情報ファイルとインストールスクリプトの作成方法を説明します。第 2 章パッケージの構築ではパッケージ作成の最低限の要件を説明しましたが、この章ではパッケージに組み込むことのできる追加機能について説明します。この追加機能は、パッケージの設計方法を計画する際に考慮した条件に基づいています。詳細については、「パッケージを構築する前の考慮事項」を参照してください。
この章の内容は以下のとおりです。
次の作業マップでは、パッケージに組み込むことのできるオプション機能について説明します。
表 3–1 情報ファイルとインストールスクリプトの作成 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
1. 情報ファイルを作成する |
パッケージの依存関係を定義する パッケージの依存関係を定義すると、パッケージが以前のバージョンと互換性があるかどうか、ほかのパッケージに依存するかどうか、またはほかのパッケージがそのパッケージに依存するかどうかを指定できます。 | |
著作権に関するメッセージを書く copyright ファイルを用意すると、ソフトウェアアプリケーションを法的に保護できます。 | ||
ターゲットシステムに追加領域を予約する space ファイルにより、ターゲットシステム上でブロックが取り置かれます。これにより、pkgmap ファイルで定義されていないファイルを、インストール時に作成できます。 | ||
2. インストールスクリプトを作成する |
インストーラから情報を取得する request スクリプトを使用すると、パッケージをインストールする人から情報を取得できます。 | |
インストールに必要なファイルシステムデータを収集する checkinstall スクリプトを使用すると、ターゲットシステムの分析を行なって、インストール用の環境を適切に設定したり、インストールをクリーンに停止したりできます。 | ||
手続きスクリプトを書く 手続きスクリプトを使用すると、インストールプロセスまたは削除プロセスの特定のフェーズの間に、カスタマイズしたインストール命令を挿入できます。 | ||
クラスアクションスクリプトを書く クラスアクションスクリプトを使用すると、パッケージのインストールおよび削除の間にパッケージオブジェクトの特定のグループに対して、一連の命令を指定して実行できます。 |
この節では、オプションのパッケージ情報ファイルについて説明します。パッケージ情報ファイルを使用すると、パッケージの依存関係の定義、著作権に関するメッセージの提供、およびターゲットシステム上の追加領域の予約が可能になります。
作成するパッケージがほかのパッケージに依存するかどうか、およびほかのパッケージが作成するパッケージに依存するかどうかを、判定する必要があります。パッケージの依存関係と非互換性は、2 つのオプションパッケージ情報ファイル、compver と depend で定義できます。
compver ファイルを提供することで、インストールされているパッケージと互換性のある、以前のバージョンのパッケージを指定できます。
depend ファイルを提供することで、パッケージに関連付けられた 3 種類の依存関係を定義できます。依存タイプには次の 3 種類があります。
depend ファイルは、とても基本的な依存関係のみを判定します。作成するパッケージが特定のファイル、そのファイルの内容、動作に依存する場合、depend ファイルによる判定だけでは正確性は十分ではありません。このような場合は、request スクリプトまたは checkinstall スクリプトを使用して、詳細な依存関係チェックを行うようにしてください。checkinstall スクリプトは、パッケージのインストールプロセスをクリーンに停止できる唯一のスクリプトでもあります。
depend ファイルと compver ファイルのエントリが prototype ファイルにあることを確認してください。ファイルタイプは、i (パッケージ情報ファイル) としてください。
詳細は、depend(4) および compver(4) のマニュアルページを参照してください。
以前のバージョンのパッケージが存在し、新しいパッケージと互換性があることを指定する必要がある場合は、任意のテキストエディタを使用して compver という名前のファイルを作成します。
作成するパッケージと互換性があるバージョンを一覧表示します。次の形式を使用します。
string string . . . |
string の値は、各互換パッケージの pkginfo ファイルの VERSION パラメータに割り当てられている値と同じです。
ファイルを保存してエディタを終了します。
作成するパッケージがほかのパッケージの存在に依存する場合、ほかのパッケージが作成するパッケージの存在に依存する場合、または作成するパッケージが別のパッケージと互換性がない場合は、任意のテキストエディタを使用して depend という名前のファイルを作成します。
依存関係ごとにエントリを追加します。次の形式を使用します。
type pkg-abbrev pkg-name (arch) version (arch) version . . . |
依存タイプを定義します。次のいずれかの文字を指定する必要があります。 P (必須パッケージ)、I (非互換パッケージ)、または R (逆依存)。
パッケージの省略名を指定します (SUNWcadap など)。
完全なパッケージ名を指定します。たとえば、「Chip designers need CAD application software to design abc chips. Runs only on xyz hardware and is installed in the usr partition.」などです。
省略可能。パッケージが稼働するハードウェアの種類を指定します。たとえば、sparc や x86 などです。アーキテクチャーを指定する場合は、区切り文字として丸括弧を使用する必要があります。
省略可能。pkginfo ファイルで VERSION パラメータに割り当てられている値を指定します。
詳細については、depend(4) を参照してください。
ファイルを保存してエディタを終了します。
次のいずれかの作業を完了します。
追加情報ファイルおよびインストールスクリプトを作成する場合は、次の作業、「著作権に関するメッセージを書く方法」に進んでください。
prototype ファイルを作成していない場合は、「pkgproto コマンドを使用して prototype ファイルを作成する方法」の手順を完了して、手順 7 に進んでください。
prototype ファイルをすでに作成している場合は、それを編集し、前の手順で作成した各ファイルのエントリを追加します。
パッケージを構築します。
必要な場合は、「パッケージの構築方法」を参照してください。
この例では、パッケージには 4 つのバージョンがあります。 1.0、1.1、2.0、および新しいパッケージの 3.0 です。新しいパッケージは、以前の 3 つのバージョンすべてと互換性があります。最新バージョンの compver ファイルは次のような内容です。
release 3.0 release 2.0 version 1.1 1.0 |
エントリは、順番になっていなくてもかまいません。ただし、各パッケージの pkginfo ファイルでの VERSION パラメータの定義と正確に一致するようにしてください。この例では、パッケージ設計者は最初の 3 つのバージョンで異なる形式を使用しています。
この例では、サンプルパッケージ SUNWcadap は、SUNWcsr パッケージと SUNWcsu パッケージがターゲットシステムにすでにインストールされている必要があるものとします。 SUNWcadap の depend ファイルは、次のような内容です。
P SUNWcsr Core Solaris, (Root) P SUNWcsu Core Solaris, (Usr) |
パッケージを構築したあと、実際にインストールして、正しくインストールされることを確認し、整合性を検証します。第 4 章パッケージの確認と転送では、これらの作業について説明し、検証済みのパッケージを配布媒体に転送する方法の手順を示します。
パッケージのインストール中に著作権に関するメッセージを表示するべきかどうかを決める必要があります。表示する必要がある場合は、copyright ファイルを作成します。
ソフトウェアアプリケーションを法的に保護するには、copyright ファイルを含めるようにしてください。メッセージの正確な文言については、会社の法務部門に確認してください。
著作権に関するメッセージを提供するには、copyright という名前のファイルを作成する必要があります。インストール中に、ファイルに記述されているとおりに (書式設定されずに) メッセージが表示されます。詳細については、copyright(4) のマニュアルページを参照してください。
copyright ファイルのエントリが prototype ファイルにあることを確認してください。ファイルタイプは、i (パッケージ情報ファイル) としてください。
任意のテキストエディタを使用して、copyright という名前のファイルを作成します。
パッケージのインストール時に表示する、著作権に関するメッセージの文章を、正確に入力します。
ファイルを保存してエディタを終了します。
次のいずれかの作業を完了します。
追加情報ファイルおよびインストールスクリプトを作成する場合は、次の作業、「ターゲットシステムに追加領域を予約する方法」に進んでください。
prototype ファイルを作成していない場合は、「pkgproto コマンドを使用して prototype ファイルを作成する方法」の手順を完了して、手順 5 に進んでください。
prototype ファイルをすでに作成している場合は、それを編集し、前の手順で作成した情報ファイルのエントリを追加します。
パッケージを構築します。
必要な場合は、「パッケージの構築方法」を参照してください。
たとえば、著作権に関するメッセージの一部分は次のようになります。
Copyright (c) 2003 Company Name All Rights Reserved This product is protected by copyright and distributed under licenses restricting copying, distribution, and decompilation. |
パッケージを構築したあと、実際にインストールして、正しくインストールされることを確認し、整合性を検証します。第 4 章パッケージの確認と転送では、これらの作業について説明し、検証済みのパッケージを配布媒体に転送する方法の手順を示します。
ターゲットシステムでは、パッケージは追加のディスク領域が必要かどうかを判定する必要があります。この領域は、パッケージオブジェクトで必要な領域とは別に追加するものです。必要な場合は、space 情報ファイルを作成します。この作業は、「インストール時に作成される追加のオブジェクトの定義」で説明した、インストール時の空のファイルとディレクトリの作成とは異なるものです。
pkgadd コマンドを使用すると、pkgmap ファイルでのオブジェクト定義に基づいて、パッケージのインストールに十分なディスク領域が確保されます。ただし、パッケージでは、pkgmap ファイルで定義されているオブジェクトが必要とするディスク領域以上の追加の領域が必要になる場合があります。たとえば、パッケージのインストール後に、ディスク領域を消費するデータベース、ログファイルなど、ファイルサイズが大きくなる可能性があるファイルが作成されるような場合です。このような場合のために領域を予約するには、必要なディスク領域を指定する space ファイルを含めるようにしてください。pkgadd コマンドは、space ファイルで指定されている追加領域をチェックします。詳細については、space(4) のマニュアルページを参照してください。
space ファイルのエントリが prototype ファイルにあることを確認してください。ファイルタイプは、i (パッケージ情報ファイル) としてください。
任意のテキストエディタを使用して、spacet という名前のファイルを作成します。
パッケージに必要な追加ディスク領域の要件を指定します。次の形式を使用します。
pathname blocks inodes |
ディレクトリ名を指定します。ファイルシステムのマウントポイントであってもなくてもかまいません。
予約する 512 バイトブロックの数を指定します。
必要な i ノードの数を指定します。
詳細については、space(4) のマニュアルページを参照してください。
ファイルを保存してエディタを終了します。
次のいずれかの作業を完了します。
インストールスクリプトを作成する場合は、次の作業、「request スクリプトを書く方法」に進んでください。
prototype ファイルを作成していない場合は、「pkgproto コマンドを使用して prototype ファイルを作成する方法」の手順を完了して、手順 5 に進んでください。
prototype ファイルをすでに作成している場合は、それを編集し、前の手順で作成した情報ファイルのエントリを追加します。
パッケージを構築します。
必要な場合は、「パッケージの構築方法」を参照してください。
この space ファイルの例では、1000 個の 512 バイトブロックと 1 個の i ノードをターゲットシステムの /opt ディレクトリに予約するように指定しています。
/opt 1000 1 |
パッケージを構築したあと、実際にインストールして、正しくインストールされることを確認し、整合性を検証します。第 4 章パッケージの確認と転送では、これらの作業について説明し、検証済みのパッケージを配布媒体に転送する方法の手順を示します。
この節では、オプションのパッケージインストールスクリプトについて説明します。pkgadd コマンドでは、パッケージ情報ファイルが入力として使用され、パッケージのインストールに必要なすべてのアクションが自動的に実行されます。パッケージインストールスクリプトを提供する必要はありません。ただし、カスタマイズしたインストール手順を作成する場合は、インストールスクリプトを使用して実現できます。インストールスクリプトには次の条件があります。
Bourne シェル (sh) で実行可能である必要があります。
Bourne シェルのコマンドとテキストで構成します。
#!/bin/sh シェル識別子を含める必要はありません。
実行可能ファイルである必要はありません。
カスタマイズしたアクションを実行できるインストールスクリプトには 4 種類あります。
request スクリプトは、パッケージをインストールしている管理者に、環境変数の割り当てまたは再定義のためのデータを要求します。
checkinstall スクリプトは、ターゲットシステムで必要なデータがあるかを検査し、パッケージの環境変数を設定または変更して、インストールを続行するかどうかを判定します。
checkinstall スクリプトは、Solaris 2.5 およびその互換リリース以降で使用できます。
手続きスクリプトは、パッケージのインストールまたは削除の前後に呼び出される手続きを特定します。手続きスクリプトには、preinstall、postinstall、preremove および postremove の 4 種類があります。
クラスアクションスクリプトでは、インストールまたは削除の間にファイルのクラスに適用するべき 1 つまたは複数のアクションを定義します。独自のクラスを定義できます。または、4 つの標準クラス (sed、awk、build、および preserve) のいずれかを使用することもできます。
使用するスクリプトの種類は、インストールプロセスのどの時点でスクリプトのアクションが必要かによって決まります。パッケージのインストールでは、pkgadd コマンドは次の手順を実行します。
request スクリプトを実行します。
checkinstall スクリプトを実行します。
checkinstall スクリプトは、ファイルシステムのデータを収集し、環境変数の定義を作成または変更して、以降のインストールを制御できます。パッケージ環境変数の詳細については、「パッケージ環境変数」を参照してください。
インストールするクラスごとに、パッケージオブジェクトをインストールします。
これらのファイルのインストールはクラスごとに行われ、それに従ってクラスアクションスクリプトが実行されます。対象となるクラスのリストおよびインストールの順序は、最初は pkginfo ファイルの CLASSES パラメータで定義されています。ただし、request スクリプトまたは checkinstall スクリプトで、CLASSES パラメータの値を変更できます。インストール時のクラスの処理方法の詳細については、「パッケージインストール時のクラスの処理方法」を参照してください。
パッケージを削除するときは、pkgrm コマンドで次の手順が実行されます。
各クラスのパッケージオブジェクトを削除します。
削除もクラスごとに行われます。削除スクリプトは、CLASSES パラメータで定義されている順序に基づいて、インストールの逆の順序で処理されます。インストール時のクラスの処理方法の詳細については、「パッケージインストール時のクラスの処理方法」を参照してください。
ハードリンクを削除します。
通常ファイルを削除します。
シンボリックリンク、デバイス、および名前付きパイプを削除します。
request スクリプトは、パッケージの削除時には処理されません。ただし、このスクリプトの出力はインストールされたパッケージに保持されており、削除スクリプトで利用できます。request スクリプトの出力は、環境変数のリストです。
次の環境変数のグループは、すべてのインストールスクリプトで使用できます。一部の環境変数は、request スクリプトまたは checkinstall スクリプトで変更できます。
request スクリプトまたは checkinstall スクリプトでは、pkginfo ファイルに含まれる標準パラメータのうち、必須パラメータ以外のいずれかのパラメータを設定または変更できます。標準インストールパラメータの詳細については、pkginfo(4) のマニュアルページを参照してください。
BASEDIR パラメータは、Solaris 2.5 リリースおよびその互換リリース以降でのみ変更できます。
pkginfo ファイルで値を割り当てることにより、独自のインストール環境変数を定義できます。このような環境変数の名前は、先頭が大文字の英数字でなければなりません。これらの環境変数はすべて、request スクリプトまたは checkinstall スクリプトで変更できます。
request スクリプトと checkinstall スクリプトのどちらでも、環境変数に値を割り当ててインストール環境に設定することで、新しい環境変数を定義できます。
次の表は、環境を通じてすべてのインストールスクリプトで使用できる環境変数の一覧です。これらの環境変数はいずれも、スクリプトでは変更できません。
環境変数 |
説明 |
---|---|
CLIENT_BASEDIR |
ターゲットシステムに関するベースディレクトリ。BASEDIR はインストールシステム (通常はサーバー) から特定のパッケージオブジェクトを参照する場合に使用する変数ですが、CLIENT_BASEDIR はクライアントシステムに配置されるファイルに格納するパスです。CLIENT_BASEDIR は、BASEDIR が存在する場合に存在し、PKG_INSTALL_ROOT がない場合は BASEDIR と同じです。 |
INST_DATADIR |
現在読み取られているパッケージが配置されるディレクトリ。パッケージがテープから読み取られている場合、この変数は、パッケージがディレクトリ形式に転送された一時ディレクトリの場所を表します。つまり、パッケージ名に拡張子がないとすると (SUNWstuff.d など)、現在のパッケージの request スクリプトは $INST_DATADIR/$PKG/install にあります。 |
PATH |
スクリプトの呼び出しでコマンドを見つけるために sh が使用する検索リスト。通常、PATH は /sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin に設定されています。 |
PKGINST |
インストールされているパッケージのインスタンス識別子。パッケージの別のインスタンスがまだインストールされていない場合、値はパッケージの省略名 (SUNWcadap など) です。すでにインストールされている場合は、パッケージの省略名のあとに接尾辞が付加された値 (SUNWcadap.4 など) になります。 |
PKGSAV |
削除スクリプトで使用するためにファイルを保存できるディレクトリ、または以前に保存されたファイルを見つけることのできるディレクトリ。Solaris 2.5 リリースおよびその互換リリースでのみ使用できます。 |
PKG_CLIENT_OS |
パッケージがインストールされているクライアントのオペレーティング システム。この変数の値は Solaris です。 |
PKG_CLIENT_VERSION |
x.y 形式の Solaris のバージョン。 |
PKG_CLIENT_REVISION |
Solaris 構築リビジョン。 |
PKG_INSTALL_ROOT |
パッケージがインストールされているターゲットシステムのルートファイルシステム。この変数は、pkgadd コマンドと pkgrm コマンドが -R オプションを指定して呼び出された場合にのみ存在します。このように条件付きで存在するため、手続きスクリプトでは、${PKG_INSTALL_ROOT}/somepath の形式で容易に使用できます。 |
PKG_NO_UNIFIED |
pkgadd コマンドと pkgrm コマンドが -M および -R オプションを指定して呼び出された場合に設定される環境変数。この環境変数は、パッケージ環境の一部であるいずれかのパッケージインストールスクリプトまたはパッケージコマンドに渡されます。 |
UPDATE |
この環境変数は、ほとんどのインストール環境には存在しません。この変数が存在する場合は値が yes に設定され、次の 2 つのどちらかを意味します。同じ名前、バージョン、およびアーキテクチャーのパッケージが、システムにすでに存在します。または、このパッケージは、管理者の指示により、同じ名前のインストール済みパッケージを上書きしています。これらの場合は、元のベースディレクトリが常に使用されます。 |
スクリプトから 2 つのコマンドを使用して、パッケージについての情報を要求できます。
pkgparam コマンドは、要求された環境変数の値を返します。
詳細は、pkginfo(1) マニュアルページ、pkgparam(1) マニュアルページ、および第 4 章パッケージの確認と転送を参照してください。
各スクリプトは、次の表に示す終了コードのいずれかで終了する必要があります。
表 3–2 インストールスクリプトの終了コード
コード |
意味 |
---|---|
0 |
スクリプトが正常終了したことを表します。 |
1 |
致命的エラーが発生したことを表します。インストールプロセスは、この段階で終了します。 |
2 |
警告、またはエラーの可能性がある状態です。インストールは継続されます。警告メッセージは、インストール完了時に表示されます。 |
3 |
pkgadd コマンドがクリーンに停止されたことを表します。checkinstall スクリプトのみがこのコードを返します。 |
10 |
選択されているすべてのパッケージのインストールが完了した時点で、システムが再起動されるべきであることを表します (この値は、1 桁の終了コードに追加されるはずです)。 |
20 |
現在のパッケージのインストールが終了したら、ただちにシステムを再起動するべきであることを表します (この値は、1 桁の終了コードに追加されるはずです)。 |
インストールスクリプトによって返される終了コードの例については、第 5 章パッケージ作成のケーススタディーを参照してください。
パッケージとともに提供されるすべてのインストールスクリプトは、prototype ファイルにエントリするようにしてください。ファイルタイプは、i (パッケージインストールスクリプトの場合) としてください。
request スクリプトは、パッケージをインストールしている管理者とパッケージが直接対話できる唯一の手段です。たとえば、このスクリプトを使用すると、パッケージのオプション部分をインストールするべきかどうかを、管理者に尋ねることができます。
request スクリプトの出力は、環境変数とその値のリストでなければなりません。このリストは、pkginfo ファイルで作成したいずれかのパラメータおよび CLASSES と BASEDIR パラメータを含むことができます。また、リストでは、どこでも定義されていない環境変数を使用することもできます。ただし、実際に使用するには、pkginfo ファイルでデフォルト値を提供するようにしてください。パッケージ環境変数の詳細については、「パッケージ環境変数」を参照してください。
request スクリプトで環境変数に値を割り当てるときは、pkgadd コマンドやほかのパッケージスクリプトでこの値を使用できるようにする必要があります。
request スクリプトでは、どのファイルも変更できません。このスクリプトは、パッケージをインストールしている管理者と対話し、その対話に基づいて環境変数割り当てのリストを作成するだけです。request スクリプトは、特権を持たないユーザー install が存在する場合は、そのユーザーとして実行されます。それ以外の場合は、スクリプトは root として実行されます。
pkgadd コマンドは、スクリプトの応答ファイルを示す 1 つの引数を指定して、request スクリプトを呼び出します。応答ファイルには、管理者の応答が格納されます。
request スクリプトは、パッケージ削除時には実行されません。ただし、このスクリプトによって割り当てられた環境変数は保存され、パッケージ削除時に使用できます。
パッケージごとに存在できる request スクリプトは 1 つだけです。スクリプトの名前は、request でなければなりません。
環境変数の割り当ては、pkgadd コマンドやほかのパッケージスクリプトが使用できるように、応答ファイル (スクリプトには $1 として認識される) に書き込むことで、インストール環境に追加するようにしてください。
CLASSES および BASEDIR パラメータを除くシステム環境変数と標準インストール環境変数は、request スクリプトでは変更できません。独自に作成されたほかの環境変数はすべて変更できます。
request スクリプトで BASEDIR パラメータを変更できるリリースは、Solaris 2.5 およびその互換リリース以降のみです。
request スクリプトで操作する可能性のあるすべての環境変数に、pkginfo ファイルのデフォルト値を割り当てるようにしてください。
出力リストは、PARAM=value の形式としてください。次に例を示します。
CLASSES=none class1 |
request スクリプトに対しては、管理者の端末が標準入力として定義されます。
request スクリプトでは、ターゲットシステムについての特別な分析は一切実行しないでください。特定のバイナリまたは動作がシステムに存在するかどうかをテストすること、およびその分析に基づいて環境変数を設定することは危険です。インストール時に request スクリプトが実際に実行される保証はありません。パッケージをインストールする管理者が、request スクリプトを呼び出さないで、環境変数を挿入する応答ファイルを提供する可能性があります。request スクリプトでもターゲットファイルシステムを評価している場合、その評価は行われないことがあります。特別な処理についてのターゲットシステムの分析は、checkinstall スクリプトに任せるのが最善です。
パッケージをインストールする管理者が JumpStartTM 製品を使用する可能性がある場合は、パッケージのインストールを対話形式にしてはいけません。パッケージで request スクリプトを提供しないようにするか、インストールの前に pkgask コマンドを使用するべきであることを管理者に伝える必要があります。pkgask コマンドは、応答を request スクリプトに格納します。pkgask コマンドの詳細については、pkgask(1M) のマニュアルページを参照してください。
任意のテキストエディタを使用して、request という名前のファイルを作成します。
ファイルを保存してエディタを終了します。
次のいずれかの作業を完了します。
追加のインストールスクリプトを作成する場合は、次の作業、「ファイルシステムデータを収集する方法」に進んでください。
prototype ファイルを作成していない場合は、「pkgproto コマンドを使用して prototype ファイルを作成する方法」の手順を完了して、手順 5 に進んでください。
prototype ファイルをすでに作成している場合は、それを編集し、前の手順で作成したインストールスクリプトのエントリを追加します。
パッケージを構築します。
必要な場合は、「パッケージの構築方法」を参照してください。
request スクリプトで環境変数に値を割り当てるときは、その値を pkgadd コマンドで使用できるようにする必要があります。この例では、4 つの環境変数についてこの作業を実行する request スクリプトのセグメントを示します。 環境変数は、CLASSES、NCMPBIN、EMACS、および NCMPMAN です。これらの環境変数は、スクリプトですでに、管理者との対話セッションで定義されているものとします。
# make environment variables available to installation # service and any other packaging script we might have cat >$1 <<! CLASSES=$CLASSES NCMPBIN=$NCMPBIN EMACS=$EMACS NCMPMAN=$NCMPMAN ! |
パッケージを構築したあと、実際にインストールして、正しくインストールされることを確認し、整合性を検証します。第 4 章パッケージの確認と転送では、これらの作業について説明し、検証済みのパッケージを配布媒体に転送する方法の手順を示します。
checkinstall スクリプトは、オプションの request スクリプトの直後に実行されます。checkinstall スクリプトは、install ユーザーが存在する場合はそのユーザーとして、存在しない場合は nobody ユーザーとして実行します。checkinstall スクリプトには、ファイルシステムのデータを変更する権限はありません。ただし、スクリプトが収集する情報に基づいて、環境変数を作成または変更し、以降のインストールを制御できます。また、このスクリプトは、インストールプロセスをクリーンに停止することもできます。
checkinstall スクリプトは、pkgadd コマンドにとって普通ではない、ファイルシステム上の基本的なチェックを行うためのものです。たとえば、このスクリプトを使用して、現在のパッケージのいずれかのファイルが既存のファイルを上書きするかどうかを事前にチェックしたり、一般的なソフトウェアの依存関係を管理したりできます。depend ファイルは、パッケージレベルの依存関係のみを管理します。
request スクリプトとは異なり、checkinstall スクリプトは応答ファイルが提供されるかどうかに関係なく実行されます。スクリプトが存在しても、パッケージが対話型としてブランドを設定されることはありません。checkinstall スクリプトは、request スクリプトが使用できない場合、または管理的な対話が実際的ではない場合に使用できます。
checkinstall スクリプトは、Solaris 2.5 およびその互換リリース以降で使用できます。
checkinstall スクリプトは、どのファイルも変更できません。このスクリプトは、システムの状態を分析し、その対話に基づいて環境変数割り当てのリストを作成するだけです。この制限を強制するため、checkinstall スクリプトは、特権を持たないユーザー install が存在する場合は、このユーザーとして実行されます。このユーザーが存在しない場合は、特権を持たないユーザー nobody として実行されます。checkinstall スクリプトには、スーパーユーザー権限はありません。
pkgadd コマンドは、スクリプトの応答ファイルを示す 1 つの引数を指定して、checkinstall スクリプトを呼び出します。スクリプトの応答ファイルは、管理者の応答を格納するファイルです。
checkinstall スクリプトは、パッケージ削除時には実行されません。ただし、このスクリプトによって割り当てられた環境変数は保存され、パッケージ削除時に使用できます。
パッケージごとに存在できる checkinstall スクリプトは 1 つだけです。スクリプトの名前は、checkinstall でなければなりません。
環境変数の割り当ては、pkgadd コマンドやほかのパッケージスクリプトが使用できるように、応答ファイル (スクリプトには $1 として認識される) に書き込むことで、インストール環境に追加するようにしてください。
CLASSES および BASEDIR パラメータを除くシステム環境変数と標準インストール環境変数は、checkinstall スクリプトでは変更できません。独自に作成されたほかの環境変数はすべて変更できます。
checkinstall スクリプトで操作する可能性のあるすべての環境変数に、pkginfo ファイルでデフォルト値を割り当てるようにしてください。
出力リストは、PARAM=value の形式としてください。次に例を示します。
CLASSES=none class1 |
checkinstall スクリプトの実行中は、管理者と対話することはできません。管理者との対話はすべて、request スクリプトに制限されます。
任意のテキストエディタを使用して、checkinstall という名前のファイルを作成します。
ファイルを保存してエディタを終了します。
次のいずれかの作業を完了します。
追加のインストールスクリプトを作成する場合は、次の作業、「手続きスクリプトを書く方法」に進んでください。
prototype ファイルを作成していない場合は、「pkgproto コマンドを使用して prototype ファイルを作成する方法」の手順を完了して、手順 5 に進んでください。
prototype ファイルをすでに作成している場合は、それを編集し、前の手順で作成したインストールスクリプトのエントリを追加します。
パッケージを構築します。
必要な場合は、「パッケージの構築方法」を参照してください。
checkinstall スクリプトのこの例では、SUNWcadap パッケージで必要なデータベースソフトウェアがインストールされているかどうかをチェックします。
# checkinstall script for SUNWcadap # # This confirms the existence of the required specU database # First find which database package has been installed. pkginfo -q SUNWspcdA # try the older one if [ $? -ne 0 ]; then pkginfo -q SUNWspcdB # now the latest if [ $? -ne 0 ]; then # oops echo "No database package can be found. Please install the" echo "SpecU database package and try this installation again." exit 3 # Suspend else DBBASE="`pkgparam SUNWsbcdB BASEDIR`/db" # new DB software fi else DBBASE="`pkgparam SUNWspcdA BASEDIR`/db" # old DB software fi # Now look for the database file we will need for this installation if [ $DBBASE/specUlatte ]; then exit 0 # all OK else echo "No database file can be found. Please create the database" echo "using your installed specU software and try this" echo "installation again." exit 3 # Suspend fi |
パッケージを構築したあと、実際にインストールして、正しくインストールされることを確認し、整合性を検証します。第 4 章パッケージの確認と転送では、これらの作業について説明し、検証済みのパッケージを配布媒体に転送する方法の手順を示します。
手続きスクリプトは、パッケージのインストールまたは削除に対する特定の段階で実行する一連の命令を提供します。4 つの手続きスクリプトには、命令をいつ実行するかに応じて、定義済みの名前のいずれかを設定する必要があります。スクリプトは、引数なしで実行されます。
クラスのインストールが開始する前に実行します。このスクリプトではファイルをインストールするべきではありません。
すべてのボリュームがインストールされたあとで実行します。
クラスの削除が開始する前に実行します。このスクリプトではファイルを削除するべきではありません。
すべてのクラスが削除されたあとで実行します。
手続きスクリプトは、uid=root および gid=other として実行されます。
各スクリプトは、パッケージ内のボリュームごとに 1 回実行されるので、1 回を超えて実行できるようにしてください。つまり、あるスクリプトの実行結果は、同じ入力であれば何度実行しても常に同じであることを意味します。
pkgmap ファイル内にないパッケージオブジェクトをインストールする各手続きスクリプトは、installf コマンドを使用して、パス名を追加または変更することをパッケージデータベースに通知する必要があります。すべての追加または変更が完了したあとでは、-f オプションを指定してこのコマンドを呼び出すようにしてください。この方法でパッケージオブジェクトをインストールできるスクリプトは、postinstall および postremove スクリプトのみです。詳細は、installf(1M) のマニュアルページおよび第 5 章パッケージ作成のケーススタディーを参照してください。
手続きスクリプトの実行中は、管理者と対話することはできません。管理者との対話はすべて、request スクリプトに制限されます。
pkgmap ファイルからインストールされたものではないファイルを削除する各手続きスクリプトは、removef コマンドを使用して、パス名を削除することをパッケージデータベースに通知する必要があります。削除が完了したあとでは、-f オプションを指定してこのコマンドを呼び出すようにしてください。詳細および例については、removef(1M) のマニュアルページおよび第 5 章パッケージ作成のケーススタディーを参照してください。
手続きスクリプトは pkgmap ファイルにリストされているパス名と自動的には関連付けられないので、installf および removef コマンドを使用する必要があります。
任意のテキストエディタを使用して、1 つ以上の手続きスクリプトを作成します。
手続きスクリプトの名前は、定義済みの名前のいずれかである必要があります。 つまり、preinstall、postinstall、preremove、または postremove です。
ファイルを保存してエディタを終了します。
次のいずれかの作業を完了します。
クラスアクションスクリプトを作成する場合は、次の作業、「クラスアクションスクリプトを書く方法」に進んでください。
prototype ファイルを作成していない場合は、「pkgproto コマンドを使用して prototype ファイルを作成する方法」の手順を完了して、手順 5 に進んでください。
prototype ファイルをすでに作成している場合は、それを編集し、前の手順で作成した各インストールスクリプトのエントリを追加します。
パッケージを構築します。
必要な場合は、「パッケージの構築方法」を参照してください。
パッケージを構築したあと、実際にインストールして、正しくインストールされることを確認し、整合性を検証します。第 4 章パッケージの確認と転送では、これらの作業について説明し、検証済みのパッケージを配布媒体に転送する方法の手順を示します。
オブジェクトクラスを使用すると、インストール時または削除時に、パッケージオブジェクトのグループに対して一連のアクションを実行できます。クラスへのオブジェクトの割り当ては、prototype ファイルで行います。すべてのパッケージオブジェクトにはクラスを指定する必要がありますが、特別なアクションを必要としないオブジェクトには、デフォルトで none クラスが使用されます。
pkginfo ファイルで定義されているインストールパラメータ CLASSES は、インストールするクラスのリストです ( none クラスを含みます)。
pkgmap ファイルで定義されていても、pkginfo ファイルのこのパラメータにリストされていないクラスに属するオブジェクトは、インストールされません。
CLASSES のリストで、インストールの順序が判定されます。none クラスがある場合は、常に最初にインストールされて、最後に削除されます。ディレクトリはほかのすべてのシステムオブジェクトに対する基礎となるサポート構造なので、すべてのディレクトリは none クラスに割り当てられるようにしてください。例外がある場合もありますが、一般的に none クラスが最も安全です。このようにすることで、ディレクトリに格納されるオブジェクトより前に、確実にディレクトリが作成されます。また、空になっていないディレクトリの削除が試みられることがありません。
次に、クラスのインストール時にシステムが実行するアクションについて説明します。アクションは、パッケージのボリュームごとに、そのボリュームのインストール時に 1 度行われます。
pkgadd コマンドは、アクションスクリプトの対象となるパス名のリストを作成します。このリストの各行には、ソースパス名とターゲットパス名がスペースで区切られて記述されています。ソースパス名は、インストールされるオブジェクトがインストールボリューム上で常駐する場所を示します。ターゲットパス名は、オブジェクトがインストールされるべきターゲットシステム上の場所を示します。リストの内容は、次の条件によって制限されます。
リストには、関連付けられたクラスに属するパス名のみが含まれます。
パッケージオブジェクトの作成が失敗すると、リストに含まれるディレクトリ、名前付きパイプ、文字デバイス、ブロックデバイス、およびシンボリックリンクには、/dev/null というソースパス名が設定されます。通常、これらのアイテムは pkgadd コマンドによって自動的に作成され (まだ存在しない場合)、pkgmap ファイルでの定義に従って適切な属性 (モード、所有者、グループ) が設定されます。
ファイルタイプが l のリンクファイルは、どのような場合にもリストには追加されません。特定のクラスのハードリンクは、以降の 4 番目のアクションで作成されます。
特定のクラスのインストールに対してクラスアクションスクリプトが提供されない場合は、生成されるリストのパス名が、ボリュームから適切なターゲットの場所にコピーされます。
クラスアクションスクリプトが存在する場合は実行されます。
クラスアクションスクリプトは、1 番目のアクションで生成されたリストを含む標準入力で呼び出されます。パッケージで最後のボリュームの場合、またはクラスで最後のオブジェクトの場合は、スクリプトは単一の引数 ENDOFCLASS を指定して実行されます。
このクラスの通常ファイルがパッケージ内に存在しない場合でも、クラスアクションスクリプトは、空のリストと ENDOFCLASS 引数で少なくとも 1 回は呼び出されます。
pkgadd コマンドがコンテンツと属性の監査を実行し、ハードリンクを作成します。
2 番目または 3 番目のアクションが正常に実行されたあと、pkgadd コマンドはパス名のリストについて内容と属性の情報を監査します。pkgadd コマンドは、クラスと関連付けられたリンクを自動的に作成します。生成されたリストのすべてのパス名について、検出された属性の不整合が修正されます。
オブジェクトはクラスごとに削除されます。パッケージに存在していても CLASSES パラメータに含まれないクラスが、最初に削除されます (たとえば、installf コマンドでインストールされたオブジェクト)。CLASSES パラメータにリストされているクラスが、逆の順序で削除されます。none クラスは、常に最後に削除されます。次に、クラスの削除時に行われるシステムのアクションについて説明します。
pkgrm コマンドが、パス名のリストを作成します。
pkgrm コマンドは、指定されたクラスに属するインストール済みのパス名のリストを作成します。別のパッケージによって参照されているパス名は、ファイルタイプが e であるものを除き、リストから除外されます。e というファイルタイプは、インストール時または削除時にファイルを編集するべきであることを意味します。
削除されるパッケージがインストール時にタイプ e のいずれかのファイルを変更していた場合は、そのときに追加した行だけを削除するようにしてください。空ではない編集可能なファイルは削除しないでください。パッケージが追加した行を削除します。
クラスアクションスクリプトが存在しない場合は、パス名が削除されます。
パッケージにクラスに対する削除クラスアクションスクリプトが存在しない場合は、pkgrm コマンドによって生成されたリストのすべてのパス名が削除されます。
ファイルタイプが e (編集可能) のファイルは、クラスおよび関連するクラスアクションスクリプトに割り当てられません。これらのファイルは、パス名がほかのパッケージと共有されている場合であっても、この時点で削除されます。
クラスアクションスクリプトが存在する場合は、実行されます。
pkgrm コマンドが、1 番目のアクションで生成されたリストを含む、スクリプトに対する標準入力でクラスアクションスクリプトを呼び出します。
pkgrm コマンドが監査を実行します。
クラスアクションスクリプトの実行に成功したあと、pkgrm コマンドは、パス名が別のパッケージによって参照されていない場合は、パッケージデータベースからパス名への参照を削除します。
クラスアクションスクリプトは、パッケージのインストールまたは削除時に実行される一連のアクションを定義しています。アクションは、クラス定義に基づいてパス名のグループに対して実行されます。クラスアクションスクリプトの例については、第 5 章パッケージ作成のケーススタディーを参照してください。
クラスアクションスクリプトの名前は、対象となるクラス、およびこれらの操作が、パッケージのインストール時や削除時に実行されるべきかどうかに基づきます。次の表では、2 種類の名前形式を示します。
名前の形式 |
説明 |
---|---|
i.class |
パッケージインストール時に、示されているクラスのパス名に対して実行されます。 |
r.class |
パッケージ削除時に、示されているクラスのパス名に対して実行されます。 |
たとえば、manpage という名前のクラスのインストールスクリプトの名前は、i.manpage となります。削除スクリプトは、r.manpage という名前になります。
このファイル名形式は、sed、awk、build の各システムクラスに属するファイルには使用されません。これらの特殊なクラスの詳細については、「特殊なシステムクラス」を参照してください。
スクリプトは、現在のボリューム上の指定されたクラスに含まれるすべてのファイルに対して実行されます。
pkgadd と pkgrm コマンドは、クラスに属する pkgmap ファイルにリストされているすべてのオブジェクトのリストを作成します。結果として、クラスアクションスクリプトは、特定のクラスに属する pkgmap で定義されているパス名に対してのみ実行できます。
クラスアクションスクリプトは、最後に実行されるときには (つまり、そのクラスに属しているクラスがそれ以上ないとき)、キーワード引数 ENDOFCLASS を指定して実行されます。
クラスアクションスクリプトの実行中は、管理者と対話することはできません。
パッケージが複数のボリュームに分かれている場合、クラスアクションスクリプトはクラスに属するファイルが 1 つでも含まれるボリュームごとに 1 回ずつ実行されます。したがって、各スクリプトは 2 回以上実行できるようになっている必要があります。つまり、あるスクリプトの実行結果は、同じ入力であれば何度実行しても同じになるということを意味します。
あるファイルがクラスアクションスクリプトを持つクラスの一部である場合、スクリプトはそのファイルをインストールする必要があります。pkgadd コマンドは、クラスアクションスクリプトが存在するファイルをインストールしませんが、インストールを検証します。
クラスアクションスクリプトでは、pkgadd コマンドで生成されるリストに出現しないパス名またはシステム属性を追加、削除、または変更してはいけません。このリストの詳細については、「パッケージインストール時のクラスの処理方法」の手順 1 を参照してください。
スクリプトで ENDOFCLASS 引数を検出した場合は、クリーンアップなどの事後処理アクションをスクリプトに組み込みます。
管理者との対話はすべて、request スクリプトに制限されます。クラスアクションスクリプトを使用して管理者から情報の取得を試みないでください。
パッケージのインストール時および削除時に sed 命令を使用してファイルを編集するための方法を提供します。
パッケージのインストール時および削除時に awk 命令を使用してファイルを編集するための方法を提供します。
Bourne シェルコマンドを使用してファイルを動的に作成または変更するための方法を提供します。
将来のパッケージのインストールによって上書きされるべきではないファイルを保持するための方法を提供します。
マニフェストに関連する SMF (サービス管理機能) サービスの自動的なインストールおよびアンインストールを提供します。パッケージ内のすべての SMF マニフェストに、manifest クラスが使用されなければなりません。
パッケージ内の複数のファイルで必要な特殊な処理が、sed、awk、または sh コマンドを使用して完全に定義できる場合は、システムクラスを使用すると、複数のクラスとそれに対応するクラスアクションスクリプトを使用するより、インストールの時間を短縮できます。
sed クラスは、ターゲットシステム上の既存オブジェクトを変更する方法を提供します。sed クラスアクションスクリプトは、sed クラスに属するファイルが存在する場合は、インストール時に自動的に実行されます。sed クラスアクションスクリプトの名前は、命令が実行される対象のファイルの名前と同じであるようにしてください。
sed クラスアクションスクリプトは、次の形式で sed 命令を提供します。
2 つのコマンドが、命令を実行する必要があるときを示します。!install コマンドに続く sed 命令は、パッケージのインストール時に実行されます。!remove コマンドに続く sed 命令は、パッケージの削除時に実行されます。ファイル内でこれらのコマンドが使用される順序は関係ありません。
sed 命令の詳細については、sed(1) のマニュアルページを参照してください。sed クラスアクションスクリプトの例については、第 5 章パッケージ作成のケーススタディーを参照してください。
awk クラスは、ターゲットシステム上の既存オブジェクトを変更する方法を提供します。変更は、awk クラスアクションスクリプト内の awk 命令として提供されます。
awk クラスアクションスクリプトは、awk クラスに属するファイルが存在する場合、インストール時に自動的に実行されます。このようなファイルには、awk クラススクリプトに対する命令が次の形式で含まれます。
2 つのコマンドが、命令を実行する必要があるときを示します。!install コマンドに続く awk 命令は、パッケージのインストール時に実行されます。!remove コマンドに続く命令は、パッケージの削除時に実行されます。これらのコマンドは、任意の順序で使用できます。
awk クラスアクションスクリプトの名前は、命令が実行される対象のファイルの名前と同じであるようにしてください。
変更対象のファイルは、awk コマンドに対する入力として使用され、スクリプトの出力は最終的に元のオブジェクトを置き換えます。この構文では、環境変数を awk コマンドに渡すことはできません。
awk 命令の詳細については、awk(1) のマニュアルページを参照してください。
build クラスは、Bourne シェルの命令を実行して、パッケージオブジェクトファイルを作成または変更します。これらの命令は、パッケージオブジェクトとして提供されます。パッケージオブジェクトが build クラスに属している場合は、インストール時に命令が自動的に実行されます。
build クラスアクションスクリプトの名前は、命令が実行される対象のファイルの名前と同じであるようにしてください。また、名前は sh コマンドで実行できる必要もあります。スクリプトの出力は、構築または変更されると新しいバージョンのファイルになります。スクリプトが出力を生成しない場合、ファイルは作成または変更されません。したがって、スクリプトはファイル自体を変更または作成できます。
たとえば、パッケージがデフォルトファイル /etc/randomtable を提供し、ファイルがターゲットシステム上にまだ存在しない場合は、prototype ファイルのエントリは次のような内容です。
e build /etc/randomtable ? ? ? |
また、パッケージオブジェクト /etc/randomtable は、次のような内容です。
!install # randomtable builder if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then echo "/etc/randomtable is already in place."; else echo "# /etc/randomtable" > $PKG_INSTALL_ROOT/etc/randomtable echo "1121554 # first random number" >> $PKG_INSTALL_ROOT/etc/randomtable fi !remove # randomtable deconstructor if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then # the file can be removed if it's unchanged if [ egrep "first random number" $PKG_INSTALL_ROOT/etc/randomtable ]; then rm $PKG_INSTALL_ROOT/etc/randomtable; fi fi |
build クラスを使用する別の例については、第 5 章パッケージ作成のケーススタディーを参照してください。
preserve クラスは、パッケージのインストール時に既存のファイルを上書きするべきかどうかを判定して、パッケージオブジェクトファイルを保持します。preserve クラススクリプトを使用する場合、2 つの可能なシナリオは次のとおりです。
インストールするファイルがターゲットディレクトリにまだ存在しない場合は、ファイルは正常にインストールされます。
インストールするファイルがターゲットディレクトリに存在する場合は、ファイルが存在することを示すメッセージが表示されて、ファイルはインストールされません。
どちらのシナリオの結果も、preserve スクリプトとしては成功と見なされます。失敗は、2 番目のシナリオでのみ発生し、ファイルをターゲットディレクトリにコピーできない場合です。
Solaris 7 リリース以降、i.preserve スクリプトおよびこのスクリプトのコピー i.CONFIG.prsv は、ほかのクラスアクションスクリプトとともに、/usr/sadm/install/scripts ディレクトリに置かれています。
保持するファイル名を含むには、スクリプトを変更します。
manifest クラスは、SMF マニフェストに関連する SMF (サービス管理機能) サービスを自動的にインストールおよびアンインストールします。SMF の詳細については、『Solaris のシステム管理 (基本編)』の第 16 章「サービスの管理 (概要)」で、SMF によるサービス管理の方法に関する情報を参照してください。
パッケージ内のすべてのサービスマニフェストは、クラス manifest によって識別されます。サービスマニフェストのインストールと削除を行うクラスアクションスクリプトは、パッケージ化サブシステムに含まれています。pkgadd(1M) が呼び出されると、サービスマニフェストがインポートされます。pkgrm(1M) が呼び出されると、無効になっているサービスマニフェスト内のインスタンスが削除されます。また、インスタンスが残っていないマニフェスト内のサービスもすべて削除されます。pkgadd(1M) または pkgrm(1M) に -R オプションを指定した場合、これらのサービスマニフェストアクションは、次にシステムが代替ルートパスでリブートしたときに実行されます。
次のパッケージ情報ファイルのコードの一部では、manifest クラスの使用が示されています。
# packaging files i pkginfo i copyright i depend i preinstall i postinstall i i.manifest i r.manifest # # source locations relative to the prototype file # d none var 0755 root sys d none var/svc 0755 root sys d none var/svc/manifest 0755 root sys d none var/svc/manifest/network 0755 root sys d none var/svc/manifest/network/rpc 0755 root sys f manifest var/svc/manifest/network/rpc/smserver.xml 0444 root sys
prototype ファイル内のパッケージオブジェクトに、目的のクラス名を割り当てます。
たとえば、application および manpage クラスへのオブジェクトの割り当ては、次のような内容です。
f manpage /usr/share/man/manl/myappl.1l f application /usr/bin/myappl |
pkginfo ファイル内の CLASSES パラメータを変更し、パッケージで使用するクラス名を追加します。
たとえば、application および manpage クラスのエントリは次のような内容です。
CLASSES=manpage application none |
none クラスは、CLASSES パラメータの定義での出現位置に関係なく、常に最初にインストールされて、最後に削除されます。
sed、awk、 build のいずれかのクラスに属するファイルのクラスアクションスクリプトを作成している場合は、パッケージオブジェクトを含むディレクトリを、現在の作業用ディレクトリにします。
クラスアクションスクリプトまたはパッケージオブジェクト (sed、awk、または build クラスに属すファイルの場合) を作成します。
たとえば、application という名前のクラスに対するインストールスクリプトは i.application という名前にし、削除スクリプトは r.application という名前にします。
あるファイルがクラスアクションスクリプトを持つクラスの一部である場合、スクリプトはそのファイルをインストールする必要があります。pkgadd コマンドは、クラスアクションスクリプトが存在するファイルをインストールしませんが、インストールを検証します。また、クラスを定義しても、クラスアクションスクリプトを提供しないと、そのクラスに対して行われるアクションは、インストールメディアからターゲットシステムへのコンポーネントのコピーだけです (pkgadd のデフォルトの動作)。
次のいずれかの作業を完了します。
prototype ファイルを作成していない場合は、「pkgproto コマンドを使用して prototype ファイルを作成する方法」の手順を完了し、手順 7 に進んでください。
prototype ファイルをすでに作成している場合は、それを編集し、前の手順で作成した各インストールスクリプトのエントリを追加します。
パッケージを構築します。
必要な場合は、「パッケージの構築方法」を参照してください。
パッケージを構築したあと、実際にインストールして、正しくインストールされることを確認し、整合性を検証します。第 4 章パッケージの確認と転送では、この作業について説明し、検証済みのパッケージを配布媒体に転送する方法の手順を示します。
署名付きパッケージを作成するプロセスには、複数の手順が含まれ、新しい概念と用語を理解する必要があります。この節では、署名付きパッケージ、その用語、および証明書管理に関して説明します。この節では、署名付きパッケージの作成手順についても説明します。
署名付きパッケージは、次のことを証明するデジタル署名 (次に定義する、PEM で符号化された PKCS7 デジタル署名) の付いた通常のストリーム形式のパッケージです。
そのパッケージに署名したエンティティーがそのパッケージの作成者である。
そのエンティティーが実際にそのパッケージに署名した。
そのパッケージがエンティティーによる署名後に変更されていない。
そのパッケージに署名したエンティティーが信頼されたエンティティーである。
署名付きパッケージは、署名が付いている点以外は、署名なしパッケージと同一です。署名付きパッケージと署名なしパッケージは、バイナリレベルで互換性があります。したがって、署名付きパッケージは古いバージョンのパッケージツールで使用できます。ただし、その場合、署名は無視されます。
署名付きパッケージ技術には新しい用語と省略名がいくつかあり、それについて次の表で説明します。
署名付きパッケージを作成するには、先にパッケージキーストアが存在している必要があります。このパッケージキーストアには、証明書がオブジェクトの形式で含まれます。パッケージキーストアには、2 種類のオブジェクトが存在します。
信頼できる証明書には、別のエンティティーに属する単一の公開鍵証明書が含まれます。信頼できる証明書という呼び名は、証明書に含まれる公開鍵が、その証明書の「サブジェクト」(所有者) によって示された本人のものであることを、キーストアの所有者が信頼することに由来しています。この信頼を表明するために、証明書の発行者はその証明書に署名します。
信頼できる証明書は、署名を検証するとき、およびセキュリティー保護されたサーバーへの接続 (SSL) を開始するときに使用されます。
ユーザー鍵は、暗号鍵に関する機密情報を保持します。この情報は、不正なアクセスを防ぐために、セキュリティーが施された形式で格納されます。ユーザー鍵は、ユーザーの非公開鍵と対応する公開鍵証明書から構成されます。
ユーザー鍵は、署名付きパッケージを作成するときに使用されます。
デフォルトでは、パッケージキーストアは /var/sadm/security ディレクトリに格納されます。個別のユーザーも、独自のキーストアをデフォルトで $HOME/.pkg/security ディレクトリに格納できます。
ディスク上でのパッケージキーストアには、2 種類の形式があります。 つまり、複数ファイル形式と単一ファイル形式です。複数ファイル形式は、オブジェクトを複数のファイルに格納します。オブジェクトの種類ごとに、異なるファイルに保存されます。これらのファイルはすべて、同じパスフレーズを使用して暗号化される必要があります。単一ファイルキーストアは、すべてのオブジェクトをファイルシステムの単一のファイルに格納します。
証明書とパッケージキーストアの管理に使用する主なユーティリティは、pkgadm コマンドです。次に、パッケージキーストアの管理に使用される一般的な作業について説明します。
信頼できる証明書をパッケージキーストアに追加するには、pkgadm コマンドを使用します。PEM または DER の形式の証明書を使用できます。次に例を示します。
$ pkgadm addcert -t /tmp/mytrustedcert.pem |
この例では、mytrustedcert.pem という名前の PEM 形式の証明書を、パッケージキーストアに追加します。
pkgadm コマンドは、ユーザー証明書または非公開鍵は生成しません。ユーザー証明書と非公開鍵は、通常、Verisign などの認証局から入手します。または、自己署名付き証明書としてローカルで生成します。入手した鍵と証明書は、pkgadm コマンドを使用してパッケージキーストアにインポートできます。次に例を示します。
pkgadm addcert -n myname -e /tmp/myprivkey.pem /tmp/mypubcert.pem |
この例では、次のオプションを使用しています。
-n myname |
パッケージキーストアに含まれる対象のエンティティー (myname) を特定します。myname エンティティーは、オブジェクトが格納される別名になります。 |
-e /tmp/myprivkey.pem |
非公開鍵を含むファイルを指定します。この場合、ファイルは myprivkey.pem であり、/tmp ディレクトリにあります。 |
/tmp/mypubcert.pem |
mypubcert.pem という名前の PEM 形式の証明書ファイルを指定します。 |
pkgadm コマンドは、パッケージキーストアの内容の表示にも使用します。次に例を示します。
$ pkgadm listcert |
このコマンドは、パッケージキーストアに含まれる信頼できる証明書と非公開鍵を表示します。
pkgadm コマンドを使用すると、信頼できる証明書と非公開鍵をパッケージキーストアから削除できます。
ユーザー証明書を削除するときは、証明書と鍵のペアの別名を指定する必要があります。次に例を示します。
$ pkgadm removecert -n myname |
証明書の別名は証明書の共通名であり、pkgadm listcert コマンドを使用して識別できます。たとえば、次のコマンドは、Trusted CA Cert 1 という名前の信頼できる証明書を削除します。
$ pkgadm removecert -n "Trusted CA Cert 1" |
信頼できる証明書とユーザー証明書を同じ別名で保存した場合は、-n オプションを指定するとどちらも削除されます。
署名付きパッケージ作成のプロセスは、3 つの基本手順から成ります。
署名なしディレクトリ形式パッケージの作成。
署名証明書、CA 証明書、および非公開鍵のパッケージキーストアへのインポート。
手順 2 の証明書による手順 1 のパッケージへの署名。
パッケージツールでは証明書は作成されません。これらの証明書は、Verisign や Thawte などの認証局から入手する必要があります。
次に、署名付きパッケージ作成の各手順について説明します。
署名なしディレクトリ形式パッケージを作成する手順は、すでに説明した通常のパッケージの作成手順と同じです。次の手順では、この署名なしディレクトリ形式パッケージを作成するプロセスを説明します。詳細については、パッケージの構築に関する前の節を参照してください。
pkginfo ファイルは、次の基本的な内容となるようにしてください。
PKG=SUNWfoo BASEDIR=/ NAME=My Test Package ARCH=sparc VERSION=1.0.0 CATEGORY=application |
prototye ファイルは、次の基本的な内容となるようにしてください。
$cat prototype i pkginfo d none usr 0755 root sys d none usr/bin 0755 root bin f none usr/bin/myapp=/tmp/myroot/usr/bin/myapp 0644 root bin |
オブジェクトソースディレクトリの内容を一覧表示します。
次に例を示します。
$ ls -lR /tmp/myroot |
/tmp/myroot: total 16 drwxr-xr-x 3 abc other 177 Jun 2 16:19 usr /tmp/myroot/usr: total 16 drwxr-xr-x 2 abc other 179 Jun 2 16:19 bin /tmp/myroot/usr/bin: total 16 -rw------- 1 abc other 1024 Jun 2 16:19 myapp |
署名なしパッケージを作成します。
pkgmk -d `pwd` |
出力は次のような内容です。
## Building pkgmap from package prototype file. ## Processing pkginfo file. WARNING: parameter <PSTAMP> set to "syrinx20030605115507" WARNING: parameter <CLASSES> set to "none" ## Attempting to volumize 3 entries in pkgmap. part 1 -- 84 blocks, 7 entries ## Packaging one part. /tmp/SUNWfoo/pkgmap /tmp/SUNWfoo/pkginfo /tmp/SUNWfoo/reloc/usr/bin/myapp ## Validating control scripts. ## Packaging complete. |
現在のディレクトリにパッケージが存在するようになります。
インポートする証明書と非公開鍵は、PEM または DER で符号化された X.509 である必要があります。さらに、署名する証明書を認証局証明書にリンクするいずれかの中間、つまり「チェーン」証明書も、パッケージに署名する前にパッケージキーストアにインポートする必要があります。
各認証局は、さまざまな形式で証明書を発行できます。PKCS12 ファイルから PEM 符号化された X.509 ファイル (パッケージキーストアへのインポートに適したもの) に証明書と非公開鍵を抽出するには、OpenSSL などのフリーウェアの変換ユーティリティを使用します。
非公開鍵が暗号化されている場合 (通常の場合) は、パスフレーズの入力を求められます。また、生成されるパッケージキーストアを保護するためのパスワードの指定を求められます。パスワードを指定しないこともできますが、その場合は、生成されるパッケージキーストアは暗号化されません。
次の手順では、証明書が適切な形式になったあと、pkgadm コマンドを使用して証明書をインポートする方法について説明します。
PEM または DER で符号化された X.509 証明書ファイルに含まれるすべての認証局証明書をインポートします。
たとえば、ca.pem に含まれるすべての認証局証明書をインポートするには、次のように入力します。
$ pkgadm addcert -k ~/mykeystore -ty ca.pem |
出力は次のような内容です。
Trusting certificate <VeriSign Class 1 CA Individual \ Subscriber-Persona Not Validated> Trusting certificate </C=US/O=VeriSign, Inc./OU=Class 1 Public \ Primary Certification Authority Type a Keystore protection Password. Press ENTER for no protection password (not recommended): For Verification: Type a Keystore protection Password. Press ENTER for no protection password (not recommended): Certificate(s) from <ca.pem> are now trusted |
署名に使用する鍵をパッケージキーストアにインポートするには、あとでパッケージに署名するときに使用する別名を指定する必要があります。この別名は、パッケージキーストアから鍵を削除する場合にも使用できます。
たとえば、署名鍵を sign.pem ファイルからインポートするには、次のように入力します。
$ pkgadm addcert -k ~/mykeystore -n mycert sign.pem |
出力は次のような内容です。
Enter PEM passphrase: Enter Keystore Password: Successfully added Certificate <sign.pem> with alias <mycert> |
パッケージキーストアに証明書があることを確認します。
たとえば、前の手順で作成したキーストア内の証明書を表示するには、次のように入力します。
$ pkgadm listcert -k ~/mykeystore |
証明書をパッケージキーストアにインポートしたら、パッケージに署名できます。パッケージに実際に署名するには、pkgtrans コマンドを使用します。
pkgtrans コマンドを使用してパッケージに署名します。署名なしパッケージの場所と、パッケージに署名するための鍵の別名を指定します。
たとえば、前の手順の例を使用すると、SUNWfoo.signed という名前の署名付きパッケージを作成するには、次のように入力します。
$ pkgtrans -g -k ~/mykeystore -n mycert . ./SUNWfoo.signed SUNWfoo |
このコマンドの出力は、次のような内容です。
Retrieving signing certificates from keystore </home/user/mykeystore> Enter keystore password: Generating digital signature for signer <Test User> Transferring <SUNWfoot> package instance |
署名付きパッケージは、SUNWfoo.signed ファイルにパッケージストリーム形式で作成されます。この署名付きパッケージは、Web サイトにコピーし、pkgadd コマンドと URL を使用してインストールするのに適しています。