Sun N1 Service Provisioning System ユーザーズガイド (OS Provisioning Plug-In 3.0)

付録 F 追加 JET モジュールの作成

範囲

このモジュールは、JET フレームワークと、製品ソフトウェアの実際のインストールを実行するために提供される機能との間の接着剤の働きをします。このモジュールは、テンプレート内の一連の構成オプションで、ターゲット単位でのサーバーオプションを設定できるようにします。サーバーオプションはパラメータに従った製品インストールの実行に使用されます。

テンプレート内にどのオプションが出現するか、またどのように製品インストールを実行するかの範囲に関しては、特別な要件や制限は存在しません。ただし、可能な限りモジュールが互いに共存するようにしたり、不自然な依存関係をなくすようにすべきであるという一定のガイドラインは存在します。

モジュール設計のガイドライン

ツールキットそれ自体がある基本的な原理に基づいて設計されています。そのツールキットとともに当初作成されたモジュールもこのスタイルに従っていました。すべてのモジュール開発者は独自の手法を使用できますが、少なくとも次の事項を考慮し、可能であれば従う必要があります。

モジュールの対応範囲

各モジュールは、なるべく別のモジュールで使用可能な機能を複製することなく、アプリケーションの特定の範囲に対応する必要があります。また、モジュールのサイズを適切にする必要があります。モジュールを適切にサブコンポーネントに分割できる場合、1 つの巨大なモジュールの代わりに、より小さなモジュールを作成する必要があります。

次に例を示します。設計者が、ターゲットサーバーインストールにセキュリティーサービスを提供するモジュールを書くことを決定する場合を考えます。このモジュールの一部として、設計者はファイアウォールと、一連の強化スクリプトをインストールすることを決定します。

この場合、設計者は別のモジュールがこれら 2 つの領域のいずれかにすでに対応しており、そのモジュールを活用できるかどうかを調べる必要があります。また、ファイアウォールと強化スクリプトのいずれかがお互いに分離して別の場所で使用できる場合、それらをまとめるのではなく、2 つのモジュールとして作成する方がより柔軟性が高い場合があります。

モジュールの依存関係

各モジュールはそれ自身で完結している必要があり、別のモジュールに依存したり、別のモジュールの存在を想定したりするべきではありません。そのような相互作用が必要である場合 (場合によっては実際に意味をなす)、そのモジュールはもう一方のモジュールに依存していると明確に指定する必要があります。このような状況が生じた場合、独立したモジュールに機能が最もよく実現されているかどうか、またはお互いに依存する 2 つのモジュールが 1 つの包括的なモジュールでよりよく実現されているかどうかを判断する必要があります。基本的な前提は、意味のある場合は項目をまとめ、多数のより小さなモジュールを、それ自体を目的として作成しないことです。

モジュールの相互作用

状況がモジュールの分離に有利であり、モジュールが (少なくとも一方向で) 依存している場合、モジュールは正しい (望ましい) 結果が得られるように相互作用を行うようにする必要があります。ツールキットには、モジュールごとにヒントを設定および取得するための非常に単純なメカニズムがあります。モジュールがヒントを取得するかどうかは、モジュールの設計者にかかっていますが、モジュール開発者の間の連携により、モジュールは孤立した状態で正しく動作し、統合した場合により強力なソリューションを提供するようにモジュールを書くことも可能です。

次に例を示します。実際の例では、Sun Cluster 3 製品は Solstice DiskSuite がどのように構成されているかに依存しますが、必ずしも DiskSuite がインストールされている必要はなく、また DiskSuite もクラスタソフトウェアがインストールされている必要はありません。実際、DiskSuite がクラスタマシン以外のマシン上にインストールされていることが非常に重要です。

この場合、DiskSuite に対応するモジュールと、Sun Cluster 製品に対応するモジュールの 2 つの別々のモジュールを用意します。それぞれのモジュールは独立して正しく動作しますが、同じターゲットサーバー構成内で結びつけられた場合、Sun Cluster モジュールは DiskSuite モジュールに影響し、 Sun Cluster 3.0 により DiskSuite に課せられた制限に適合します。

この相互作用はモジュールヒントを使用することにより行われ、スタンドアロンシナリオでのそれらの動作は次のように要約できます。

