test

アプリケーションパッケージ開発者ガイド

異機種システム混在環境での再配置のサポート

System V のパッケージ化の背後にあるもともとの概念では、システムごとに 1 つのアーキテクチャーを想定していました。サーバーの概念は設計に関与しませんでした。今では当然、単一のサーバーが複数のアーキテクチャーをサポートしています。つまり、1 つのサーバー上に同じソフトウェアが異なるアーキテクチャーごとに複数存在する場合があります。Solaris パッケージは推奨されるファイルシステムの境界内 (例: / および /usr) に隔離されていますが、サーバーおよび各クライアントの製品データベースでは、必ずしもすべてのインストールでこの分割がサポートされているわけではありません。特定の実装では、まったく異なる構造をサポートして、共通製品データベースを含んでいます。クライアントを異なるバージョンに向けることは簡単ですが、実際に System V のパッケージを異なるベースディレクトリにインストールした場合、管理者にとって複雑な状況をもたらす可能性があります。

パッケージを設計する場合、管理者が新しいバージョンのソフトウェアのインストールに使用する一般的な方法についても検討するようにしてください。管理者は、しばしば現在インストールされているバージョンと共存させて最新バージョンをインストールし、テストしようとします。その手順として、現在のバージョンとは異なるベースディレクトリに新しいバージョンをインストールして、少数の重要ではないクライアントをテストとして新しいバージョンにします。確信が得られたら、管理者はより多くのクライアントを新しいバージョンにします。最終的に、管理者は非常時用にのみ旧バージョンを保持して、最後には削除します。

つまり、現代の異機種システムで使用するパッケージは、管理者がファイルシステム上の任意の適切な場所に配置でき、正常に動作するという意味で本当の再配置をサポートする必要があります。Solaris 2.5 および互換リリースでは、多数の有用なツールが提供され、同じシステムに複数のアーキテクチャーおよびバージョンをクリーンにインストールできます。Solaris 2.4 および互換バージョンでも本当の再配置をサポートしていますが、そのための手順は明白ではありません。

従来のアプローチ

再配置可能パッケージ

System V ABI は、再配置可能パッケージの背後にある当初の目的は、パッケージのインストールを管理者にとってより便利にすることだったということを含意しています。今では、再配置可能パッケージの必要性はそれ以上のものになっています。利便性だけの問題ではなく、インストール時にアクティブなソフトウェア製品がすでにデフォルトディレクトリにインストールされている可能性が非常に高くなっています。この状況に対応できないパッケージは、既存の製品を上書きするか、インストールに失敗します。しかし、複数のアーキテクチャーおよび複数のバージョンに対応したパッケージは、スムーズにインストールでき、従来の管理方法と十分に互換性がある幅広いオプションを管理者に提供します。

ある意味で、複数のアーキテクチャーの問題と複数のバージョンの問題は同じです。既存のパッケージのバリアントは、ほかのバリアントと共存させてインストールできる必要があります。また、エクスポートされたファイルシステムのクライアントまたはスタンドアロンのコンシューマは、機能を低下させることなく、いずれかのバリアントに変更できる必要もあります。Sun はサーバー上で複数のアーキテクチャーに対応する方法を確立していますが、管理者はこれらの提案に従わない場合もあります。すべてのパッケージは、管理者のインストールに関する合理的な要望に応じることができるようにする必要があります。

例 - 従来の再配置可能パッケージ

この例では、従来の再配置可能パッケージを示します。パッケージは /opt/SUNWstuf に配置され、pkginfo ファイルおよび pkgmap ファイルは次のようになります。

pkginfo ファイル

# pkginfo file
PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/opt
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none
PSTAMP=hubert990707141632

pkgmap ファイル

: 1 1758
1 d none SUNWstuf 0775 root bin
1 d none SUNWstuf/EZstuf 0775 root bin
1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none SUNWstuf/HRDstuf 0775 root bin
1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865

これが従来の方法と呼ばれる理由は、すべてのパッケージオブジェクトが pkginfo ファイルの BASEDIR パラメータで定義されるベースディレクトリにインストールされるためです。たとえば、pkgmap ファイルの最初のオブジェクトは /opt/SUNWstuf ディレクトリにインストールされます。

絶対パッケージ

