前のトピック: Linux distro のインストール次のトピック: vme: イベント ジェネレータ


共通の Linux コンポーネント

このセクションには、以下のトピックが含まれています。

アプライアンス カスタマイズ動作

vme: イベント ジェネレータ

アプライアンス カスタマイズ動作

スタートアップ スクリプトの自動動作をカスタマイズして、カスタム機能を持ったアプライアンスを提供できます。

以下のいずれかのファイルで以下のパラメータを定義します。

/etc/sysconfig/applogic_init

アプライアンス Init 設定

ファイル /etc/sysconfig/applogic_init が存在する場合、APK init スクリプトはシェル インクルード スクリプトと解釈します(「.」コマンド)。

重要: /etc/sysconfig/applogic_init ファイルは設定データが取得または適用される前に実行されます。 したがって、スクリプトはアプライアンスのいずれの設定ファイルの存在にも依存できません。 このファイルは、上記に定義した設定変数にのみ使用し、初期化コードを実行するためには使用しないでください。

/etc/sysconfig/applogic_init の例:

APK_CONFIG_FILES=/etc/httpd/conf.d/myconfig.conf
APK_AUTH_KEY_PATH=/root/.ssh/alternate_keys 

いずれかのスクリプトで以下のパラメータを定義できます。

APK_AUTH_KEY_PATH

アプライアンスの SSH のアクセス公開キーを格納する場所。 3t comp ssh コマンドは、対応する秘密キーを使用して、アプライアンスに接続します。

デフォルトは /root/.ssh です。

空の文字列に設定された場合、キーはどこにも格納されません。
指定された場所が既存のファイルの場合、その所有者と権限が保持されます。 そうでない場合は、ファイルは所有者のルートに作成されます。

APK_CONFIG_FILES

アプライアンスのプロパティを適用するファイルのスペース区切りリスト。

APK を使用したアプライアンスは、GUI で指定されたリストではなく、アプライアンス自体に置かれている APK_CONFIG_FILES リストを使用します。

アプライアンスが APK を使用していない場合、これは GUI の Infrastructure Editor の[境界の変更]ダイアログ ボックスで指定されている設定ファイル リストを置換します。

重要: APK を既存のアプライアンスにインストールする場合は、クラス記述子内の設定ファイルを確認します。 クラス記述子は、Infrastructure Editor 内の[境界の変更]ダイアログ ボックスの[環境設定ファイル]タブにあります。 ファイルのリストをアプライアンスの APK_CONFIG_FILES 設定に転送します。

APK_CONFIG_DNS

このパラメータは、システム名リゾルバ設定の更新を制御します。

値:

  • yes - APK は AppLogic グリッドで設定されている値で、システム リゾルバ設定(Linux では /etc/resolv.conf ファイル、Windows では netsh コマンドを使用する DNS 設定)を更新します。
  • no - APK は更新を実行しません。
  • auto - システム リゾルバの更新は、/etc/resolv.conf ファイルの「---APK_UNMODIFIED---」タグによって制御されます。 /etc/resolv.conf にタグがある場合、APK は名前リゾルバの設定を更新し、変更を上書きします。

APK_HOSTNAME_UPDATE

このパラメータを No に設定すると、ホスト名またはコンピュータ名をアプライアンスのインスタンス名から派生した文字列に変更するデフォルト動作が無効になります。

アプライアンス所有者がホスト名などその設定のすべての側面をメンテナンスする仮想プライベートまたは専用サーバ アプライアンスでは、自動的なホスト名変更を無効にすることが望ましい場合があります。

重要: APK_HOSTNAME_UPDATE が Yes に設定されている、またはまったく設定されていない場合、ホスト名の変更は OS の再起動のトリガになります。 この状況は、初回起動時、またはアプライアンスのインスタンス名が変更されて再起動されるたびに発生します。

この再起動は APK が開始の成功をレポートする前に行われるため、アプライアンスの開始に 2 倍の時間がかかるように見えます。

再起動が APK によってトリガされた場合、スタートアップ進捗状況詳細でのメンテナンス モード入力に関するメッセージが表示されます。

APK_AUTOMOUNT

アプライアンス クラスで指定されるように、このパラメータを No に設定すると、ドライブ文字またはマウント ポイントの自動割り当てが無効になります。 これにより、APK 内のボリューム状態確認もすべて無効になります。

重要: このオプションは、ISO 形式のイメージをその仮想ディスクの 1 つとして割り当てることによってアプライアンスに CD-ROM デバイスが設定されている場合に使用する必要があります。 APK 自動マウントは、この組み合わせでは動作せず、アプライアンスの開始が失敗する原因になります。


アプライアンスの開始後チェック

ファイル /etc/sysconfig/applogic_appliance または ¥aookiguc¥config¥applogic_appliance が存在する場合、APK late init スクリプトはアプライアンス上の他のすべてのサービスが開始した後、「.」コマンドでシェルのインクルード スクリプトとしてそのファイルを読み取ります。 スクリプトからのリターン ステータスは、アプライアンスが正常に開始されたか失敗したかを示します。

スクリプトによってメッセージが stderr に出力され、エラーが返される場合は、このメッセージの最後の行が、コントローラに送信されるエラー メッセージとして使用されます。

Web サーバ アプライアンス用の起動後チェック ファイルの例。 これは、サーバが起動し、ホーム ページへの HTTP GET に応答することを確認します。

if ! wget -q -O /dev/null http://localhost/ ; then
echo "start failed - web server is not responding" >&2
return 1
fi
return 0 

アプライアンス サービスを起動する起動スクリプトとして /etc/sysconfig/applogic_appliance を使用することは避けてください。 これにより、APK がインストールされているアプライアンスの外部でセットアップ フォームを使用またはテストできません。

重要: Windows では、Windows SCM (サービス コントロール マネージャ)がサービスをすべてロードした後、applogic_appliance の開始後チェックが始まります。初期化を完了した時点ではありません。 これは APK によってサポートされた他のプラットフォームとは異なります。

Windows で、いくつかのサービスは明示的な依存性としてではなく、API コールを使用して、他のサービスによって開始されます。 これらは単に自動的なサービス ロード完了イベントを待機するだけでは把握できません。 そのため、/etc/sysconfig/applogic_appliance ファイルに追加された「スタートアップ確認」コードでこれを把握し、まだ初期化されていない場合には監視する必要のあるサービスを待機する必要があります。