Sun Cluster モジュールのみがアクティブである場合、Sun Cluster はヒントを設定しますが、DiskSuite は存在せず、ヒントを取得しません。
DiskSuite のみがアクティブである場合、ヒントを探しますが、ヒントはほかのモジュールにより設定されていないため、通常のデフォルト動作を使用します。

ヒントが実際に何を表現するかは、完全にモジュール開発者にかかっています。モジュール開発者間の緊密な連携により、ヒントを最も効率的に使用できるようになります。可能であれば、そのほかのモジュール開発者が追加インタフェースを活用できるように、モジュールのリリースノート内にヒントを文書化する必要があります。

モジュールのコーディング

モジュール開発者は、JumpStart インストール時に使用可能な標準スクリプト言語を選択する必要があります。たとえば、ターゲットサーバーが使用する NFS ブートイメージにシェルが含まれないため、「バッシュ」が使用できない場合があります。

この問題はすべてのバージョンの Solaris で存在することが認識されているため、可能であれば Bourne Shell を使用する必要があります。最後の手段としてのみ、コンパイル済み言語を検討してください。

モジュールのディレクトリ

各モジュールには、メインツールキットフレームワークがインストールされた場所からの Products サブディレクトリに位置する、独自のディレクトリ構造があります。ディレクトリの名前は、特定のモジュールを参照するためにツールキットにより使用される名前です。

たとえば、モジュール sds (Solstice DiskSuite) は .../Products/sds/ に存在し、このモジュールのみがそのディレクトリ内に存在するものとその使用法を制御します。次に、注意するべき例外を示します。

ツールキットへのモジュールの登録には追加の相互作用は必要ありません。ディレクトリが存在すれば十分です。Products ディレクトリ内にメインツールキットインストールポイントの外部にあるそのほかの位置へのシンボリックリンクを作成することはお勧めできません。アクセス機能を提供するそのほかの手段が講じられない限り、インストール時にターゲットサーバーはそのようなディレクトリにアクセスできない場合があります。

モジュール構成 (`module.conf` ファイル)

各モジュールはある程度までユーザーにより構成可能なようになっています。これは必須要件ではありませんが、通常は実装されていることが想定されています。

ツールキットは、ユーザーへのモジュール構成の提供に関して非常に単純な見方をしています。ツールキット make_template コマンドを使用してテンプレートを作成する場合、1 つのフラットファイルが作成されます。このファイルは、コア base_config 構成ファイルと、各選択モジュールからの構成ファイルを連結します。モジュールそれ自体のあとで、.conf 接尾辞を使用した名前が付けられた構成ファイルを提供することにより、ツールキット make_template コマンドは残りの作業を行います。

構成ファイルは単純な Bourne Shell スクリプトです。構成ファイルは、ユーザーに対する変数の形式で、構成可能なオプションを表す必要があります。モジュールの変数名前空間を保存し、あるモジュールが別のモジュールを破壊するのを防ぐため、各変数にはモジュール名とアンダースコアの接頭辞をつける必要があります。

たとえば、モジュール sds は、ユーザーに対して、インストールするソフトウェアのバージョンを選択するオプションを表します。構成ファイルの対応する部分は次のようになります。

############
#
# Which version of the product is to be installed 
# 
sds_product_version="4.2.1"

この例では、デフォルト値 4.2.1 がすでに構成ファイルに生成されています。これが、モジュールが記述された時点での製品の最も新しいバージョンであったためです。

モジュールのインタフェース

ツールキットは、ターゲットサーバーと JumpStart サーバーの両方において、JumpStart プロセスのライフサイクル中にモジュール内で特定のインタフェースを呼び出します。各インタフェースは、環境変数を通じて供給されるターゲットサーバーのコンテキストを持つ、実行可能なシェルスクリプト (または最悪の場合バイナリ) であると想定されています。

copy_media インタフェース

呼び出される場所

JumpStart サーバー

引数

<patches|packages> version srcdir destdir arch

必須/オプション

必須