絶対パッケージは、ファイルシステムの特定のルート (/) にインストールされるパッケージです。絶対パッケージは、複数のバージョンおよびアーキテクチャーの立場から対処することが困難です。原則的に、すべてのパッケージを再配置可能にしてください。ただし、再配置可能パッケージに絶対的な要素を含める合理的な理由もあります。

例 - 従来の絶対パッケージ

SUNWstuf パッケージが絶対パッケージの場合、BASEDIR パラメータは pkginfo ファイルでは定義されず、pkgmap ファイルは次のようになります。

pkgmap ファイル

: 1 1758
1 d none /opt ? ? ?
1 d none /opt/SUNWstuf 0775 root bin
1 d none /opt/SUNWstuf/EZstuf 0775 root bin
1 f none /opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none /opt/SUNWstuf/HRDstuf 0775 root bin
1 f none /opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865

この例では、管理者がインストール時に代替ベースディレクトリを指定した場合、pkgadd コマンドでは無視されます。このパッケージは、常にターゲットシステムの /opt/SUNWstuf にインストールされます。

pkgadd コマンドの -R 引数は予期されるとおりに機能します。たとえば、次のように指定します。


pkgadd -d . -R /export/opt/client3 SUNWstuf

オブジェクトは /export/opt/client3/opt/SUNWstuf にインストールされますが、これはこのパッケージが再配置可能になることとほぼ同じです。

pkgmap ファイルの /opt ディレクトリに疑問符 (?) を使用しています。これは、既存の属性を変更できないことを示します。これは「デフォルト属性でディレクトリを作成する」ということではありませんが、特定の状況ではそうなる場合もあります。新しいパッケージに固有のディレクトリは、すべての属性を明示的に指定する必要があります。

複合パッケージ

再配置可能オブジェクトを含むパッケージは、再配置可能パッケージと呼ばれます。再配置可能パッケージは pkgmap ファイルに絶対パスが含まれる場合があるため、これは誤解を招く可能性があります。pkgmap ファイルでルート (/) エントリを使用することで、パッケージの再配置可能な側面を強化できます。再配置可能なエントリとルートエントリの両方が含まれるパッケージは、複合パッケージと呼ばれます。

例 - 従来の解決方法

SUNWstuf パッケージのオブジェクトの 1 つが、実行レベル 2 で実行される起動スクリプトだと仮定します。/etc/rc2.d/S70dostuf ファイルはパッケージの一部としてインストールする必要がありますが、ベースディレクトリに配置することはできません。再配置可能パッケージが唯一の解決方法だとすると、pkginfo および pkgmap は次のようになります。

pkginfo ファイル

# pkginfo file
PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none
PSTAMP=hubert990707141632

pkgmap ファイル

: 1 1758
1 d none opt/SUNWstuf/EZstuf 0775 root bin
1 f none opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none opt/SUNWstuf/HRDstuf 0775 root bin
1 f none opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 d none etc	? ? ?
1 d none etc/rc2.d ? ? ?
1 f none etc/rc2.d/S70dostuf 0744 root sys 450 223443
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865

このアプローチと絶対パッケージのアプローチには大きな違いはありません。実際、これは絶対パッケージよりも良い状態です。管理者がこのパッケージの代替ベースディレクトリを指定した場合、このパッケージは機能しません。

このパッケージのファイルは 1 つだけルートと相対的にする必要がありますが、残りは任意の場所に移動できます。複合パッケージを使用してこの問題を解決する方法は、この節の後半で説明します。

従来の方法を超えて

この節で説明するアプローチはすべてのパッケージには適用されませんが、異機種システム混在環境にインストールする場合にパフォーマンスを向上できます。このアプローチは、Solaris OS の一部として提供されるパッケージ (バンドル版のパッケージ) にはほとんど適用されませんが、アンバンドルのパッケージでは従来とは異なるパッケージ化を実行できます。

再配置可能パッケージを奨励する理由は、次の要件をサポートするためです。

パッケージを追加または削除しても、インストールされたソフトウェア製品の既存の動作は変わりません。

アンバンドルのパッケージは、新しいパッケージが既存の製品と干渉しないことを保証できるように、/opt の下に配置するようにしてください。

複合パッケージの別の側面

