apk-*-linux-ub バージョンは以下の OS distro と互換性があります。
APK をインストールするには、以下のいずれかが必要です。
APK で提供されるカーネルおよび initrd ファイルを使用する場合、イメージには ext3 ファイル システムが必要です。
Linux バージョンの APK は、VMWare と XEN ハイパーバイザの両方の HVM ブートをサポートします。 CA AppLogic で提供される PVM カーネルはオプションです。
CA AppLogic で提供されるカーネルが APK インストールの実行前にアンパックされた場合、アプライアンスが PVM モードでブートされるとブートするカーネルとして自動的に設定されます。このための新しい boot/grub/menu.lst ファイルが作成されます。 HVM ブートでは、インストールされた OS で提供されるカーネルが使用されます(Red Hat 互換のオペレーティング システム用のデフォルト OS grub 設定ファイルは、boot/grub/grub.conf です)。
CA AppLogic で提供されるカーネルが APK インストールの実行前にアンパックされた場合、ブート カーネルとして boot/grub/menu.lst にセットアップされます。 元の GRUB 設定ファイルは、boot/grub/menu.lst.apkbk にバックアップされます。 アプライアンス作成者は、設定ファイルとして別のファイル名を使用できるように、保存されたバックアップの名前を変更し、GRUB ブートローダを再設定できます。HVM モードのアプライアンス ブート時に選択できるようになります。 PV モードのブートでは、常に boot/grub/menu.lst が使用されます。
CA AppLogic で提供されるカーネルをアンパックせずに APK インストールを実行した場合、GRUB 設定は元のままです。 アプライアンスが HVM モードで実行されること、または OS で提供されるカーネルが XEN PV モードでブートできることが想定されています(多くの新しい OS distro では XEN-PV カーネル ビルドが提供され、デフォルトとしてインストール、設定されます)。
以下の手順は、OS が最初にどのようにインストールされたかに応じて変わります。 これらの手順の一部は(準備されているイメージ上ではなく)誤ってライブ システム上で実行されると有害あるいは破壊的な影響を及ぼす可能性があり、自動スクリプトで実行することは不適切な場合があるため、これらの手順は APK セットアップ スクリプトでは実行されず、管理者の裁量に任されます。 適切でない手順はスキップしてください。
イメージを準備する方法
run tune2fs -j
ext2 (または ext3 以外の任意のファイルシステム)を使用するには、APK と共に提供された initrd ファイルを再構築する必要があります。
/dev/hda1
また、ルート デバイスがラベルまたは UUID によって指定された場合、インストーラは確認の上、警告を出力します。
注: APK の 32 ビット実行可能ファイルではなく、他のファイルを実行する必要がある場合は、ia32-libs meta-package のインストールを考慮してください。 meta-package は、32 ビット ライブラリを含むすべてのパッケージをインストールします。
重要: ネットワーク マネージャをアンインストールするか無効にします。 このプログラムは CA AppLogic ネットワーク設定と干渉します。 例外: グラフィカル ユーザ インターフェースを備えた VPS サーバのセットアップの場合、ネットワーク マネージャのアプレットがマニュアル IP 設定を実行するために使用されます(ただし、CA AppLogic の新しい OS のインストールを起動する前に手動モードでセットアップする必要があります)。
注: クリーンアップ後に、アプライアンス用により小さなブート ボリューム イメージを作成するためにボリュームが縮小される場合がありますが、XEN DomU カーネルおよび APK をインストールするスペースを確保するため、またログ ファイルや一時ファイルなどに使用する空間を確保するために、少なくとも 10 ~ 15 MB の空き容量が残されていることを確認してください。
APK は、Red Hat の「nash」ブートストラップ プログラムで作成された単純な initrd(initial ramdisk)イメージを使用します。 カーネル モジュールはロードされません。唯一の目的は、udev プログラムの ramdisk ベースの /dev/ ディレクトリをセットアップし、入力することです。
Ubuntu ベースの仮想アプライアンスを正常に起動し、アプライアンスの ubuntu スタイルの initrd イメージを作成する必要はありません。 Ubuntu 6/7 initrd イメージは重く、高度な機能が備わっていますが、ほとんどのアプライアンスでは必要ありません。 必要に応じて、Ubuntu 固有の initrd ファイルを作成して使用できます。 /boot/grub/menu.lst ファイルを編集して単に代わりの initrd イメージを指定してください。 将来的に APK を再インストールした場合、この変更は再適用する必要があります。
このインストール手順では、APK インストールが実行中ではない OS イメージに対して実行されることを想定しています。クリーンな OS のインストール、シャットダウン、ブート ディスク イメージの作成を行うことにより、または既存の CA AppLogic アプライアンスを APK の新バージョンでアップグレードすることにより、事前に準備された OS イメージが対象です。
ライブ インストール(実行中の OS )も可能です。CA AppLogic サービス パック 2.4.5 以降で提供されている iso2class ユーティリティと共に使用できます。 ライブ システムにインストールするには、以下の手順に従ってください。ただし、「/」をすべての操作のカレント ディレクトリとして使用します。 XEN 仮想マシン(たとえば、iso2class を使用)で実行すると最もうまくいきます。 APK が CA AppLogic XEN PV カーネルでのみインストールされていると、ブート不可能マシンになります。
オペレーティング システム イメージをファイル システムにマウントします。 すでにイメージをボリュームとして CA AppLogic グリッドにインストールしている場合、vol manage コマンドを使用して、アクセスします。 イメージ自体の /tmp ディレクトリまたはイメージがマウントされているホスト上の一時ディレクトリに APK ファイルをコピーします。 イメージがすでにグリッド上にある場合は、Web インターフェースを使用して、イメージ自体にファイルをコピーします。 グリッド上でこのタスクを実行していない場合、root ユーザが以下の操作を行う必要があります。
APK のインストール方法
cd /mnt/vol tar -zxf tmp/domu-linux-2.6.18.8.i386.tar.gz tar -zxf tmp/apk-2.0.14-ub.tar.gz
セットアップ スクリプトは ./tmp ディレクトリにアンパックされます。
重要: distro アーキテクチャ用の適切な domu-linux アーカイブを使用してください。 32 ビット カーネルのインストールは 64 ビット distro では動作しません。
tmp/apk-install
注: APK で提供された init スクリプトは、/appliance にインストールされたアプライアンス固有のスクリプトをもはやサポートしません。 存在する場合、インストール スクリプトが停止し、ユーザは入力を求められます。 このディレクトリでアプライアンス固有のカスタマイズが行われていない場合は、削除したほうが安全です。 たとえば、コンテンツが LUX のコンテンツと同じか似ている場合などです。 以前はここにインストールされた標準機能は、すべて APK によって提供されるようになりました。 そうでない場合は、[保存]をクリックして /tmp に保存し、インストールを続行します。
セットアップ スクリプトおよび tar ファイルがイメージにコピーされている場合は削除できます。
rm tmp/apk-install = =tmp/domu-linux-*.tar.gz = tmp/apk-*.tar.gz=
vol manage
詳細については、ユーザ ガイドを参照してください。
ファイル /etc/sysconfig/applogic_init が存在する場合、APK init スクリプトはシェル インクルード スクリプトと解釈します(「.」コマンド)。 以下のパラメータは /etc/sysconfig/applogic_init に定義できます。
APK_AUTH_KEY_PATH |
アプライアンスに SSH ログインする公開キーを格納する場所を指定します。 3t comp ssh コマンドは、対応する秘密キーを使用して、アプライアンスに接続します。 デフォルトは /root/.ssh です。 空の文字列に設定された場合、キーはどこにも格納されません。 |
APK_CONFIG_EXTIFC |
アプリケーションで提供されている場合、外部インターフェースの自動 IP 設定を有効化します。 外部インターフェースの IP 設定を無効にする場合は、この値を「no」に設定します。 また、この値に設定すると、外部インターフェース設定をサポートしていなかった前のバージョンのように APK が動作します。 デフォルト: はい 重要: 3.5 以前のグリッドで動作するよう設計された外部インターフェースを持つアプライアンスに新しい CA AppLogic 3.5 APK をインストールする場合は、APK_CONFIG_EXTIFC=no を設定します。 これらのアプライアンスは、プロパティを使用して外部ネットワークを設定します。 この設定は外部インターフェースを持たないアプライアンスには効果がありません。 |
APK_CONFIG_FILES |
アプライアンスのプロパティを適用するファイルをスペースで区切ったリストを指定します。 これは、(APK を使用していないアプライアンスの)GUI の[境界の変更]ダイアログ ボックスで指定した環境設定ファイル リストに取って代わります。 APK を使用したアプライアンスは、GUI で指定されたリストではなく、アプライアンス自体に置かれている APK_CONFIG_FILES リストを使用します。 重要: 既存のアプライアンスに APK をインストールする場合、エディタ GUI を使用してクラス記述子をチェックし、[View Class]/[境界の変更]ダイアログ ボックスの[環境設定ファイル]タブに設定ファイルが存在するかどうか調べてください。 ファイルのリストをアプライアンスの APK_CONFIG_FILES 設定に転送します。 |
重要: /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
ファイル /etc/sysconfig/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
重要: システム カタログ内の一部のアプライアンスでは、/appliance 内にあるカスタマイズされたスクリプトを使用してサービスが初期化されます。 これはサポートされなくなりました。 APK がインストールされると、ルート ディレクトリ構造をクリーンな状態に保ち、Filesystem Hierarchy Standard に準拠するよう、警告が表示されます。 このようなスクリプトのコードを /etc/sysconfig/applogic_appliance に移動して古い動作をエミュレートできますが、この操作は起動後チェック ファイルで意図されていないため推奨されません。 代わりに、インストールされるサービスには独自の init スクリプトが必要であり、一般には完全に CA AppLogic の外部で動作できる必要があります。
Copyright © 2012 CA. All rights reserved. |
|