copy_media スクリプトが呼び出されるのは、ユーザーが copy_product_media または copy_product_patches スクリプトを呼び出してこのモジュールのメディアを管理する場合です。このスクリプトはアプリケーションが配信される形式を理解し、渡されたソースメディアの位置から、サーバー上の適切なメディア位置に対して、コピーを実行する必要があります。この機能を使用することで、メインツールキットを各メディアタイプに対して更新する必要なく、通常とは異なる形式のメディア (tar.gz、zip、bz2 など) を処理できるようになります。また、モジュール開発者が既知の状態でサーバーにメディアを配置できるようにもなります。たとえば、ディレクトリツリー全体、または Solaris パッケージのまとまりのみを参照可能にする必要が製品で生じる場合があります。

make_template インタフェース

呼び出される場所: JumpStart サーバー
引数: なし
必須/オプション: オプション

管理者がサーバービルドの新しい定義を作成する場合、管理者は /opt/SUNWjet/bin に用意されている最上位レベルコマンド make_template を実行します。この最上位レベル make_template スクリプトは基本ターゲットサーバー構成情報を設定し、存在する場合は各モジュール固有の make_template スクリプトを呼び出します。モジュール固有の make_template スクリプトは、テンプレート上で追加作業を実行できます。たとえば、ユーザーが編集するクライアントごとのデフォルトの生成などです。

make_client インタフェース

呼び出される場所: JumpStart サーバー
引数: なし
必須/オプション: オプション

管理者がインストール用にターゲットサーバーを設定する場合、ツールキットの bin ディレクトリに付属する最上位レベルコマンド make_client を実行します。この最上位レベル make_client スクリプトは基本ターゲットサーバー構成情報を設定し、存在する場合は各モジュール固有の make_client スクリプトを呼び出します。モジュール固有の make_client スクリプトはターゲットサーバー固有の /opt/SUNWjet/Clients ディレクトリで追加作業を実行でき、またモジュールヒントを構成したり、それに応じてターゲットサーバープロファイル sysidcfg やそのほかのファイルを変更できます。

begin インタフェース

呼び出される場所: ターゲットサーバー
引数: なし
必須/オプション: オプション

JumpStart プロセスの「begin」段階で、ツールキットはモジュールが begin という名前のスクリプトを持っているかどうかを確認し、それが存在する場合は、そのスクリプトが実行されます。テンプレートのモジュール構成セクションで設定されたすべての変数は、スクリプトがアクセスする環境に存在します。

install インタフェース

呼び出される場所: ターゲットサーバー
引数: なし
必須/オプション: 必須

install スクリプトは、モジュールの中心的な存在です。このスクリプトは Solaris のメインのインストールが完了したあとに、「finish」スクリプト段階でターゲットサーバー上に呼び出されます。その目的は、特定のアプリケーションのインストールまたは構成を調べることです。

スクリプトそれ自体は、新しくインストールされたターゲットサーバーの最初の再起動の前に呼び出されます。この時点で、ルートディレクトリ (/) は実際には JumpStart サーバーからマウントされた NFS ファイルシステムです。実際のディスクベースのルートディレクトリは、環境変数 $ROOTDIR (従来は /a に設定されている) の使用を通じて位置が特定されます。

ルートが $ROOTDIR に位置している場合にアプリケーションをインストールできなければ、install スクリプトは、ツールキットにより提供されるインストール後機能を使用して、最初の再起動後のそれ以降のインストールをスケジュールする必要があります。最初の再起動後、ターゲットサーバーは実際にそれ自身のディスクからブートし、ルートは実際に「/」になります。

install スクリプトは、ユーザーが提供する構成を取得し、実際のアプリケーションのインストールおよび構成を適切に実行する役割があります。これをどのように実現するかはモジュール開発者の工夫にかかっていますが、パッケージやパッチのインストール、ファイルコピー、メッセージ報告など共通のタスクを支援する数多くのユーティリティー機能がメインツールキットから使用できます。

モジュール install スクリプトが呼び出される前に、テンプレートで定義され、元来は module.conf ファイルから生成されたモジュール構成が、シェル環境に読み込まれます。install スクリプトは引数を使用して呼び出されることは想定していませんが、代わりに現在の環境からその構成を取得する必要があります。このテクニックにより、各モジュールインストールスクリプトが異なる数の引数を要求するといった問題を回避できます。

check_client インタフェース

呼び出される場所: ターゲットサーバー
引数: なし
必須/オプション: オプション