有効な複合パッケージを構築する場合、次の 2 つの規則に従います。

つまり、「再配置可能」とはオブジェクトを任意の場所にインストールして実行できることを意味するため、ブート時に init で実行される起動スクリプトは再配置可能と見なすことができません。提供されるパッケージで相対パスとして /etc/passwd を指定することに問題はありませんが、配置できる場所は 1 つしかありません。

再配置可能に見える絶対パス名の作成

複合パッケージを構築する場合、インストールされた既存のソフトウェアに干渉しないように絶対パスを処理する必要があります。すべて /opt に含まれるパッケージでは、既存のファイルが存在しないためこの問題を回避できます。/etc のファイルがパッケージに含まれる場合、絶対パス名が相対パス名から予測されるのと同様に機能することを保証する必要があります。次の 2 つの例を考えてみましょう。

例 — ファイルの変更

説明

エントリがテーブルに追加されるか、オブジェクトがほかのプログラムまたはパッケージによって変更される可能性が高い新しいテーブルです。

実装

オブジェクトを、build、awk、または sed クラスに属するファイルタイプ e として定義します。この作業を実行するスクリプトは、自身を追加するのと同程度効率的に自身を削除する必要があります。

例

新しいソリッドステートのハードディスクをサポートするには、エントリを /etc/vfstab に追加する必要があります。

pkgmap ファイルのエントリは次のようになります。 


1 e sed /etc/vfstab ? ? ?

request スクリプトは、パッケージで /etc/vfstab を変更するかどうかをオペレータに確認します。オペレータが "no" と答えると、このジョブを手動で実行する方法が表示され、次の処理が実行されます。 


echo "CLASSES=none" >> $1

オペレータが "yes" と答えると、次の処理が実行されます。 


echo "CLASSES=none sed" >> $1

これによって、必要な変更を行うクラスアクションスクリプトが起動されます。sed クラスは、パッケージファイル /etc/vfstab が、ターゲットシステム上の同じ名前のファイルに対するインストールおよび削除の両方の処理を含む sed プログラムであることを意味します。

例 — 新しいファイルの作成

説明

オブジェクトはまったく新しいファイルで、後から編集される可能性は高くありません。または、別のパッケージが所有するファイルを置き換えます。

実装

パッケージオブジェクトをファイルタイプ f として定義して、変更を取り消すことができるクラスアクションスクリプトを使用してインストールします。

例

ソリッドステートのハードディスクをサポートするために必要な情報を提供するには、/etc に /etc/shdisk.conf という名前の新しいファイルが必要です。pkgmap ファイルのエントリは、次のようになります。 


 
.
.
.
1 f newetc /etc/shdisk.conf
.
.
.

クラスアクションスクリプト i.newetc は、/etc に配置する必要があるファイルのインストールに使用されます。このスクリプトは、所定の場所に別のファイルが存在するかどうかを確認します。存在しない場合は新しいファイルをコピーするだけです。所定の場所にファイルが存在する場合、そのファイルをバックアップしてから新しいファイルをインストールします。スクリプト r.newetc は、必要に応じてこれらのファイルを削除して、元のファイルを復元します。インストールスクリプトの重要な部分を次に示します。

# i.newetc
while read src dst; do
	  if [ -f $dst ]; then
	    dstfile=`basename $dst`
	    cp $dst $PKGSAV/$dstfile
	  fi
	  cp $src $dst
done
 
if [ "${1}" = "ENDOFCLASS" ]; then
	  cd $PKGSAV
	  tar cf SAVE.newetc .
	  $INST_DATADIR/$PKG/install/squish SAVE.newetc
fi

このスクリプトでは、PKGSAV 環境変数を使用して置き換えるファイルのバックアップを格納しています。引数 ENDOFCLASS がスクリプトに渡された場合、これらがこのクラスの最後のエントリであることをスクリプトに通知するのは pkgadd コマンドです。この時点で、パッケージのインストールディレクトリに格納された非公開の圧縮プログラムを使用して、保存されたファイルがアーカイブおよび圧縮されます。

パッケージの更新時には PKGSAV 環境変数の使用は信頼性がありませんが、(たとえばパッチによって) パッケージが更新されない場合、バックアップファイルはセキュリティー保護されています。次の削除スクリプトには、旧バージョンの pkgrm コマンドがスクリプトに PKGSAV 環境変数への正しいパスを渡さないという別の問題に対応するコードが含まれています。

