Ubuntu Linux ディストリビューション用 APK インストール

アプライアンスの作成 › ディストリビューションインストール › Ubuntu Linux ディストリビューション用アプライアンスのインストール

Ubuntu Linux ディストリビューション用アプライアンスのインストール

ファイル

apk-ver-linux-ub.tar.gz - アプライアンスキット
domu-linux-lver.tar.gz - 準仮想化カーネルおよびモジュールライブラリ

互換性

apk-*-linux-ub バージョンは以下の OS distro と互換性があります。

Ubuntu （バージョン 6 と 7 は検証済み。これより古い distro でも動作する可能性あり）
Debian で動作すると見込まれる（未検証）

APK をインストールするには、以下のいずれかが必要です。

（APK がインストールされているかどうかに関わらず）古い CA 3Tera AppLogic アプライアンスイメージ
OS distro のバニラインストール

APK で提供されるカーネルおよび initrd ファイルを使用する場合、イメージには ext3 ファイルシステムが必要です。

イメージの準備

Linux バージョンの APK は、VMWare と XEN ハイパーバイザの両方の HVM ブートをサポートします。 CA AppLogic で提供される PVM カーネルはオプションです。

Red Hat 互換のオペレーティングシステム

CA 3Tera AppLogic で提供されるカーネルが APK インストールの実行前にアンパックされた場合、アプライアンスが PVM モードでブートされるとブートするカーネルとして自動的に設定されます。このための新しい boot/grub/menu.lst ファイルが作成されます。 HVM ブートでは、インストールされた OS で提供されるカーネルが使用されます（Red Hat 互換のオペレーティングシステム用のデフォルト OS grub 設定ファイルは、boot/grub/grub.conf です）。

他の Linux ベースのオペレーティングシステム

CA 3Tera AppLogic で提供されるカーネルが APK インストールの実行前にアンパックされた場合、ブートカーネルとして boot/grub/menu.lst にセットアップされます。元の GRUB 設定ファイルは、boot/grub/menu.lst.apkbk にバックアップされます。アプライアンス作成者は、設定ファイルとして別のファイル名を使用できるように、保存されたバックアップの名前を変更し、GRUB ブートローダを再設定できます。HVM モードのアプライアンスブート時に選択できるようになります。 PV モードのブートでは、常に boot/grub/menu.lst が使用されます。

CA 3Tera AppLogic で提供されるカーネルをアンパックすることなく APK インストールを実行した場合、GRUB 設定は元のままです。アプライアンスが HVM モードで実行されること、または OS で提供されるカーネルが XEN PV モードでブートできることが想定されています（多くの新しい OS distro では XEN-PV カーネルビルドが提供され、デフォルトとしてインストール、設定されます）。

以下の手順は、OS が最初にどのようにインストールされたかに応じて変わります。これらの手順の一部は（準備されているイメージ上ではなく）誤ってライブシステム上で実行されると侵略的で有害な可能性があり、自動スクリプトで実行することは不適切な場合があるため、これらの手順は APK セットアップスクリプトでは実行されず、管理者の裁量に任されます。適切でない手順はスキップしてください。

イメージを準備する方法

ディスクイメージが ext3 ファイルシステムであることを確認します。 OS が ext2 としてインストールされた場合、以下のコマンドを実行してイメージを ext3 に変換します。
```
run tune2fs -j
```
ext2 （または ext3 以外の任意のファイルシステム）を使用するには、APK と共に提供された initrd ファイルを再構築する必要があります。
ネットワーク設定ファイル（/etc/network/interfaces）を編集し、lo を除くすべてのインターフェースを削除します。
etc/fstab ファイルを編集し、ルートデバイスの名前を以下のように変更します。
```
/dev/hda1
```
また、ルートデバイスがラベルまたは UUID によって指定された場合、インストーラは確認の上、警告を出力します。
（オプション）依存関係を無視して、カーネルパッケージを削除します（ブートボリュームのディスク容量の保存のため）。
iproute パッケージが古い Debian および Ubuntu distro にインストールされていることを確認します。
使用しないすべての OS サービスをアンインストールします。
（64 ビットディストリビューション）libc6-i386 パッケージおよびその依存関係をインストールします（apt-get install libc6-i386）。 APK バイナリは 32 ビットです。32 ビットライブラリがないと実行されません。
注： APK の 32 ビット実行可能ファイルではなく、他のファイルを実行する必要がある場合は、ia32-libs meta-package のインストールを考慮してください。 meta-package は、32 ビットライブラリを含むすべてのパッケージをインストールします。