モジュール開発者が check_client スクリプトを用いると、テンプレートで指定されている構成オプションに関する基本的なチェックを実行できます。このスクリプトを呼び出すと、テンプレートで設定されている変数を使用して環境が構成され、またスクリプトはインストールエラーを減らすための基本的なチェックを実行できます。

モジュールは、有効なオプションのチェックや、選択したバージョン用のメディアが存在することのチェックを決定できます。提供される機能のレベルは、実装者によって決まります。

ツールキットのサポート関数

メインツールキットには、モジュールにより活用可能な多くの共通関数が用意されています。これにより、コードの再利用が改善され、モジュールがよりシンプルになります。どのような関数が使用できるかを調べる最善の方法は、関数が存在するディレクトリ /opt/SUNWjet/Utils/lib を調べる方法です。

JET モジュールの追加

この節では、追加の JET モジュールを Solaris ブートおよびインストール (JET) サーバーに追加する方法について説明します。プロセスは Flash モジュールのコンテキストで説明されていますが、その論理はほかの JET モジュールにも拡張されます。

Flash モジュールを追加する

JetFLASH.pkg を Solaris ブートおよびインストールサーバーにダウンロードします。

JetFLASH パッケージをインストールします。

次の例のようなコマンドを使用します。

# cat >/tmp/admin-file <<- _EOF
mail=\n
instance=unique
partial=quit
runlevel=ask
idepend=quit
rdepend=nocheck
space=quit
setuid=nocheck
conflict=nocheck
action=nocheck
basedir=/opt/SUNWjet/Products
_EOF
  pkgadd -a /tmp/admin-file -d JetFLASH.pkg

Flash イメージを Solaris ブートおよびインストールサーバーにコピーします。

次の例のようなコマンドを使用します。
# telnet solaris-bis-ip-address # cp flash-archive /export/install/flash/sol10_xall_sparc.flar

この Flash イメージの Solaris Profile を作成します。

Solaris 10 Flash イメージの変数セットを作成するには、次の例のようなコマンドを入力します。

# cr_cli -cmd cdb.vs.add -comp NM:/com/sun/n1osp/untyped/SolarisImage \
-name "solaris10sparc" -u admin -p admin -vars "version=10;release=ga;architecture=sparc; \
image_path=/export/install/s10ga-sparc;image_subnet_addr=10.42.42.2; \
image_subnet_mask=255.255.255.0;media_src="

Flash 情報を指定するには、次のエントリが含まれるファイル /tmp/flash-profile を作成します。
```
flash-with-ra
Solaris10 Flash Archive With SPS RA
base_config flash spsra
```
各行の意味は次のとおりです。
- ファイルの最初の行は、ブラウザインタフェースのプラン変数セクションの「Profile Name」フィールドに対応します。
- ファイルの 2 番目の行は、ブラウザインタフェースのプラン変数セクションの「Profile Description」フィールドに対応します。
- ファイルの 3 番目の行は、ブラウザインタフェースのプラン変数セクションの「JET Module Name(s)」フィールドに対応します。

コンポーネントを作成するには、次の例のようなコマンドを入力します。
# cr_cli -cmd pe.p.run -u admin -p admin \ -PID NM:/com/sun/n1osp/untyped/SolarisImage-create-profile -tar H:NM:biss1-jet \ -comp - -vs solaris10sparc -pto 30 -nto 10 -f /tmp/flash-profile
ヒント –
また、N1 SPS ブラウザインタフェースを介して Profile コンポーネントを作成することもできます。「Solaris Image: create profile」オプションを使用します。

前の手順で作成した Profile コンポーネントを編集します。

プロファイルの位置は、/com/sun/n1osp/autogen-masterserver-jet/provision/ です。この作業例では、Profile コンポーネントは /com/sun/n1osp/autogen-masterserver-jet/provision/Solaris_10.flash です。

Profile コンポーネントで、archive_locations_flash 変数の値を Flash アーカイブを指すよう変更します。

次に例を示します。
```
archive_locations_flash nfs://10.216.0.55/export/install/flash/sol10_xall_sparc.flar
```

コンポーネントをチェックインします。

これで上記の Solaris Profile を使用して目的のターゲットホスト上で配備を行う準備ができました。