削除スクリプトは次のようになります。

# r.newetc
 
# make sure we have the correct PKGSAV
if [ -d $PKG_INSTALL_ROOT$PKGSAV ]; then
	  PKGSAV="$PKG_INSTALL_ROOT$PKGSAV"
fi
 
# find the unsquish program
UNSQUISH_CMD=`dirname $0`/unsquish
 
while read file; do
	  rm $file
done
 
if [ "${1}" = ENDOFCLASS ]; then
	  if [ -f $PKGSAV/SAVE.newetc.sq ]; then
	     $UNSQUISH_CMD $PKGSAV/SAVE.newetc
	  fi
 
	  if [ -f $PKGSAV/SAVE.newetc ]; then
	     targetdir=dirname $file	# get the right directory
	     cd $targetdir
		    tar xf $PKGSAV/SAVE.newetc
		    rm $PKGSAV/SAVE.newetc
	  fi
fi

このスクリプトでは、パッケージデータベースのインストールディレクトリの非公開アンインストールアルゴリズム (unsquish) が使用されます。これはインストール時に pkgadd コマンドによって自動的に実行されます。pkgadd コマンドによって明確にインストール専用として認識されないスクリプトはすべて、pkgrm コマンドで使用するためにこのディレクトリに残されます。このディレクトリの場所を知ることはできませんが、このディレクトリが平坦で、パッケージの適切な情報ファイルおよびインストールスクリプトがすべて含まれていることは信頼できます。このスクリプトでは、 unsquish プログラムが含まれるディレクトリからクラスアクションスクリプトが実行されることが保証されていることに基づいてディレクトリを検索します。

また、このスクリプトでは、ターゲットディレクトリが /etc だけであるとは仮定していません。実際には /export/root/client2/etc である場合もあります。正しいディレクトリは、2 通りの方法のいずれかで構成できます。

パッケージ内の絶対オブジェクトごとにこのアプローチを使用することで、現在の望ましい動作が変わらないか、少なくとも回復可能であることを保証できます。

例 — 複合パッケージ

次に示すのは、複合パッケージに対して pkginfo ファイルと pkgmap ファイルを使用する例です。

pkginfo ファイル

PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/opt
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none daemon
PSTAMP=hubert990707141632

pkgmap ファイル

: 1 1758
1 d none SUNWstuf/EZstuf 0775 root bin
1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none SUNWstuf/HRDstuf 0775 root bin
1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 d none /etc	? ? ?
1 d none /etc/rc2.d ? ? ?
1 e daemon /etc/rc2.d/S70dostuf 0744 root sys 450 223443
1 i i.daemon 509 39560 752978103
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865
1 i r.daemon 320 24573 742152591

S70dostuf は daemon クラスに属しますが、これにつながるディレクトリ (インストール時に配置済み) は none クラスに属します。ディレクトリがこのパッケージに固有の場合でも、none クラスのままにしてください。この理由は、最初にディレクトリを作成して、最後に削除する必要がありますが、これは none クラスの場合も常に該当するためです。pkgadd コマンドによってディレクトリが作成されます。このディレクトリは、パッケージからコピーされたり、作成されるクラスアクションスクリプトに渡されたりすることはありません。その代わり、pkgadd コマンドで作成してからインストールクラスアクションスクリプトが呼び出され、削除クラスアクションスクリプトの完了後に、pkgrm コマンドによってディレクトリが削除されます。

つまり、特殊クラスのディレクトリに none クラスのオブジェクトが含まれる場合、pkgrm コマンドでディレクトリを削除しようとすると、ディレクトリが時間内に空にならないので失敗します。none クラスのオブジェクトが特殊クラスのディレクトリに挿入される場合、時間内にオブジェクトを受け入れるディレクトリは存在しません。pkgadd コマンドにより、オブジェクトのインストール時にオンザフライでディレクトリが作成され、最終的に pkgmap 定義を確認した場合にそのディレクトリの属性を同期できない場合があります。

注 –

クラスにディレクトリを割り当てる場合は、常に作成と削除の順序を覚えておいてください。