重要： ネットワークマネージャをアンインストールするか無効にします。このプログラムは CA 3Tera AppLogic ネットワーク設定と干渉します。例外：グラフィカルユーザインターフェースを備えた VPS サーバのセットアップの場合、ネットワークマネージャのアプレットがマニュアル IP 設定を実行するために使用されます（ただし、CA 3Tera AppLogic の新しい OS のインストールを起動する前に手動モードでセットアップする必要があります）。

注：クリーンアップ後に、アプライアンス用により小さなブートボリュームイメージを作成するためにボリュームが縮小される場合がありますが、XEN DomU カーネルおよび APK をインストールするスペースを確保するため、またログファイルや一時ファイルなどに使用する空間を確保するために、少なくとも 10 ～ 15 MB の空き容量が残されていることを確認してください。

Initrd ファイルの注意事項

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 のインストール

このインストール手順では、APK インストールが実行中ではない OS イメージに対して実行されることを想定しています。クリーンな OS のインストール、シャットダウン、ブートディスクイメージの作成を行うことにより、または既存の CA 3Tera AppLogic アプライアンスを APK の新バージョンでアップグレードすることにより、事前に準備された OS イメージが対象です。

ライブインストール（実行中の OS ）も可能です。CA 3Tera AppLogic サービスパック 2.4.5 以降で提供されている iso2class ユーティリティと共に使用できます。ライブシステムにインストールするには、以下の手順に従ってください。ただし、「/」をすべての操作のカレントディレクトリとして使用します。 XEN 仮想マシン（たとえば、iso2class を使用）で実行すると最もうまくいきます。 APK が CA 3Tera AppLogic XEN PV カーネルでのみインストールされていると、ブート不可能マシンになります。

OS イメージを system.gm ファイルにマウントします。イメージが CA 3Tera AppLogic グリッドにボリュームとしてすでにインストールされている場合は、vol manage コマンドを使用してアクセスできます。イメージ自体の /tmp ディレクトリまたはイメージがマウントされているホスト上の一時ディレクトリに APK ファイルをコピーします。イメージがすでにグリッド上にある場合は、Web インターフェースを使用して、イメージ自体にファイルをコピーします。（グリッドにおけるこの操作を行わない場合、以下の操作をユーザ root として実行する必要があります。）

wget をインストールする方法

DomU カーネルおよび 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=
イメージをマウント解除し、CA 3Tera AppLogic グリッドにインポートします（または、イメージがすでにグリッドにあり、vol manage を使用して編集されている場合は、単に vol manage シェルを閉じます。）。
イメージが既存のアプライアンスのイメージの場合、以下の手順を実行してください。
1. （GUI エディタを使用して）クラスを編集し、カーネルと initrd ファイルの名前を削除します。
2. 環境設定モードを dhcp に設定します。

アプライアンス動作のカスタマイズ - クイックリファレンス

詳細については、ユーザガイドを参照してください。

アプライアンス Init 設定

ファイル /etc/sysconfig/applogic_init が存在する場合、APK init スクリプトはシェルインクルードスクリプトと解釈します（「.」コマンド）。以下のパラメータは /etc/sysconfig/applogic_init に定義できます。

APK_AUTH_KEY_PATH

アプライアンスの SSH のアクセス公開キーを格納する場所。 3t comp ssh コマンドは、対応する秘密キーを使用して、アプライアンスに接続します。デフォルトは /root/.ssh です。空の文字列に設定された場合、キーはどこにも格納されません。
指定された場所が既存のファイルの場合、その所有者と権限が保持されます。そうでない場合は、ファイルは所有者のルートに作成されます。

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 がインストールされると、root!! ディレクトリ構造をクリーンな状態に保ち、Filesystem Hierarchy Standard に準拠するために、このディレクトリが削除されます。このようなスクリプトのコードを /etc/sysconfig/applogic_appliance に移動して古い動作をエミュレートできますが、この操作は起動後チェックファイルで意図されていないため推奨されません。代わりに、インストールされるサービスには独自の init スクリプトが必要であり、一般には完全に CA 3Tera AppLogic の外部で動作できる必要があります。

このトピックについて CA Technologies に電子メールを送信する